The value of malleable systems

We’re almost at the end of our hand over phase now; my time on the project is almost over. The last couple of weeks have been interesting. We’ve been working towards a demo of the system and this seems to have helped to get everyone moving in the same direction; suddenly the hand over seems to be happening… I don’t think I’ll need to be that involved in the demo as everyone else knows what’s going on and can explain how the system works… This is a Good Thing.

One of the other good things about the last couple of weeks is that my client changed their mind quite near the end of the project and we’ve been forced to accommodate these changes during the hand over. Our tests have made these last minute change reasonably easy; we’ve had to change the system but our changes have been supported by pretty decent test coverage and this has helped to remove some of the fear… I’ll probably kick myself later for saying this, but, I think having the client change the sign off criteria near the end of a project is, possibly, a good thing from a hand over point of view…

The system we’ve written operates on sets of trade data that’s split into organisational units; trades are grouped into books… For most of the development we were focused on the books that were traded out of London. We designed from this data, tested with it and generally built the entire system based on how the London books were organised. Like all multi-national organisations my client would probably prefer their data to be pretty similar no matter where in the organisation you are; however, like most of their contemporaries, the reality tends to be less clean cut.

Late in the day the decision was made to go live with our system using the New York based books. This shouldn’t have been much of an issue but it’s meant that we’ve had to face up to the most disruptive changes right now, rather than after I’d left… This is good; no, really, I mean it.

The changes we’ve had to make would have been required eventually anyway. By making them now we’ve managed to make them happen during the hand over phase which has meant that, for much of this work, I’ve merely directed people in how to make the required changes in keeping with the original design. It doesn’t matter what level of documentation you have, you can never beat having someone with the inside track on the design of the system available for these kind of changes.

What’s been nice is that we’ve had to make some fairly sweeping changes… Some of the decisions that were made based on London trading were inappropriate for the New York data. It became fairly obvious that some changes needed to be made at a fairly low level and these would, ordinarily, have been quite scary changes to make this late into the project. Often this leads to a pollution of the design as the system is perverted to fit the changes into the original design with as little change as possible; less change, less chance to break things; special cases start to be added and the design rot begins… Our tests helped and gave us the confidence to make the right changes in the right places and have them ripple out through the surrounding code as and when they needed to. These sweeping changes weren’t scary as our tests usually pointed out when we broke things. We didn’t need to try and remember all the assumptions that we’d made because our tests enforced these assumptions in code. Every time we built the system these assumptions were checked and we knew pretty much as soon as we made a change that violated something that some other part of the system relied on.

I’d almost be tempted to suggest to future clients that this is the ideal way to make sure that people understand the system that’s being handed over to them; get them to make some substantial changes to the system during the hand over…