The Zombie Horde vs. A Posse of Cowboys

A recent blog entry attempts to paint Big M Methodology as a zombie creating process and quotes Peopleware as the sole evidence of its argument.  You, the poor developer, are turned into a mindless zombie by having a defined process to follow.  You are given no license for creativity, no room for error, and you are discouraged from making mistakes.

This apparently makes you a zombie that must be told what to do and how to do it.  Or, to put it another way, this makes you a grown-up software developer that can write code for the space shuttle.

Fast Company has a fascinating article called “They Write the Right Stuff” that looks into the methodology that produces bug free software.  The software powering the space shuttle has to be bug free or people die.  Quality matters.  It was originally written in the internet stone age (1996), but it is just as relevant today as it was a decade ago.

[The shuttle group] is aggressively intolerant of ego-driven hotshots.In the shuttle group’s culture, there are no superstar programmers. The whole approach to developing software is intentionally designed not to rely on any particular person.

Mindless zombines cannot be superstars! Joel said that only superstars can hit the high notes!  How can bug free software be written by zombies?!  Don’t CMM Level 5 certified organizations (of which there are only a handful in the world) know they need superstars to send space ships into the wild blue yonder?

The blog entry makes the claim that disallowing developers to make mistakes is teamicide.  The blog author further claims that by stifling creativity, management and Big M Methodology shows distrust of their developers which dooms a project in the long run.

Again, someone forgot to tell the guys writing bug free code:

And the culture is equally intolerant of creativity, the individual coding flourishes and styles that are the signature of the all-night software world. “People ask, doesn’t this process stifle creativity? You have to do exactly what the manual says, and you’ve got someone looking over your shoulder,” says Keller. “The answer is, yes, the process does stifle creativity.”

And that is precisely the point — you can’t have people freelancing their way through software code that flies a spaceship, and then, with peoples lives depending on it, try to patch it once its in orbit. “Houston, we have a problem,” may make for a good movie; it’s no way to write software. “People have to channel their creativity into changing the process,” says Keller, “not changing the software.”

An interesting idea arises from Big M: You don’t fix bugs, you fix the process that allowed the bug in the first place.  The shuttle group “avoids blaming people for errors. The process assumes blame – and it’s the process that is analyzed to discover why and how an error got through.”

Capability and Maturity Model

CMM certification is an interesting thing, and I find the wording particularly enlightening:  “Maturity model.”  A CMM certified process is for grown-ups, not start ups.  It’s mature and rational, not for the cowboy coders who stay up all night slinging code from the hip in a heroic effort to ship version 1.0.

Tracking bugs, prioritizing issues, performing QA, and having basic version control and configuration management is the nuts and bolts of Level 2.  Many organizations have these basic project management processes in place and would qualify for level 2 certification. Level 3, though, is Big M Methodology and Process.  Without a defined process (level 3) that emits metrics (level 4), how can an organization possibly attempt to improve development, increase quality, and reduce costs via process improvement (level 5)?

Page 1 of 2 | Next page