Software process and climbing (9/1/2005)

A while back, I was working my way up a climbing wall when I noticed something that I'd missed all the way back to my days on search and rescue teams: I'm not worried about falling when I'm halfway up a cliff. In fact, I'm not worried about much of anything except the bubble of reality starting at my body and extending about 20 feet. Any more than that, and I'm not concerned. I'm not looking down and going "Wow! I could fall and die!" I'm not thinking about all the moves that got me to my current point, and I'm not worried about all the moves I'll need to make before I get to the top. All I'm thinking about is my current set of holds, and my next few moves.

This may be a key to the problem of adopting formal software processes. The entire picture is incredibly complex. The need to simultaneously manage requirements, specs, builds, tests, schedules, metrics, issues, code, politics, and personnel presents an overwhelming picture. Maybe that's why there's so much resistance to adopting formal processes. Just thinking about implementing the entire picture is like envisioning an entire ascent in detail, and the image of falling comes easily to mind.

When people are executing within a defined process, the route has been planned in advance. The details are different, but the route is the same. The participants are not worried about what has passed and what's in the distant future. They focus on their "bubble," which is the current stage. They know where they've been, and are comfortable in their knowledge that what's coming is clearly defined and familiar. Like the climber, they stay in their bubble, focus on what's happening now, and ignore the rest.

It doesn't have to be Shell Method. Any stable process will produce the same effect. The word needs to get out: People who work within formal processes experience a much more comfortable environment. I believe this is one of the reasons why defects are so much lower than in chaotic development projects.