Re: LO & Software Development LO961

John R. Snyder (jsnyder@bga.com)
Thu, 27 Apr 1995 02:28:37 -0600

Replying to LO915 --

Paul DesRosiers LO868 and Beth Clark LO915 both asked about LO ideas in
software engineering organizations. Beth also asked about the SEI
Capability Models.

This is an interesting question. I recently went back over four years of
attendance records for the annual Systems Thinking in Action conference,
looking for patterns. I noticed that many respresentatives from the
insurance, health, manufacturing, semiconductor, and pharmaceutical
industries had attended consistently over the years. There were a few
major computer manufacturers -- it was hard to tell if the software "side
of the house" had been in attendance. Conspicuous by their absence or
near absence were many of the well known names in software engineering:
Aldus, Microsoft, Borland, Lotus, Novell, Apple, Sun, Silicon Graphics,
ParcPlace, Oracle, etc. Also missing were the older engineering
organizations in which Software Engineering was born and for whom the SEI
Capability Models are arguably optimized; e.g., TRW, Hughes, CSC, IBM
Federal Systems, NASA, Boeing, etc.

Now I'll be the first to admit that this is not a very scientific
procedure for measuring "penetration" of LO concepts into the Software
Engineering world, but I do think there's a pattern here. I know that
some of these organizations have engaged with TQM to various degrees, and
some of them are trying out reengineering. So what is the bottleneck with
regard to LO concepts?

My own tentative answer, based on long association with the software
industry, is that these software development cultures experience most LO
ideas as too "soft," too philosophical, too slow. To be sure, a few
people in each software organization seem to "get it," and a few more are
excited by the idea of building systems dynamics models on their PC's, but
most seem to have trouble seeing the relevance of OL. I would be very
interested in hearing from others who have data either disconfirming or
supporting these conjectures.

As for the relationship of the SEI models to LO concepts, I see some
potential overlap. The SEI models encourage software process design,
systematic measurement, standards, careful requirements engineering,
software design verification/validation (formal methods in the upper
levels), and strong project management skills. Software project managers
should be interested in LO concepts like team learning, shared vision, and
systems thinking. The concept of mental models is useful in helping to
frame some common problems in requirements engineering and software
design. (Actually, user interface designers were talking about mental
models years before The Fifth Discipline.) I personally am working on
processes for collaborative requirements engineering, software design,
software process design, and quality assurance based on what is
undiscussable or hard to discuss about each of these activities, but I
cannot report results from the field as yet.

One caveat I'll pass on for what it's worth. Software people think of
themselves as systems thinkers. After all, they build software systems,
practice systems analysis, have business cards that say "systems
engineer", etc. However, most of them have never encountered anything
like the systems dynamics techniques popularized by Senge. I have seen
people who could take apart an IBM mainframe operating system and put it
back together again boggle over a fairly simple causal loop diagram. The
reason, I believe, is that software systems techniques tend to focus on
the *static structure* of systems and how to manage the complexities of
scale that arise in large software applications. Analytic modeling
techniques are still more common in the software world than are simulation
modeling techniques. As a result, software professionals are no better
than the standard population when it comes to predicting the behavior of
dynamic systems over time. (This often comes as a shock to them.)
Standard software system techniques are also designed to deal with cause
and effect in highly deterministic situations. And, for very good
reasons, a competent software system design is one that decomposes the
system into a large number of small units and then minimizes the linkages
between those units. In the software world, "everything is connected to
everything else" is the definition of incompetence and disaster. Software
people *will* bring these mental models about systems to their experience
of LO-style systems thinking. The results can be frustrating unless one
is forewarned.

Cheers,

John Snyder
Innovation On Demand
Round Rock, TX
jsnyder@bga.com