I am now mere moments away from finally switching off my windows box and making the iMac our primary home machine.

The last hurdle was cleared this week when I found a replacement accounting package for the family treasurer to use and replace the copy of Quicken 2002 we have been running for many years on the PC.

The reason I took so long in finding a proper replacement was that I’d failed to listen to my stakeholder (my wife, Liz) on what her actually requirements were for the new package. I had investigated all sorts of shinny new software, from the free GNUCASH (that took me half a day to build) through to some fancy stuff from Igg Software called iBank. Everything I looked at seemed to do the the job (at least the trial versions allowed me to import the data) and looked good.

However, each time I ran the stakeholder demo I got the response ‘its too complicated’, or ‘I don’t want to learn a new package’, ‘I just want it to look and work like the old Quicken’.

Now Quicken isn’t the most fantastic piece of software, but it does a job, Liz knows how to use it and we’ve got several years worth of transactions in it. Its satisfied my stakeholder’s needs. So here I was trying to find something wizzy and new, when all Liz actually wanted was to have Quicken run on the iMac.

Unfortunately there isn’t a Mac version of Quicken (there was one, but they stopped it in the UK a while back and they’re promising one later this year), but in my searches I stumbled across an offering from Codeweaver called CrossOver Mac that claims it allows Windows programs (albeit a specially selected list) to run on a Mac. So last weekend I downloaded the trial version, installed Quicken 2002 and rebuilt all my transactions using a backup file and hey presto! we were in business.

After running the Mac and PC in parallel for a few days my stakeholder made the call to make the switch permanently. So we are now fully Mac’ed’ and I have a delighted treasurer.

Lesson learned, listen to what your stakeholder really wants, don’t assume you know better. Sometimes the simplest solutions are the best.

Now the only thing I have to crack is convincing my eldest that the Mac’s parental control really is a good thing!

I’d like to thank one of our senior developers for inspiring this post. Dave Vines recently sent out an excellent, thought provoking email on how we should be moving towards a tester driven development model. I’ve slightly reworded his email:
“One thought that I’ve recently had was that perhaps we need “Tester Driven Development” rather than “Test Driven Development”. Let me try to explain.

We are currently very much a “Developer Driven Development” organization:
We gather new requirements and (typically) farm them out to the development community to investigate
Once a work item is identified, it is typically a developer that

• Writes the Design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the development resource to write the code
• Decides which iteration in which the code will be written
• Hopes that test will have the resource to test all the use cases and “interesting edge cases” that have been identified and for which code has been written (or not written)

In effect the developer owns the work item

In a “Tester Driven Development” organisation I would see us:
Gathering new requirements and (typically) farm them out to the test community to investigate
Once a work item is identified, it is typically a tester that:

• Writes the design document
• Calls the meeting to develop the use cases
• Identifies the interesting scenarios
• Gathers the test resource to test those scenarios and use cases
• Decides which iteration in which the code will be tested
• Indicates to development what use cases and code will be needed and when

In effect the tester owns the work item

This would be a massive culture shift for a department, but one that makes it clear that the desired deliverable is actually requirements that have been tested, not requirements that have been coded and may have been tested if test had enough resource. “

(more…)