Marathon sprinting

Have you ever watched Usain Bolt run? Bolt is considered to be one of the best sprinters of all time. He currently holds the world record in the 100-meter dash at 9.58 seconds, which, translated to Imperial units, means he’s running just over 23 miles an hour. That’s really, really fast! There’s no doubt that Bolt trains extremely hard for his sprinting events and that’s why he’s one of the best ever at what he does. But think about this. How do you think he would do as a marathon runner?

That’s a hard, if not impossible, question for me to answer as I’m not a runner; I’d rather go biking myself. But as a casual biker, I know that if I pace myself, I can go for longer distances than if I push myself hard all the time. Think if a marathon runner would go at the sustained pace that Bolt does for the 100-meter dash. Given that a marathon is approximately 26 miles, a Bolt-like marathon runner would finish in 1 hour and 7 minutes. The current world record is a little bit over 2 hours.

Now, since 1908 the best marathon time has been reduced by roughly 53 minutes as we’ve learned how to train and condition better over the last 100 years, but marathon runners are still nowhere near sprinting times, and arguably never will be. It’s a different style of running that requires different training techniques. Yet we seem to emphasize “sprinting” in software development all the time, and we need to take care on how we use the term.

Unhealthy sprinting

I’m sure you’ve seen projects that are sometimes deemed “death march” projects. The code is a mess, the requirements are non-existent or confusing, team members are constantly fighting – in short, the project is laced with negativity and dread. Yet, it is a project that is “critical to the success of the business,” so, no matter what, the project will be “finished.” It may come across the finish line with a bunch of duct tape and chewing gum holding the car together, but hey, it’s “finished!”