Marathons and Software
September 15, 2003
Dave Hoover : Home

For the last few months I have been training for the Chicago Marathon. Every Sunday morning, I do my long run of the week. While alone with my thoughts for a few hours on the prairie path near my home, it has occurred to me that marathon running and software development have some similarities.


I am a novice marathon runner, but I quickly learned that a consistent pace is critical to running a good race. The more I train, the more consistent I get with my pace, and the easier it is for me to predict when I will finish my run. When I run 10 miles, the majority of my mile times are within 20 seconds of each other. For me, the ability to be this consistent began to develop when I purchased a watch and started checking my splits.   A critical software development practice has emerged in the past two decades: iterative development. Iterative development means breaking the development cycle into timeboxed chunks. Working software is the product of each iteration, displaying concrete progress.

When software development teams are asked to estimate delivery dates, they benefit from having a history of iterations to draw upon. By tracking progress in strictly timeboxed intervals, the team's ability to predict is improved.

Sharp milestones are in fact a service to the team,
and one they can properly expect from a manager.
The fuzzy milestone is the harder burden to live with.
It is in fact a millstone that grinds down morale,
for it deceives one about lost time until it is irremediable.
And chronic schedule slippage is a morale-killer.

Frederick Brooks

Time and Distance

A marathon is 26.2 miles. The athlete completes the race when he or she has crossed the finish line. Results are based on time.   Software development projects need a delivery date based on time, not scope. Teams complete as much as they can before they reach the delivery date. Results are based on scope, cost, stability, and maintainability.

Social Influences

One exciting aspect of marathon running for me is the mixture of individual determination with group dynamics. I always viewed running as an individual event, yet I have been surprised by how much of it is socially influenced. While it would be absurd for anyone to try to tell me how fast to run, when I run alongside someone who is faster than me, I find I run signficantly faster than when I run alone. Furthermore, when I run alongside anyone, regardless of her or his speed, I find my pace to be more consistent.   Only a project's software developers can predict the results. When non-coding managers or non-coding architects make predictions or mandate functionality beyond the team's estimates, morale will diminish.

The closer the team can be physically, the more their deveopment speed will normalize. Pair programming in a co-located environment with an on-site customer can transform a stereotypically isolated and individualistic group of programmers into a team.

It's not easy to guess how fast you will go at first,
but it's easy to observe how fast you do go.

Ron Jeffries et al


When something or someone is pushing a runner beyond the limits of their ability for too long, they will inevitably consider cheating. Some running races have "out-and-back" segments of the course where a person could cut off a bunch of time by turning around early. Running requires an internal discipline and inherent pride that comes with finishing within the rules.

From a training perspective, a runner could cheat by skipping workouts or stopping short of the distances they had intended. The repercussions of this cheating will be felt at race time.

  Software development managers are under increasing and continual pressure to complete projects on time and under budget. Due to this pressure, it can be tempting for managers to push developers to increase their development speed. Software developers take pride in their ability to solve problems and will often concede to their managers' wishes, cramming more features into an iteration.

When developers are pushed beyond their natural development pace, they cheat. They stop writing tests first and they stop refactoring. The repercussions of this cheating will be felt when the software is released.

Sustainable Pace

I ran a small half-marathon race last weekend. The pace I have been striving for is just under a nine minute mile. My first mile was under eight minutes. As I looked in surprise at my watch, it was tempting to keep the pace and impress my wife with my time. But I thought again, and over the next ten miles, I scaled back to an 8:30 pace. In my last mile, though, I ran under eight minutes again and finished the race on a high note.   When software development teams are forced to work long hours for extended periods of time they become less productive. Maintaining a sustainable pace means resisting the urge to commit to more than the team has done in the past. A sustainable pace keeps minds fresh and creative, keeps morale and discipline high, and keeps development speed consistent.

Overtime is like sprinting:
it makes some sense for the last hundred yards
of the marathon for those with any energy left,
but if you start sprinting in the first mile, you're just wasting time.

Tom DeMarco and Timothy Lister


Do you not know that in a race all the runners run, but only one gets the prize?
Run in such a way as to get the prize.
Everyone who competes in the games goes into strict training.
They do it to get a crown that will not last;
but we do it to get a crown that will last forever.

1 Corinthians 9:24-25

Home : Dave Hoover Copyright © 2001-2004 Red Squirrel Design, Inc. All Rights Reserved.