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!”
The problem is that the team members are left in a demoralized state, wondering if they have to keep pushing the car along for years to come, or if they’ll be reassigned to another project where the same disaster will occur. Unhealthy projects like this typically come with the view that everyone should just “work faster” and push themselves to somehow “code quicker.” But is that possible?
I think every developer would like to say they can “code fast”, but that’s not the only aspect that matters. It also has to work well, passes QA and user acceptance testing, performs well, and can be maintainable in the future, along with a number of other desirable qualities in an application. Yes, getting something to market quicker than a competitor has advantages, and sometimes we need to push ourselves harder. But trying to run as fast as a sprinter over the course of a marathon isn’t doable.
Healthy sprinting
Here’s what I think is a good example of “sprinting when necessary.” In 2007, I was on a project that was going very well. The team produced what was necessary in every iteration, we had a known velocity, we could estimate new stories well, the code base was in good shape -- in short, the team was grooving.
One day, a user story was submitted during an iteration by someone who insisted it had to be by the end of the current iteration, which required us to get it done that day. The project lead came up to me and asked if I could get it done in a day. I started to debate in my head if it was possible, but then he interrupted me and said something to the effect of, “could you get it done today if I got you a case of your favorite beer?”
I got it done, and my project lead held to his promise.
Here’s my point: Projects can’t be continuous sprints. That’s just not sustainable over the long haul. Projects that are in good shape move along at a consistent, marathon-like pace. This reduces the chance that team members will burn out and never get to the finish line.
However, we also need to recognize there will be times when a new feature needs to be added or the project itself may change direction mid-flight due to unexpected events like market changes or financial adjustments within the company. We should be able to adjust and rise to sprint-like efforts so long as we know that trying to move at that velocity is not sustainable over the long haul.
Furthermore, this only works if the team is healthy. If the team knows what it can produce, has a strong architecture in place and can make changes in a predicable way, it can make those jumps to “overdrive” status when needed without upsetting the overall flow of the work.
Finally, giving some kind of reward to those who have to push hard never hurts. Until next time, happy coding!