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)?
When a process improvement demonstrably reduces the defect rate, the end user benefits with higher quality software at a reduced price. This is absolutely required in the space shuttle, but isn’t it desired in everything else, from our operating system (no blue screens of death!) to our applications? I don’t like kernel panics or having my computer crash from a bad driver. I don’t like losing all my data because a bug shutdown my program. A posse of cowboys can hack out a bad version 1 of their product, but it’s the Big M zombies lead by mature management that engineers the quality software I want to buy or manage our nuclear reactors.
It’s Just a Software Problem
The B-2 bomber wouldn’t fly on its maiden flight — but it was just a software problem. The new Denver airport was months late opening and millions of dollars over budget because its baggage handling system didn’t work right — but it was just a software problem. This spring, the European Space Agency’s new Ariane 5 rocket blew up on its maiden launch because of a little software problem. The federal government’s major agencies – from the IRS to the National Weather Service — are beset with projects that are years late and hundreds of millions of dollars over budget, often because of simple software problems.
Talent does vary by developer — after all, we’re not resources and interchangeable cogs — but we need better processes for developing software. We need process improvement to increase quality, which leaves more time for more features because we’re not consumed by rework issues. We need to reduce the cost of software development, which reduces the price and increases demand.
We need developers to stop thinking all their creativity goes into the code because their creativity should be put into improving how we write code in the first place.
I'm Mark Turansky, I'm the founder of
#1 by Tom on January 7, 2009 - 11:21 am
Quote
I posted a response to this on the Coding Horror website, just under Mike’s comment.
His reading leaves out a key point when it comes to the “zombification” question, which is the clear respect the team members have for each other, and the fact that they are still allowing creativity, but at the process level, not the code level.
You also missed the words “The people here are just of the highest caliber” which blows your point about “Superstars” out of the water. The 260 employees in that company are probably among the best software engineers in the *world*.
A vital point is also skimmed over right at the end. Space Shuttle and Nuclear Power software products are like no other software in the world, in that the
If all 60 million Microsoft end users were willing to pay Microsoft $350 million for Windows 7 to never crash, I’m pretty sure Windows 7 would never crash, especially if it only had to do one thing and was only used by highly-trained end users. And if when it crashed, people died.
To summarize, your example won’t apply to 99% of software products, and Jeff’s point about having respect for the abilities of your employees still applies. Thank you however, for pointing me to a fascinating article.
http://www.fastcompany.com/magazine/06/writestuff.html
Oh, and incidentally, there is no evidence that reducing costs increases demand. Reducing price *might*, but you then have to prove it will increase the demand to cover the loss in profit per item. And if you’re making Space Shuttle software, it won’t increase demand at all.
#2 by Mark Turansky on January 7, 2009 - 11:49 am
Quote
“You also missed the words “The people here are just of the highest caliber” which blows your point about “Superstars” out of the water. The 260 employees in that company are probably among the best software engineers in the *world*.”
But if they are the best in the world and they choose to follow a Big M process, why would the average developer choose cowboy methods when the best of us choose otherwise? Big M process would, in that case, protect the average developer from himself.