Too busy to report project status? That's an old chestnut!

Joe & I focused on assembling pieces for Release 1. Not quite a ziffer (Zero Feature Release) but just enough to let our users steer the next iteration.

To put it another way: rather than exploration or analysis or even collecting user stories, given that we're adapting a previous system (SVQUOTE, hereinafter SVQ), we're presenting a version of SVQ with a fraction of the required logic and output installed. Next week, when we plan the next iteration, the users can tell us how much effort to spend on changing the existing SVQ features, and how much to spend on new capabilities.

Joe joined us yesterday with experience from the SVQUOTE system. That means he can figure out how to adapt the system to handle this project, while I focus on the specifics for this project. He manages the bone and muscle, and I, the squishy innards.

He was a bit appalled at all the new things to digest: object-oriented code organisation, data and code nested into namespaces passed as arguments and file components, but is now bearing down on adapting the shell's GUI data editors.

The XP practice of adapting scope to a fixed timetable is serving us well, and keeping us focused on what can be achieved in the next few days. The training I had as a Course Supervisor at Landmark Education is making a big difference too.

I've also had an insight that sharpens the sometimes blurry distinction between unit tests and acceptance tests. If I don't understand why an acceptance test fails, the customer can help me. But if it's a unit test, she can't.

So I cheated. XP deprecates working overtime, but I spent some hours on Sunday working on the Diktat class. This was my first attempt to practise Test-First Design, and the results were encouraging.

At first, it was hard to think of the tests. But I got the hang of it after a while. The Dyalog Explorer is really coming into its own as I define a test case in a name space c, edit its comment and lx (test expression) values and edit or define any other fns or values it needs. Then Tests.RunTest c gives me a pass or fail.

XP talks about establishing a development rhythm: write a test, run it to see it fail, write code, see it pass or fail, revise code until it passes test, write another test...

The beauty of this rhythm is how focused it keeps me. For the Compare method of the Diktat class I wrote three tests: compare a diktat with itself, with a variant where the text fragments match but the dictionary values don't, and a variant where neither match. (I can think of other tests, but they seem unnecessary.) Defining the tests first had me focus on coding just to pass those tests without thinking about other issues. That shortened coding time. When the method passed all three tests, I reviewed the code for refactoring opportunities and I was done.

Reading Wake on Extreme Programming Explored, full of practical illustrations. Sadly, all the illustrations are in (tedious, verbose) Java, but it's still possible to follow the narrative. Leaves me strongly impressed with how much faster I can follow the same paths in APL; just so much less to write or refactor.

Miki's hanging on Monday for her first exhibition (see www.mikiy.com) and for technical support called me back from sunny Surrey and the walk I had planned for after the meeting of the Vector working group. But we did take a break in the new spring weather and played frisbee on Hampstead Heath.