“Programmers are smarter than sprinters, we just fire off the gun every 100 yards.” – Rich Hickey, Simple Made Easy
It’s important to know when you’re sprinting, and when you’re marathoning. Agile practice uses a term like “sprint” to mean what really is an iteration. Sprint and iteration might mean the same thing to you, but they really should be separated.
When you’re sprinting, you’re pushing your limits to the max in a short period of time. Sprinting means optimizing for high speed in a small time window. A sprint is a large burst of energy that’s expended quickly. Contrast that with a marathon, where the race is about cadence and rhythm, consistency and continuity. If you watch a sprinter race, and then watch a marathoner race, you’ll observe entirely different spectacles. They’re entirely different races.
When I ran cross country in high school, one of the most important skills to master was consistent cadence. My coach would place people along the race course at certain mile markers to call out our times. The goal was to have each leg of the race be consistent with every other leg. If you were running a 6 minute mile in the first leg, you wanted to be as consistent as possible through each leg, with the possibility of shaving a few seconds on each one.
That was a fixed distance race, where I knew I had to run just 3 miles and then I was done. I knew that even if I went really hard for 3 miles, I wouldn’t collapse if I ran too fast. I could plan my target speeds ahead of time.
The racing distance of most software projects often ends up being longer than a marathon. What’s worse, most software projects don’t have a fixed distance that everyone has to race. Keep going until we win. When do we win?
Most software projects aren’t aware of this dilemma. You have a race that could go on for years, but it’s anybody’s guess as to how long it will actually be. How do you pace your race? How do you decide how fast to go? Is there a time to run like crazy and a time to slow down and recover?
Imagine a long distance runner entering a race. It’s a unique race, in that when you decide to enter, you don’t know how far you have to run. 100 meters? 5K? 10K? Marathon? All the runner can do is try to look at their surroundings, look ahead on the course and try to estimate based on what the course looks like. Does it veer onto the road and snake off into the distance, or does it loop around a small and confined area? When the gun goes off, is the runner going to sprint as fast as he can? No, he’s going to run at a pace he know he can sustain for a long time. After all, he might be running for another 50 miles. Sprinting for 50 miles is not going to work. This is the same ambiguity that surrounds most software projects.
If you know your software project is only going to be around for a few months, by all means sprint as fast as you can. Pull late nights, code all day and crunch crunch crunch. Burn and churn baby. But as soon as you realize that you’re in this thing for the long haul, it’s time to start thinking less like a sprinter and more like a marathoner.