Reversing Hofstadter’s Law

2007-10-09 • , • Comments

Exponential overrun

I arrived at the station a few minutes early. The information board showed the train was running on time so I went straight down to the platform. No time for a snack. I glanced at the Passenger’s Charter poster in passing — a bar-chart showed the trains were 90% reliable.

Just before the train was due the information board flashed up an alteration — the train was in fact running 10 minutes late. 10 minutes later a second alteration stated the train would now be 20 minutes late. When the train finally departed 40 minutes behind schedule I was hungry and cross.

As a software developer, it probably seems like I’ve got a nerve moaning about the trains running late. We get it wrong all the time, and there aren’t any leaves on our lines. Computers are supposed to be predictable, but for some reason, Hofstadter’s Law gets us every time.

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Any computer scientist can spot the recursion and the associated risk of exponential overrun. Doubling original estimates won’t bring things in on time, it just delays completion by a factor of four. And so on. “It” never gets done, and the only escape is to break out of the cycle and call it a day; except, of course, it will be rather longer than a day by then.

Spectacular errors

It’s futile to compare running trains on time to delivering software on time, but Virgin Trains do show use how to get things spectacularly wrong.

  1. Defer admitting to problems until they’re painfully obvious to everyone involved. If the information board had said the train was running 40 minutes late in the first place, I’d have been far less annoyed.

  2. Paint a positive picture. It’s galling that the train companies publish figures so far out of line with my personal experience. Either late and cancelled trains upset me disproportionately, or I have higher expectations of what it means to be punctual, or the statistics apply to train services I don’t use. Probably all three.

Bite-sized chunks

Running a software development project on time isn’t like running a railway. As a passenger, I’m not very flexible: I need to get from A to B, and want to know when I need to be at A in order to get to B on time. As a software customer, my requirements are rather more vague. Maybe I’d like to get off at the first stop, thanks very much, or maybe C will turn out to be a better destination.

Agile development techniques aim to offer customers this kind of control. By actively seeking their feedback at all stages of the project, we allow them to modify and customise their journey. It’s software after all; it’s meant to be soft. Tasks are reduced to bite-sized chucks — if you’re unsure how long something might take, chop it up — and the team, including the customer, continually reviews progress. The journey becomes the focus as much as the destination.

I adopt this approach as far as I can, and it’s served me well day by day, week by week.

Biting off more than you can chew

Unfortunately I’ve also seen agile aspirations come unstuck in the face of commercial reality. You’re invited to tender, you specify, you cost, you plan, you grumble about Microsoft Project; you consider the competition, envisage the end game, pin an end date on the calendar. All of a sudden Hofstadter’s Law has teeth.

Unfortunately I haven’t any easy answers here, just some glib observations.

  • This model of financing software development doesn’t work very well.
  • The bigger the project, the worse things get. It hurts every time I hear about failures from the likes of EDS to set up some government IT system. Whoops! There go our taxes.
  • Over-run isn’t always a disaster. Some of the best pieces of software take longer to develop than initially expected, and benefit from it. Many open source projects recognise this and emphasize doing the right thing, doing it right, and confessing to problems at the expense of schedule.

Dog Food

Here’s an example of that last point. Trac is a software product for project management. Trac’s own development is managed as a Trac project. I’ve been watching the Trac project roadmap for a while, since I needed to set up a local Trac project, and wondered whether to wait for the next point release (Version 1.1, which was apparently imminent when I started looking). That point release is now 3 months overdue.

Has the delay held us up? No! I decided to simply install an earlier version, and I haven’t regretted it. I’m confident I can upgrade to a subsequent release if I need to. Does it mean that I can’t trust Trac as a project management tool (since their own projects run late)? Again, no. This picture reflects reality, and they’re being open and honest about things. How many closed pieces of software have I purchased, which have since failed or needed a sequence of patches to keep them alive?

Under-promise, over-deliver

I’ll end with another travel story, this one with a happy ending.

My current passport was about to run out and we’d booked a holiday abroad in four weeks’ time. So I filled out the passport application form, checked it, paid the person at the post office an extra £7 to check it, and sent it off. According to the information leaflet, I could expect it back in two weeks, so there was some room for error. My new passport arrived in just one week.