Tuesday, 12 May 2009

Profound Advice: Do It Right the Third Time

This is one of series of posts on the subject of profound advice, in which I metaphorically travel back in time to meet my younger self, and give that sad git some hard-earned pearls of wisdom. Which, knowing me, I will completely ignore. Or did ignore. Or something.

This week marks the 40th anniversary of the release of 'The Italian Job'. This most quintessentially British of all crime capers stars Michael Caine as Charlie Croker, modish wide boy with an eye for the main chance.

Noel Coward is magisterial as Mr. Bridger, the uber-royalist crime lord running the underworld from his prison cell.

Even Benny Hill is watchable as the lascivious computer expert, with a penchant for the larger lady, charged with bringing Turin to a standstill by overriding the traffic control system.

And of course it gave the world the essential Michael Caine quote, the one guaranteed to be invoked by generations of impressionists.

The 2003 remake with Mark Wahlberg was a perfectly acceptable crime movie, but in the UK at least was damned by association with the original - how dare anybody remake such a classic movie? My wife wouldn't even let me bring it into the house until last year.

It's something of a truism in engineering that the best time to design your solution to a given problem is just after the project's finished. At this point you've met the pitfalls and pratfalls awaiting you, you've worked around them, and you're fully aware of the implications of your early decisions. Knowing all this, and with the benefit of 20-20 hindsight, it would be relatively trivial to re-do the project.

A depressingly common approach to design is the big bang approach, AKA BUFD (big up-front design). Given a problem, you attempt to construct an all-singing, all-dancing solution that will stand forever as a testament to your genius. You try to build a framework that will solve not only your immediate problem, but a whole class of similar problems that may or may not arise in the future. Which is a fine and worthy goal, except that it's almost certainly a colossal waste of time and effort. It's certainly not shipping code. You don't know the future - if you did you would be betting on horses, not cranking code. So admit your temporal limitations and code for what you need right now, not what you may need in some conjectural future.

My first attempt at solving a problem tends to involve a lot of hardwired assumptions - e.g., the demo code only works if the microcontroller is at a specific address on the I2C bus, has a fixed memory map, and is running a specific version of the firmware.

Which works fine a surprising amount of the time. If I have to revisit the code - for instance, the firmware gets updated - I'll add a bit more intelligence to the code to handle this new situation.

Finally, if I have to revisit the code yet again, I'll make more of an effort to do things 'right'. At this point I've already solved the basic problem twice, so I've got a pretty good handle on how to do this. I know what works and what doesn't. I can devote some effort to developing a more generic solution with the full knowledge of what functionality is likely to actually be needed - because it was actually needed. I can develop a more modular code layout that lends itself to future maintenance work. If I'd tried to do this from the get-go, I would needlessly have locked myself into what I thought was the correct architecture on day one. And it would have taken a lot longer to build the generic-but-wrong solution than it took to build my hardwired-but-quick-to-get-going solution.

As usual I thought I had independently invented here a whole new concept that would revolutionise the world, a concept I termed 'do it right the third time'. I also toyed with the phrase 'speculative complexity', which pleases me, as it captures something of the unnecessary intricacy many people seem to find so attractive.

However, it turns out that lots of other people have had exactly the same idea; the extreme-ists call it 'you ain't gonna need it', which is admittedly much cooler.

Don't go for a big bang when you're only supposed to blow the bloody doors off.

No comments: