Software Descents

Back in 1992 American Programmer magazine published an article by Jim Highsmith that draws parallels between mountaineering and software development. Jim called his piece 'Software Ascents', and - much as I like the content - I think that the title misses the mark: reaching the top of a mountain is often the easiest part of a climb. The tired, cold, or dark descent to safety is the hazardous sting in the tail that truly tests mountaineers to the limit. (See for example the tragedy of Whymper's party on the Matterhorn, the epic of Doug Scott's broken legs on The Ogre, or Joe Simpson's experience in Touching the Void.)
So which part of a software project is like the descent from a mountain summit? Well, on a waterfall project I think that the testing phase represents that long, slow, trek back to base camp: the developers reach their summit at the end of the coding phase only to find that there is a hard slog downwards before the project is finished. And what about an agile project? Unfortunately, agile projects can be even more treacherous: each release - especially the first one - can be mistaken for an opportunity to make the big push to the top. And then you stumble and fall down the descent of the other side.
Trying to 'peak' for each release diminishes your ability to successfully complete the next iteration, or even the next release. So think of the bigger picture and remember to keep some energy in reserve for the descent. You'll be glad you did.