Running as an analogy for software developers

Mail arrives from an old friend in Silicon Valley:

“So just as we get back from the show to recover, rebuild relationships with our wives and kids (since we've been working constantly for 3 weeks prior) they want us to drop everything again”

Meanwhile, a different friend tells me that he doesn’t know when his project deadline is.  He’s got his burn down chart that shows when he thinks he’ll finish but this doesn’t seem to matter to anyone just now.

So, what do these two, apparently opposite situations have in common?

Well, it makes me think that developing software is a lot like running a race.  I’m know I’m not the first to think of running as metaphor, after all SCRUM actually has development sprints but not every development is a sprint.

It all comes down to distance.  First of all, you need to know how far you are going to run, you need to know were the finishing line is.  We might start projects with only a vague idea of the deadline: next November should; and even if we do know it might get changed.  The thing is, when your deadline is makes a difference.

Unfortunately the deadline is all too often the finishing point.  Personally I like to pace myself so my work is finished before I get to the deadline.  There are two problems here.  First: all too often we’re asked to do more work than is actually possible in the time allowed.  We try and put a quart into a pint jug.  Gung-ho management can actually make this sound like a good thing.  However, if management don’t prioritize and give guidance on what to do they are really abdicating their responsibilities to developers.  They are saying:

“We want to you to do all this work, this is a challenge to you.  We don’t want to know if you can’t fit it all in, just make it fit somehow.”

So, either they have to extend the deadline, or they get a selection of requested work chosen by the developers.

The second reason why my approach fails is the tendency for people to say “Arh you’ve finished, in that case you’ve got time to do this as well…” and increase my load.

Still, back to the race analogy.

If I’m running a sprint I know I need to run just as fast as I can.  I know it will soon be over and I can recover.  I know that if I have a chance to pass someone I have to take it, there may be risk but there probably won’t be a second chance.  In a sprint the start and end are clearly defined and its a straight run.

Thats different to a 400m, you still have to run damn fast but there is an element of pacing.  You will get second chances to overtake someone but you won’t get many – so the risk equation changes.

An 800m changes things again, its much more about pacing yourself, and the risks are different again.

Normally developing software is something like a 800m.  You have near deadline but its not so close that you drop everything.  Sometimes when you have a 100m deadline you drop everything else in your life.  I did once port a piece of software overnight.  Six of us: Roy and me coding (porting) like nothing else mattered, two more developers riding shotgun, and two managers ordering take-away food and biting their finger nails.  We took risks and worked in a way we would never have done if we had another day, let alone another week or a month.

And on a long run, like a marathon, things change again.  Its all about pacing yourself, you need to know when to run fast, when to hold back.  You need to stay on the course, often you find it is not well sign posted so you need milestones and navigators to help you.  Although your competing with the others in the race your also co-operating in a way.

Or maybe development is more like a relay-race, you have to work as a team.  Or maybe its like hurdling, someone puts obstacles in the way.

So what does this analogy teach us?

I think it emphasizes the importance of pacing yourself.  You might be able to run 100m fast but running 800m is not the same as running eight 100m races back to back.  Everyone knows this about running so why don’t they see it in development?