To really foul things up LO4990

Eric Opp (eopp@mrj.com)
Fri, 19 Jan 1996 20:34:37 -0500 (EST)

Replying to LO4951 --

On Thu, 18 Jan 1996, Gray Southon wrote:

> Hank
>
> You speak of the Capability Maturity Model. It seeems to me to be a highly
> mechanistic, production-line inspired techology misapplied to innovative
> human systems. Is there any basis for this conclusion, or has CMM proven its
> worth? I would be very interested in discussing it further and detailing my
> analysis.
>
> -----
> Host's Note: Hank can you (or anyone else) say a few words about the CMU
> Capability Maturity Model. I know it's about software development and I
> suspect it has relevance to org performance, not just software.
>
> I'm thinking that if level 1 is "ad-hoc" in systems development, then it
> would be "reactive fire-fighting" in general org performance, and that
> the analogies with the other levels might be useful.
>
> -- Rick Karash, rkarash@karash.com, host for learning-org
> -----
>
> >To use the Carnegie-Mellon Capability Maturity Model, for
> >instance, the organization has to move at least from level 1 (ad hoc) to
> >level 3 (defined), and preferably to level 4 (managed) to even think of
> >implementing object technology in any meaningful way. [If you are
> >unfamiliar with this model, email me for a synopsis.]

In responding to our host's request and to the post:

The Capability Maturity Model is a way of ranking a software
organization as to the maturity of their software production process.
Among software engineers, especially the younger ones, there is great
resistance to such a framework, because they consider the creation of
software to be one of the "ultimate" creative challenges and tasks. This
attitude is dead wrong!! Why?

1. The production of the automobile and many other high quality consumer
goods started out the way software did. A lone inventor (programmer)
assembled the automobile (program) in his workshop (garage, bedroom,
university computer center etc.). Yet no one today would dream of
attempting to produce a car from scratch in his or her garage. This is die
to the fact that the "production process has matured to the point that a
well defined high quality production process exists, which allows input
from many many different individuals (production line workers) without
sacrificing the quality of the end product. That is to say that the
software production process can be defined well enough that a high quality
product can be produced.

2. Along with the creative aspects of software, there exists this myth,
which has often been self-proving or self-fulfilling for the young
software engineer, namely the project that was complete by a 24 hour stint
in front of the terminal often in the last days before a major project was
due. This has led to the professional myth that a lone, anti-social,
living on nothing but sugar and caffine super-programmer can miraculously
pull a programming project from the jaws of defeat in the last nights
before delivery. This works great for small programming projects, but
never for team efforts. As a matter of fact, Fred Brooks in his book "The
Mythical Man Month" dispelled this completely for larger software
projects. AND, we all know that such an attitude goes completely counter
to all that we are trying to achieve with a learning organization.

3. In taking the analogy to the automobile, the creativity lies in the
design and NOT the execution. Similarly, with software projects, the
software professionals SHOULD concentrate their creativity on the design,
but the actual execution should be a relatively mundane, well defined,
high quality process as the automotive assembly line is.

4. The last remaining foundation of the argument against any defined
software process by those that believe in "The Myth" is that a well
managed software process requires a metric as a basis. Since physical
measurements are often the basis for quality in the automotive assembly
line, quanitfying quality is relatively easy. What do you measure with
software? How do you define lines of code? ..... Which simply leads to the
argument that it is a purely creative process that one cannot measure.
This is also wrong, because all you really need do is define SOME metric
and use that as a basis for your measurements - akin to simply choosing to
measure part tolerances in in. or cm. as long as all measurements are made
in the same units.

Sorry for the length of the response to the original post! The
Capability Maturity Model consists of five levels, which I will describe
below:

Level 1: Ad hoc or chaotic. Most software organizations are at this
level (see above). There are no well defined software production processes
and success depends largely on individual effort.

Level 2: Repeatable. At this level some basic project management
structure has been put on the software process. This project management is
focused on the software process more than the traditional time and
financial tracking. I.E. effort and energy are focused on making accurate
estimates of effort required for tasks both for the individual programmers
and for the group as a whole. This point is important, because projects at
Level 1 will sometimes come in on time and on budget, but no consideration
is given to the fact that the programmers have worked 24 hours a day 7
days a week for the month before delivery!

Level 3: Defined. At this level, the software process is well defined,
documented and standardized. All projects are tailored to fit into this
standard software production process.

Level 4: Managed. The focus at this level is the beginning of data
collection on actual quality and "yield" of the software process. At this
point the production and level of quality of software is understood.

Level 5: Optimizing. At this level, the measures that were established
and understood at Level 4 are used as a feedback mechanism to optimize the
process.

You see very quickly the analogy to a standard industrial production
process only that we have been producting industrial products and managing
the production process for nearly a century - not so for software, but
there is no reason not to.

--
    Eric N. Opp

MRJ Inc. eopp@mrj.com