Extreme Programming in APL
Exploring XP principles in an APL project


Sunday, April 6  

Friday we delivered Release 2.

We'd estimated that we would complete stories equivalent to 6 ideal days. We didn't get it all done: we omitted complete editing of the 'policy' information as the implications of editing derived data turned out more complicated than we'd seen. So we completed 4 days work, plus some.

What's working/not working? Code quality for the OO code I've written for handling policy information is proving robust, and easy to work with. I'm identifying errors and making changes fast; once I know what behaviour I want, I can produce it quickly.

That's less true for the SVQ system we're adapting. When I pair with Joe, the SVQ code looks clunky to me, with data and derivatives held in globals. But I don't 'have the theory of the system' to use Naur's expression.

Impressed reading Peter Naur's article on programming as theory building. I doubt the philosophical references are as relevant as the author thinks, but the central notion of a 'theory of the system' is persuasive, and so too, the assertion that code quality is measured by consistency with that theory as well as by the external behaviour of the system that it produces. Programmers operating without the theory of a system will degrade the code quality.

Paul has more of this theory than Joe; we need his advice on how best to do what we gotta do.

Still, we now have a library of policies standing in for the mainframe link. (The users and we are running a sweepstake on the date that a mainframe programmer starts work on the link.) We can calculate derived data from them and produce the relevant documents. Rough edges everywhere, but an outstanding achievement for a month's work.

Business expert users are disappearing over the Easter holiday. Me too, I'm driving my mother around Ireland. We'll pick up again after Easter.

Happy trails.

posted by Stephen Taylor | 2:55 PM
About this blog
Quotes
Links
Code
Archives