Back from Italy and XP 2003.

How do you automate in three months a procedure it takes 6 months to train a new clerk to do?

No matter how smart you think you are, you've got an analysis challenge.

A pitfall to avoid is refactoring the manual procedures. These have been optimised to to minimise human work. In this project's case, some of the complexity comes from shortcuts taken to minimise calculation. With the machine, we would prefer to optimise to minimise the number of rules. Calculation is mostly free.

So spending time in analysis to reduce the number of rules to follow -- refactoring the original process -- is tempting. But it takes time we don't have. So Plan A is always to code it exactly as the clerks do it.

I can still refactor the code without consulting the trainers. I've already done some of this. The very concise APL source code allows patterns to show up at a high level. Since we now have a useful library of test cases, I can refactor these and test. In fact, doing this allowed me to catch what I believe were misunderstandings on my part, which had not been caught by the application test.

But refactoring this way has a drawback. The first version of the application code follows the trainer's instructions precisely. So it's easy to resolve any discrepancies between our results: we use the interpreter to step through the calculation, examining the results as we go.

I can't overemphasise how useful this has been. The communication process has been dramatically shortened. Effectively I'm now pair programming with the customer, who is reading the APL code off the screen, seeing her instructions reflected in control structures. (So APL is 'unreadable'? Match that, Java programmers!)

Refactoring the original process to simplify the rules is a whole new ball game. Slavishly following the existing rules, no matter how baroque they might be, has a clear advantage. You know that it will turn out, that you will produce the same result after some predictable amount of work. In refactoring the procedures, you don't have the same assurance. It's almost the same as redesigning the procedures, except you've got a test suite to get you home. Given that the trainers understand the reality represented by their procedures, it will probably all work out in reasonable time.

These reflections prompted by several days effort spent now on redesigning a table in which intermediate results are presented to the users. Using our system to display this provoked the users to suggest a more orderly presentation than the one they use themselves. We're still working out the consequences.

I felt a twinge of unease when I heard we were doing it. The lesson learned: on a sprint project like this, refactoring the users' processes can be a significant cost.

That said, we are getting it straight and it looks like the calculation rules will come out significantly simpler, with good consequences for later work.