[net.cog-eng] a panacea for all seasons

keith@uiucme.uiucme (12/03/85)

The Engineering in Engineering Design
Second of a series


Henry Spencer's comment prompts me to mention exactly what I mean
by structured design approaches.

I do not propose that there is a design method which can solve all
problems.  This seems intuitively true at least.  But I'm not worried
about that, engineers are accustomed to making things work despite
incomplete tool kits.  What is important is to appreciate the
capabilities and limits on the design methods available.

We know that it is possible to design incredibly complex systems
and turn them into operating units.  By no means do my comments
imply that human designers don't do good work; on the contrary
human designers are remarkable effective.

But how do they design?  A great deal of what designers know is
not from education or books, it is accumulated experience.  This
kind of knowledge is intangible, difficult to record for later use
by a different designer.  This would be an acceptable situation
if we were continuing to accumulate experience in new designers;
the fact is that modern corporate structures tend to prevent
designers from becoming experienced.  Better pay, better promotion
opportunities, and other reasons are incouraging technical people
into managerial positions by mid-career - JUST WHEN THEY'RE ABOUT
TO BECOME REALLY GOOD DESIGNERS.  Design knowledge is not like
riding a bicycle - you've got to keep exercising it to keep it
in good condition.

Thus the problem statement:  How do we supplement experience
in designers to maintain productivity?  How do we encourage
innovation from designers with poorer qualifications?

Two possible solutions are available.  First, we can develop
computer tools to support designers, allowing them to focus where
the human qualities of intuition and creativity will be most
effective.  Second, we can try to influence management attitudes
to allow good designers to stay in design work.  My interest is
in the first method; I think the second will be a natural result
of a better understanding of the nature of design knowledge.

When we want to use a computer to participate in design work, we can
either try to understand human design well enough to allow the computer
to understand what the human is doing, or we can try to structure
the design process so that a relatively dumb computer can be
applied as a tool.  The solution I am working toward is a compromise
between these two extremes.

Design is not a algorithmic process.  The process of design is
removing abstraction from a problem statement and removing
abstraction from the corresponding solution statement.  The thinking
process involved depends much more on selecting the right solution
method for the problem at hand than on actually cranking through
the analysis.

So what good is a structured, systematic design method?  It won't
make things easier by simplifying, it will add more information to
be juggled by the designer.  Systematic solutions ("hup, two, three,
four") tend to suppress, not encourage, innovation.

I do not propose systematic design as the final solution.  It is no
panacea, and will bring with it as many problems as it solves.  In
my perception, design knowledge - both problem-solving methods at
large and specific disciplines for design - is a chaotic mess.
Any structured method for dealing with this mess will improve
our chances of continuing to succeed.

I recall reading a conference proceedings where a prominent AI
researcher dismissed structured design approaches (to software)
as useless in every application.  Some years ago I attended a
short course on structured analysis (DeMarco was the text) where
the speaker claimed systematic design is the solution for all
large system design problems.  Neither is correct.

We are at the cusp of two opposing trends - loss of experienced
designers and increasing complexity in the systems we design.  By
adopting a structured approach as an interim solution we can continue
to design and build complex systems without a notable increase in the
rate of failures.  To accomplish this we will, no doubt, sacrifice
some innovative improvements that an old-fashioned, intuitive
designer might have given us.


keith
U of Illinois Mech Eng
{ stuff I don't know } uiucdcs!uiucme!keith

Next installment:  the fallacy of specialism and the chaos in design knowldge