2010
Suppose the Ringmaster in the movie Dumbo says, "say, the little elephant can fly, and he's holding a feather. Let's get feathers for all the big elephants so they can fly too!"
This is changing the sign to attempt to alter the signified.
It doesn't work.
Some managers attempt to apply Capability Maturity Models this way. Do not dishonor this fine work by using it backward.
Melanesian 'cargo cults' believed that if they built imitation docks, landing strips, and warehouses, the spirits of their dead would bring cargos of modern goods for the cult members. They believed that if they adopted the signs of prosperity, painted their faces white, wore castoff uniforms, and threw their money in the sea, the goods would be delivered.
This is changing signs to attempt to create the signified.
It doesn't work.
If they'd had a checklist, they would have tried to get everything marked off.
It's very tempting to try to measure aspects of the programming process, and to correlate these measurements with quality. People espouse
The common approach here is to stuff a big load of programs into the blender, puree, strain out the semicolons or whatever, and weigh. In other words, to try to learn something about a big system of programs without actually reading and understanding them all.
This is changing the sign to attempt to alter the signified.
It doesn't work.
The hidden assumption is that "one line of code is like another," or "one programmer is like another." That is, maybe they're not homogeneous, like gravel, but their properties are similar enough to be averaged, and their difference will cancel out in the mass. There is no evidence for this; repeated failures using this theory suggest that it may not be true.
I've been sucked into blender management, and then figured out that I was doing it, and moved on, several times.
I want to work at an organization that produces high quality software as a result of a pervasive culture of quality. Such an organization will probably have a high Maturity Model score as a side effect of its ability to produce good work. Specific practices are good if they help us create the software we intend.
Learning to write good software is a lifelong journey for each of us. Making this trek with others can help or hinder, depending on how well the team gets along.
A particular Maturity Model level is a milestone on such a journey, not a destination. It's a mistake to set out to get to such a milestone: better to set out to go far, and pass the milestone because it is on your route to the destination. People and teams may take different paths to their goal, and visit milestones in different orders, and have different sets of milestones.
An organization's excellence, seriousness, and commitment to quality will have many noticeable signs. The checklist items attached to Maturity Model levels measure some of these signs objectively, and this measurement process is useful as a way of keeping track of progress and eliminating misrepresentation and wishful thinking. I have no problem with the usual checklist items, but focusing on checking them all off may lead to a culture of passivity and defensiveness with respect to development practice, or to rigidity and resistance to continuous improvement.
Many of the best practices identified by Maturity Models are about not making avoidable mistakes. A team can produce timid, uninspired, useless software with the best process in the world. (A rigid and heavy enough process, supported by buggy and inflexible tools, can extinguish progress entirely. Been there, done that.)
A team with a commitment to excellence will go beyond "not making mistakes" and try to achieve positive value. The great trapeze artists do more than avoid falling; they produce great performances.
Copyright (c) 2010 by Tom Van Vleck