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.

The Tom (not Peters) Guide to Man Management

Last weekend was a bank holiday here in the UK, and so, as is our wont, on Friday evening we hopped in the car and headed off to the New Forest to go camping. We're ideally positioned for this, close enough to get out into the heart of the forest in 30 or 40 minutes (as long as we can dodge the bank holiday traffic). It means we can do a full day at work, but be pitched up with the dinner on and the first beer (always the best) in hand by 8 or 9 o'clock.

One of our favourite haunts is a site called Tom's Field. This is a field, owned by a bloke called Tom - the clue's in the name. It's low key, the facilities are basic but clean and well-maintained, and Tom and the loose confederacy who seem to run the place are friendly and helpful. Plus, of course, it's in the New Forest, with easy access to loads of walking, cycling, and pub lunches.

We had an excellent weekend, and by Monday lunchtime were packing up ready to go home and start preparing for the week ahead. Along with everybody else on-site.

Now, Tom owns a thing called a Gator. It's a little quad bike/tractor thingy that he uses for moving stuff around the site. The sort of thing you see farmers and groundsmen using.


On the Monday morning Tom went round the site telling all of the kids that if they put all the rubbish in the bins provided by the gate, they could have a ride on the back of the Gator.

This is genius. Sheer genius.

With this simple act Tom unleashed a veritable Tsunami of wombles who swept across the site like locusts, picking it clean of every last scrap of litter. In return for ten minutes of taking kids for joyrides, Tom saved himself several hours of tedious work.

I'm not entirely sure how to link this little story back into coding, the nominal topic of this blog. Somebody with more perspicacity and insight than me could doubtless create a compelling analogy to empowering the inherent synergy in a cross-functional team to achieve a win-win scenario. To using the carrot rather than the stick. To envisaging the desired outcome of a project and setting in motion the train of events necessary to manifest that version of reality.

Me, I'm just impressed that Tom gets his field cleaned for him every weekend. Tom, I salute you.