Planning a Trip by Iteration

When you’re planning a long hike, you don’t need to plan out every step along the way: you set some milestones that will lead you generally from beginning to end, then at any point along the way you really just need to figure how you’re going to get from where you are to the next milestone. This works well with hiking because you have agility on your side: you can stop at a moment’s notice and turn on a dime.

Sailing an ocean liner* is a little different (*I am not a sailor). Ships tend to have a lot of inertia and if you’re only ever thinking about the upcoming milestone, you might get there and find you’re going full speed in the wrong direction for the next milestone. So you need to look a little further ahead, make sure that the steps you’re taking to get to the upcoming milestone will also leave you in a good state for reaching the one after that (and even further).

A body of software is not as agile as we might like to think. The choices you make to reach the upcoming milestone — how you organize your code, what interfaces you expose, what data you pass where, etc. — give the code inertia which will set you on a path toward, or away from, future milestones.

That doesn’t mean the hiking approach isn’t a good option for software, it just means you need to account for the hidden costs of course correction. If you adopt this model for iterative development, you’re going to be focused almost entirely on the upcoming milestone, and therefore coding things in whatever way gets you there most quickly. However…