Re: Deming and software development

["Jonathan Siegel" <jmsiegel.info.research@worldnet.att.net>]

My experience has been mostly with developing client-specific applications
involving
research databases -- software that supports business decisions --  so I
don't
claim any general knowledge of all software classes. I've liked Weinberg's
work very
much. I've also liked much of William Inmon's work (although I don't always
agree with
Inmon's approach.)

My attempts to apply Deming have generally led me in the direction of using
numbers less, not more, in gaining a picture of what is needed. I've
found the qualitative aspects of Deming's ideas most fruitful. Key
notions I've tried to use include the importance of knowledge, the
definition of quality, the idea of a system, the Shewhart Cycle, and a
concept of overcontrol.

1. System diagram; Quality as fitness for use;

To me, Deming's system diagram is an important tool in development. It
suggests that a development team should make it their business to gain an
understanding of the context in which their product will be used and of
larger system and
business process it will be a part of before building it. -- who uses it,
how it gets used, what
they need it for, what their business process is, what's important to them,
etc. If quality as fitness for use suggests that we can't hope to have any
sort of
quality without a real understanding of uses and users. Sadly, many software
engineers still think abstract technical virtuosity is more important than
knowledge of the customer and their needs. In my experience, the
requirements development process -- the stages closest to "stage 0" -- are
where the greatest improvement is possible.

2. Knowledge-based development.

Traditionally, users are supposed to know what they need and analysts just
translate it into a model. It doesn't work. As Weinberg says, requirements
development is a process of discovery that requires significant exploration.
It requires collaborative teamwork between users and developers.

It's astonishing how many multi-million-dollar software development projects
get started with little more than a handful of meetings and specs written by
an analyst who doesn't really understand what the business is doing. A wave
of dot-coms discovered this in a rather spectacular way over the last couple
of years, but well-established business have had equally expensive failures.

3. Shewhart Cycle = Iterative Development.

A knowledge-based approach manages the risk that comes with not being able
to predict the complex interactions that arise when systems are used.
Deming's answer to the problem is the Shewhart Cycle. By developing in
pieces, prototyping,
spreading out new features across multiple versions, etc., developers get to
see how features work out in practice and get feedback from users -- to
"plan," "do", and "study" --  before committing irrevocably. William Inmon
describes his "spiral" data warehouse development model as an ongoing
process in which developers continually improve the warehouse model in
response to what they learn about how users use it and as users discover new
needs through use. Major systems should expect ongoing, continual
improvement. The whole continuous process needs to be managed as a whole.
 The traditional Waterfall Model -- manage projects separately, spec out
everything in advance, build it, roll out -- is a recipe for failure. It is
based on an assumption of perfect knowledge.

Exception-handling=Requirements Variation

Exception-handling can play some of the same role that variation plays in a
manufacturing process. It is variation in the business model. In complex
systems, it is often necessary to avoid overcontrol. Expecting a system to
account for all possible exceptions and variation can lead to failure,
because we don't have the business knowledge to predict, understand, or
support all
possible exceptions. One way to manage this is to do less, not more, in the
system. For example, if a system attempts to record all possible discount
rules, it will run into the sales rep who makes deals by handshake not in
accordance with the standard rules. Do we want the computer system to
dictate whether that should continue or not? In all too many companies, it
does.

Avoiding overcontrol suggests beginning by automating less. More can be
incorporated into the system when more knowledge is acquired. It also
suggests trusting employees more. The computer is rarely smarter. Yet
Americans habitually try to automate everything. The reason is they treat
the computer as an extension of the Taylor management method.

4. Theory of knowledge

I use Deming purpose-based theory of knowledge to suggest that the design
rules of a system sets up a model for understanding the world. Its users
come to think in the terms it was designed in. The best opportunities for
improvement tend to come in areas where the design theory is no longer
valid. This represents the areas where workers finagle to get their orders
through, and/or managers fail to see something important about their
business because their system doesn't structure data to enable it to be
seen. I apply this principle heavily in data warehousing applications. A
data warehouse, is a model of the way management sees how a company does
business. How it is structured affects what management is capable of seeing.

5. Interaction among systems.

The greatest problems in IT come from problems in system interaction. My
experience matches what Deming would predict. A person responsible for
managing interactions among systems can rarely be a profit center, because
revenues are generally allocated to individual systems. Yet they can be the
greatest sources of complexity, exceptions, and the unexpected.

I don't have a "method" with a specific set of tools -- just some ideas and
ways of thinking I find helpful. Hope this helps.

Jonathan Siegel