Software Development Analogies

Imagine you’ve been told that you have to climb a mountain. You’re told to expect cold temperatures and steep terrain, and that it’s a “medium-sized” mountain, but not much more than that. You are handed climbing supplies, then driven out to the base of a large, rocky peak stretching out into the sky.

As you approach you are asked two questions:

1. When will you reach the top (specifically, the day and time)?
2. What path will you take to get up the mountain?

You feel a little resentful at even being asked the first question. You’ve never climbed this mountain before! You are not entirely sure what to expect, or how fast you’ll make progress. You’re sorely tempted to say “I’ll reach the top when I reach the top!”

Since you can only see a few hundred feet ahead of you, the second question seems just as impossible to answer. Ideally you’d make a straight line up the mountain, but it’s very likely you’ll have to do some zigzagging, circling, and even backtracking to get around unforeseen obstacles.

Then you’re given two more pieces of information:

1. A helicopter is awaiting orders to drop off food and camping supplies at various points up the mountain. The quantity and placement of those supplies are based on your answers to the previous two questions.
2. The helicopter will swing by the top of the mountain to pick you up—at your specified time and date. Oh, and the helicopter is only available for a maximum of three days—you cannot exceed that amount of time to reach the top.

By this time, thoughts of starvation and being abandoned on the mountain are starting to put you in a dark mood. You need a perfect plan, that works perfectly, to survive this expedition—but you don’t even know how high the mountain is, or what the climb will be like. Meanwhile, your mission commander is getting impatient with you. Although not a climber himself, he really can’t see what the big deal is, and he doesn’t want to hear any excuses. He’s climbed the rock wall at his gym, and more than a few ladders in his day, and he’s not convinced that this is any different. It’s a simple formula, he shows you: estimate how many feet you can climb in a day, and divide it by the height of the mountain--it’s not rocket science.

Looking over his calculations, your first thought is that he’s underestimated the height of the mountain—by half. Not wanting to upset him, and second guessing yourself a little, you suggest increasing the height estimate by 50% as a compromise. He’s also projected a climb rate that seems quite optimistic—a very brisk ascent. You, on the other hand, drawing from your past climbing experience, ponder several scenarios that could slow you down:

• What if I get injured?
• What if the weather turns nasty?
• What if go one way only to run into an obstacle, and I have to backtrack a lot to find another way?
• What if there are wild animals that I’ll need to avoid?

Taking these things into consideration, you decide to be conservative in estimating how many feet you can climb per day. Unfortunately, you now project that you won’t reach the top for five to six days! Your mission commander looks at you incredulously. “That’s as fast as you can climb?” he asks, in a somewhat insulting tone. “What’s the matter—do you have a bad leg? Do you have to stop every few hours to take a nap? Maybe you just don’t know how to be efficient!”

Feeling a bit shamed, you hastily revise your estimate, assuming no bad luck, eliminating planned breaks and reducing your sleep hours to 5 per night—while wondering in the back of your mind if fatigue will wear you down and ultimately offset the increased hiking time. Maybe things will go better than you think (you hope).

Just as you’re gearing up to start your hike, you’re notified of another condition: you’ll be hiking with a team. You’re relieved at first, thinking of all the extra help and support you’ll have on the way up. But then you realize it introduces some complications as well. You have to move as a team—which means your speed will be dictated by the slowest climbers in the group. You’ll also have to collaborate on the best path forward—hopefully there won’t be any time-killing debate! In addition to climbing, you’ll need to keep constant watch on each team member to make sure no one gets lost—and the leaders at the front of the group will need to communicate the terrain to those in the back. You’ll also need to keep up morale since your three-day ascent calls for an exerted effort.

Sound like a fun adventure? I dreamed up this simple analogy to illustrate some of the challenges faced in planning and executing a software project. Being given a project of uncertain size and complexity, weighing risk factors, being asked for or given schedules which must be met, being pressured by superiors, dealing with group dynamics—hopefully this conveyed some of the thoughts, emotions, and challenges experienced by teams that do this on a daily basis.

My inspiration for this analogy comes from one of my Agile mentors, Mike Cohn, who named his company Mountain Goat Software. A mountain goat takes a naturally Agile approach to getting up a mountain: it takes a few steps, checks its surroundings, then takes a few more steps. It’s “inspect and adapt” in a nutshell—until the goat makes it all the way to the top.

In my analogy, the prospects for success seem grim. What are the odds of the team finding the food and supply drop-offs? What are the odds of the team making it to the top within their three day window? Yet many software teams are faced with similar quandaries in dealing with the demands of their business, their clients, and their superiors.

I used to avoid making analogies to software development, because it’s impossible to find “one” analogy that encompasses it. Software development is unique and complex—there’s no one analogy to it because there’s nothing else fully like it. That doesn’t stop people from trying—I’ve heard analogies of it being like building a car, writing a book, designing a house—you name it. The problem is that the bad analogies are so harmful that it’s worth coming up with some good analogies—even if none of them are complete—that can at least do justice to certain aspects of software development.

While my mountain climbing analogy illustrates some of the planning and management issues of a project, I would use different analogies to illustrate concepts like technical debt, or agile process, or modular architecture, which require different perspectives. I believe this is the proper antidote to the trend of comparing software development to a manufacturing process—an analogy which is simple to make, but entirely incorrect and damaging in its implications. Our search for “one” analogy causes us to oversimplify something which is just not that simple. In our quest to make analogies, we seek to make things easier to understand—but we must also make understood that software development is an endeavor of many aspects—each of which has its own story.

Comments

[Lava Infotech]

Software Development
Thanks for providing such informative blog, you have nice post here. I will be back soon. continue this hard work, people will be appreciate you like me.