Shoot This Engineer

"There comes a time in the life of a project when you have to shoot the engineers and put the dang thing into production."

I heard that saying years ago; I can't find the original attribution because it's been cross-quoted all over the Web, but it really applies to me these days. I've been picking away, tweaking this document, then that document, constantly edging toward perfection but knowing I'll never get there. Meanwhile, other stuff is piling up all around me. So I decided that it's time to shoot the engineer and get on with the next steps.

The bulk of the changes happened because I'm simply a more experienced writer than I was five years ago. The PTTQ is new, and I've significantly beefed up the SQAP and SCMP, but it was mostly better grammar and clearer writing that drove me to micro editing. The current documentation set represents Shell Method v1.1.

The biggest change from Shell Method v1.0 is the redefinition of the life-cycle from a traditional waterfall to an iterative life-cycle inspired by a blend of Boehm's old Spiral with Agile methods. In essence, the iterative life-cycle is "Big Design Up Front," as Joel Spolsky likes to put it, but tightened up to the point where it's more like Lotsa Little Designs Up Front, which gives it more of an Agile flavor than anything else.

The Umbrella documentation set has been released at v1.0. This is the documentation set that comprises all the main reference sections and process definitions for the Shell Method:

• Glossary of Software Engineering Terms
• Software Development Life-Cycle (SDLC)
• Software Configuration Management Plan (SCMP)
• Software Quality Assurance Plan (SQAP)
• Project Team Training and Qualification Plan (PTTQ)

I find it ironic that the first template set to be released on dbtemplates.com is the one set that I hope is purchased the least. In fact, I priced it pretty high (relative to the other document sets) in order to discourage folks from taking that path first. If you're purchasing this set, you're not using shellmethod.com as your process repository anymore, and I hope that won't be the case for most Shell Method developers.

The whole idea behind this effort is to provide an open process and repository so that a community of developers can form around the methodology. Once that happens, we can pool our metrics to form a viable empirical model for database project sizing and estimation. Once we have that, we'll really have something, won't we?

-Z-

Software process and climbing

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.

-Z-