Monday, August 24, 2009

Experimenting with Windows Live Writer

I heard about Windows Live Writer in the context of Windows 7.  It proclaimed itself as able to help me do a better job posting to my blog.  Thus far I’ve struggled to post multiple pictures and to have the formatting I want.

MarkWaite

The idea is that I should be able to easily embed multiple pictures, wrap text around the pictures, and generally manage the blog more directly with their editing tool rather than using the HTML editor provided by blogspot.com.

We’ll see…

MarkWaite

Thursday, August 13, 2009

Python WIN32 extensions on Windows 7

I started using Windows 7 a few days ago and needed the Python interpreter. I also needed the WIN32 extensions for Python.

The Python installation worked just fine, I downloaded Python 2.6.2 and it installed with the expected Microsoft UAC prompt confirming that I truly intended to install.

The WIN32 installation prompted for UAC as well, but then failed with an obscure error message. However, I was able to successfully install if I opened a command processor window with "Run as Administrator", and then ran the pywin32 installer from there. With that "magic", the installer succeeded and had the happy message "The pywin32 extensions were successfully installed".

Thursday, July 16, 2009

CAST 2009 - Red, Yellow, Green Facilitation

An amazing conference has ended its formal sessions. The last 3 days have been filled with insights about software testing, management, and measurement with a group of serious thinkers and practitioners of software testing.

I was fascinated by the facilitation technique used to support the high amount of conversation that occurs at CAST. The facilitation technique allowed a group of engaged listeners to discuss, debate, question, and interact with the presenter in a fluid but surprisingly orderly fashion.

Imagine the types of problems which are likely to occur when a presenter brings a controversial topic to a group of highly engaged, forward thinking professionals. The audience (software testers) consider it their professional role to challenge the status quo, see things differently, and understand those differences more deeply. With that type of audience, a typical presentation would rapidly lose focus as many of the testers challenge, question, and discuss their insights.

The CAST 2009 facilitators used "K-cards" and some agreed principles to assure that the presentations and resulting conversations are a good balance between allowing the presenter to complete their ideas and allowing the audience to interact with the presenter. K-cards are a trio of colored 3x5 cards with a unique number assigned to each member of the audience.

The red card is the "Burning Issue" card. An audience member raises their red card to interrupt the presenter or any current discussion. The red card is used to raise points of order, to flag blocking problems (like poor facility acoustics), or to allow a meaningful interruption of the presentation with key information. The red card can be confiscated by the facilitator if the facilitator feels it is being misused or abused.

The yellow card is the "On Stack" (or current topic) card. It signals that you have a question or comment related to the current thread of discussion.

The green card is the "New Stack" (or new topic) card. It signals that you have a question or comment which is not related to the current discussion. The facilitator keeps a list of numbers on a sheet of paper which reminds the facilitator the expected order in which new topics will be addressed.

The interaction during the sessions was orderly, insightful, and well managed. Ideas were presented, disagreed upon, discussed, and then new ideas were managed as well. The general format of a presentation allowed the first half of the allotted time to be dedicated to the presenter, while audience members would listen and if necessary, would raise a red card to flag a point of order or question which justified interrupting the speaker. The facilitator during my first few sessions was quite patient with my tendency to interrupt and did not take my red card.

Once the presentation was complete, or presentation time expired, the session switched to "open session". The facilitator called the number of the first "new topic" card they had seen during the presentation. The audience member whose number was called (I was number 15 throughout the sessions) asked their question or made their comment and the presenter responded, with some "back and forth" dialog between questioner and presenter.

If someone else had an "on topic" comment or question, they would raise their yellow card. Throughout the session the facilitator is noting the order of appearance and resolution of green ("new topic") and yellow ("on topic") cards on a notepad. "On topic" comments and questions take priority over new topics, and burning issues take priority over same thread topics.

With that simple mnemonic device, a skilled facilitator, an engaged audience, and a presenter ready to engage in dialog about their topic, the conference moved forward very well.

Paul Holland, the lead facilitator of CAST 2009, noted that there are some other subtle techniques which the facilitator can use to further improve the meeting. For example, if there are especially strong or high expertise individuals in the room, it is OK (and useful) for the facilitator to place those individuals at the "bottom" of the "on topic" stack, even if that is not the order in which they raised their card. By placing the experts at the bottom of the on topic stack, it allows the chance for others to present the question or observation which the expert would have presented, and involves other less expert people in the discussions more effectively. I believe some of the facilitators even chose consciously to place experts at the bottom of their "new topic" stack so the less expert would be involved in the conversation.

That stacking system worked well in the session I attended with experts. There were cases where the expert would be called upon and would call "pass" because their idea or comment had already been covered in the discussion.

The system is called "K-cards", named after Paul Holland's wife Karen. Before K-cards, Paul facilitated by having people learn three hand signs to signal the same meaning as the 3 colored K-cards. One of the attendees complained that the hand signs were too complicated. Paul was complaining to Karen in mock outrage that someone would not be able to learn 3 simple hand gestures. Karen suggested, "Why not use different colored cards". They made the switch, and they are now named "K-cards".

Paul noted that the Los Altos Workshop on Software Testing (LAWST) pioneered the original format which has been improved with K-cards.

I will attempt to use K-cards in sessions where I facilitate a discussion with a large group, and I may discuss the idea with others. We have a user experience workshop coming soon, and that workshop seems like an interesting place to try this technique as a way to manage the many opinions, discussions, and conversations which will naturally arise.

Thanks to Paul Holland and to the rest of the CAST 2009 facilitation team for showing how effectively a simple device can encourage interesting, effective, actively progressing conversation!

Tuesday, May 12, 2009

Another Mistake - Inconsistent Systems

The build broke again. It seems to have been the same root cause as the last break. The build machine has something different about its configuration which caused it to reject code which was allowed on a developers clean installation of Visual Studio 2008 and the Microsoft.NET framework.

The moral of this story: Don't ignore the first failure, since the root cause of the failure won't "just go away" until it is understood and repaired.

Thursday, May 7, 2009

End of day anti-pattern

I made a foolish mistake today. I should have known better... Now it is time to resolve to make new and different mistakes tomorrow, instead of making this same mistake yet again.

Wait For Green

Two of the programs used for our installation only make sense when run as an administrator. The Windows Vista and Windows Server 2008 user account control (UAC) code does not allow administrator privileged users to run programs as an administrator unless they explicitly select "Run as Administrator", or if the program has been marked with a manifest which tells the operating system to always run this program as an administrator.

Those two programs were using the default manifest, and one of the two was adding itself to the "Start Programs" menu. When a Windows Server 2008 user clicked the program with user account control enabled, it crashed painfully and offered to send a report of the problem to Microsoft. We didn't want that.

Visual Studio has an easy way to add manifests to applications, and it seemed simple enough that even a manager could do it...

I made the change, compiled the code, reviewed the code with a real programmer, and let it sit for a few days. This evening, just before leaving for home, I submitted it to the source master and left the building for the swim team dinner.

Don't Do That!

That was a mistake. The compilation failed on the production build machine, even though it had worked flawlessly on my machine. Apparently the production build machine has a different version of one of the compiler components in its path, and that different version did not recognize the options inserted by my version of the Visual Studio IDE. Ugh.

Check the Continuous Integration Server After You Commit!

I've reverted my change, but not after keeping someone else up late into the night because I was not paying attention to the results of my code change.

(There's another thing which is "have fast continuous integration", but we're still working on that...)

Saturday, April 25, 2009

"Benefit" that doesn't provide benefit

The U.S. government has allowed "pre-tax" medical reimbursement for several years now. The system allows my employer to take money from my pay before they compute and deduct the personal income tax, social security tax, etc. Those funds are placed in an "account" from which I may request reimbursement for qualifying medical expenses.

The medical reimbursement account has the effect of making some of my health care payments "tax free", stretching my health care funds further by the amount of my tax rate. That is a nice benefit, and I've used it for many years.

As an added benefit, my previous employer and my current employer both offer a Mastercard which can be used to pay eligible medical expenses directly, instead of paying them "out of pocket" and then requesting separate reimbursement.

That Mastercard seems like an ideal solution. It reduces my paperwork and it could reduce my costs by not requiring that I mail evidence for the reimbursement. It could reduce the costs for the benefits provider since they would not have to process the reimbursement evidence either.

But No, There's More (or Less)

Unfortunately, it doesn't work that way. It appears that almost every time I use the "benny card" (Mastercard to pay from the reimbursement account), the provider is required by the government to gather proof of the validity of the expense.

The sequence I wanted was:

  1. I pay a medical expense with the Benny card
  2. The provider pays the expense and deducts the expense from my account


The sequence I get is:

  1. I pay a medical expense with the Benny card
  2. The provider pays the expense and deducts the expense from my account
  3. The provider requests proof of the validity of the expense
  4. I find the receipt (by this point, several weeks old), copy and mail the copy to the provider
  5. The provider processes the receipt and decides it is valid (or not)
  6. If not valid, the provider rejects our claim and request repayment of the money they had paid

The actual sequence is worse than using the Benny card, not better!

I'm not clear on the root cause of the problem, but some of the alternatives to this sequence might be:

  • Stop requiring validity checks of expenses, accept some fraud as cheaper than the alternative
  • Declare all expenses from certain providers as "valid" (doctors, pharmacies, etc.)
  • Stop pre-tax medical reimbursements and either find another way to provide comparable benefit, or admit that the benefit is not valuable enough for the expense it creates


My moral: Be careful of unintended consequences. I doubt our elected representatives or the people who planned the pre-tax medical reimbursement system would be pleased that I have decided to never use the Benny card again, because its use is more onerous than the old reimbursement system

Saturday, April 18, 2009

Personal Continuous Integration

I've been experimenting for some months with distributed version control system (Mercurial and Git) on various personal projects.

The most interesting of the personal projects was a branch from an active code base that I wanted to extend in a slightly different direction. Because my changes are going in a slightly different direction, they were not likely to be included in the original code base for a very long time. That meant I was going to be "on a branch" from that original code base for a very long time.

Past experiences with CVS and Perforce suggested that being on a branch for a very long time could be a problem. Perforce was not as bad as CVS, but still it was difficult to maintain a separate personal branch and "keep it healthy". Inevitably I would make changes that were harmful to the main code, and not realize I had harmed it because I was not getting all the feedback that is available to developers on the main code.

The main code developers have a continuous integration setup which runs automated tests in many different configurations and summarizes the results to a central location. The results are easy to browse and easy to watch as they evolve.

Since I'm not on the main code, I don't have that nice infrastructure to support my private branch. With distributed version control, I have all the power of a version control system (incremental checkin, revert to previous point in time, branching, merging, etc.). Why can't I have all the power of a continuous integration server for myself as well.

Why Not Use My Own Machine?

I'm sure others have already realized this, but with the ease of installing, configuring, and using the Hudson continuous integration server, I can run my own continuous integration server which compiles and tests code from my personal version control, before it is ever pushed to any other person (or system) in the organization.

Setup Idea
  1. Install Sun JDK (needed by Hudson)
  2. Install Hudson continuous integration server
  3. Run the Hudson continuous integration server
  4. Install distributed version control (Mercurial or Git or ...)
  5. Install Hudson plugin for selected distributed version control
  6. Clone the development repository from the company central location
  7. Create a new Hudson job which monitors the local repository, checks out the source from the local repository when something changes, compiles it, tests it, and reports its results
  8. Start making local changes, checking them in, and enjoying the benefits of continuous integration test runs while developing the code, without the danger of checking into a central repository before the code is "done done"
I think those setup steps could be reduced to less than a day, and that day would repay itself within the first 4 weeks of work as developers were more confident in their changes before they shared them with others. I don't yet know if the idea will work for "real" developers, since I'm the manager trying to provide them the tools and environment to be successful, rather than a full time developer. We'll see if the idea actually reduces the feedback loop, and if it actually is viewed positively by the developers. What Will They Value? I think developers will gain
  1. Rapid feedback on their changes
  2. Background work (compiling and testing while they work on other steps)
  3. Isolation of their changes from others until they are "done done"
  4. Visibility to the impact of changes from others in their test environment (integrating changes from others onto their branch is a "trigger" event, just as checking in their own changes is a trigger event)