PairProgrammingWithTheCustomer

This is an odd practice that emerged from AnAplXpProject.

The application automates the processing of maturing pensions. The processing rules for every kind of pension scheme sold by the company in the last decades has to be included. Worse, the company has merged with several others, so all of them too.

It takes weeks to train new clerks to do the paperwork. They have 20-30 checklists, which cross-refer, so they use them like program modules. But checklists don't compile, and are subject to interpretation, leaving notorious 'grey areas'.

At first I chose to get trained like a new clerk, taking notes. But my questions were getting both me and the trainers lost, as they struggled to find unambiguous language to describe the different choices and their consequences.

I foresaw the painful production of notes full of misunderstandings which would come to light only when coded.

So I changed tactics. Instead of discussing the rules, we followed them for one real case at a time. I mocked up the case data. Everything we read from a mainframe screen got mapped to Dyalog APL namespaces in immediate-execution mode. APL's fluency with arrays enabled me to replicate an entire screenful of data in minutes.

I laid out the rules on the checklist as comments in an APL function. Then, rule by rule, the trainer demonstrated how to perform each rule or check, and I coded the rule. Coding generally took less time than demonstration and explanation. Usually I typed the APL expression for what had just been done while speaking the rule at the same time in English. For example:

From the INFO screen sum all the PUREENDOWMENT items where there the sum of corresponding NONLPIAMOUNT and LPI497AMOUNT items is positive.

+/INFO.((0<NONLPIAMOUNT+LPI497AMOUNT)/PUREENDOWMENT)

From the INFO screen sum the absolute values of all the NONLPIAMOUNT and LPI497AMOUNT items and subtract them from the same sum taken from the ISPE screen.

-/(ISPE INFO).(>+.+/|NONLPIAMOUNT LPI497AMOUNT)

When I had finished calculating the case, I'd run my code and see if I get the trainer's answer. If not, we reconcile. The APL interpreter allows us to step through the procedure, examining the partial results. It takes only minutes to discover where we differ and to work out where the error is. (It's not always me -- these procedures are complicated.) When we get the same answer, we append the case to the test suite and rerun the whole suite to see if we've broken anything.

Instead of getting requirements from these conversations, and the promise of acceptance tests to come, I now get working code and test cases that the code passes.

My training tells me I should be discovering and documenting requirements, then securing the customer's confirmation. Then I can go code. But there's no way I'd get an authentic sign-off on a formal description of the requirement. It just wouldn't communicate with the trainers. XP tells me I should get the requirement in conversation, which is a huge step forward, but we were still spending a lot of time confused.

I seem here to have suddenly collapsed analysis, specification, coding and acceptance testing into a single conversation.

People have commented in JustAnotherProgrammingLanguage that some languages are more agile than others, and that it makes a difference -- of degree. Here we see a sufficiently large quantitative shift producing a qualitative shift. Because ExtremeTerseness lets me code a solution literally as fast or faster than the customer describes the problem, I can empower the conversation.

It's nice that I spend less time coding, but that's not the point. The point is that a conversation that once could produce only notes for another conversation ("I wonder if you could clear up these points for me...") to be followed by coding and testing and feedback ("No, you need to have it do this bit first...") is now cutting and testing code.

The code is the test of the analysis. Of course, it always was. But now I'm getting immediate feedback. When we finish, both I and the customer know that the rules are done the way she wants. Huge increase in confidence on the part of the customer. Order of magnitude improvement in velocity.

StephenTaylor