Long IT rule 5: Take small steps

Much has been made of the Kenyon dominance of marathoning. Few doubt that it would extend to ultras if there was any money in it. As there isn't, ultras still enjoy a reasonably heterogeneous set of elite runners. One thing all of them have in common with the Kenyans, however, is a high turnover. Typical recreational runners take between 140 and 170 steps per minute. More serious middle distance runners are closer to 180. That used to be the norm for marathoners as well.

Then the Kenyans came. The first thing that struck most coaches was that their stride rate was so much faster than other runners traveling roughly the same speed. Sometimes as high as 200 steps per minute. It's not hard to see how this came to be. Growing up, many Kenyans run 10-15 miles to school each way with no shoes. That will do a number on your feet unless you develop a very fast, light stride with very little landing shock. Children who run barefoot in other countries develop similarly fast cadences.

The light strike from taking short steps really starts to pay off the longer the effort goes. In a short effort, you can afford to be a little inefficient as long as you're getting some extra power in return. In a long event, every exertion counts. By taking shorter steps, each individual step is more precise, more in line with the one before it. Adjustments due to bad footing are minimized. Most importantly, the shock of landing is significantly less because you haven't been in the air as long. Perhaps counter-intuitively, a short stride actually has you spending more total time in the air because it's easier to bounce off a light landing and get airborne again quickly.

The long IT equivalent of the short step is to keep each individual task short. There are some things, like procuring hardware, that may require long lead times, but the actual work should be broken into things that can be done in just a few days. Certainly, any task that takes longer than a week is a potential project killer.

Developers tend to rail against this sort of thing, claiming it's more efficient to make all modifications to a piece of code at once rather than repeatedly update it. Theoretically, this is true, but in exchange for that, you loose the ability to make quick adjustments if it turns out that jamming that extra bit of work in there was a bigger deal than realized (and it almost always is).

Along with the running analogy that we're currently beating to death, I like to think of project management as driving on ice. As long as you are making adjustments quickly enough that you never have to do anything drastic, you can go pretty fast. But, once you need a big adjustment, you're in big trouble. The only way to keep the adjustments small is to have reliable and tangible feedback (as in, a working piece of code; not one that is "almost done") at short intervals. That means short steps, and lots of 'em.