mcgregor@hemlock.Atherton.COM (Scott McGregor) (02/21/91)
The recent discussions concerning reusability contained many comments
that ignored or glossed over the importance of thoroughly testing
inherited or other reused code. Underlying these comments seemed to be
the assumption that design failures due to misuse of reused code were
merely due to an avoidable failure (some people might say "stupidity")
on the part of the component vendor ("data sheet not complete enough")
or on the part of the component consumer ("consumer misread datasheet").
There seemed to be some belief that these failures would rectify
themselves over time (the incompetent would be found out and replaced)
and the problem would go away.
I believe that in fact the problems of reusability cannot be so readily
dismissed. I believe that this particular problem is a special case
example of a wider problem of software design in general, and in fact in
the design of complex systems in general. For people interested in
CASE (COMPUTER AIDED Software Engineering) it is curious--have we
forgotten that it is the HUMAN that needs the aiding?
I believe that the reason for the above problems have little to do
with individual's own failings and stupidity, but rather human
limitations in general. In particular, there is considerable cognitive
literature describing the very limited short term memory capability
of the human brain (7 plus or minus 2 chunks). Human long term
memory is known to be faulty; not only are things forgotten, but
often mis-remembered. Human communication is a wonderous thing.
Huge amounts of information can be conveyed succinctly due to reliance
on shared knowledge (common sense reasoning); however we often
mispercieve how much knowledge is really shared by the other individual.
And we often do not communicate with all the people who might be
affected, only the most salient ones who come to mind. This leads to widely
documented cases of underinforming and underinvolvement which often
leads to poor design decisions, and subsequent errors. Lastly, humans
can be extremely good dealing with novel situations, but often their
reasoning becomes error prone in repetitive situations such as adding
up long columns of numbers.
Before computers, other solutions were developed to aid humans in their
attempts to rise above their biological and mental limitations. Books
can get information out of long term memory and are less subject to loss
or degredation than long term memory, and their use frees the reader from
having to remember their contents and allows those precious short term
registers to be used for other things. Many communication technologies
were developed to improve the thoroughness of communication and its
widespread dissemination. Devices as simple as the slide rule and abacus
aided human reasoning.
Now, we can apply computer technologies to some of these problems as well.
Databases can aid with human memory. Networking technologies, including
systems such as net news and hypertext, can help with information
completeness and dissemination. Perhaps most effectively, computers have
been applied to aiding human reasoning with repetative calculations.
If we are to design CASE tools and move ourselves forward, I think we
need to stop ignoring the human element and instead make it central.
To return to the specific case of reusable software components, we need
to understand that we face a challenge for any sufficiently complex component
that either the documentation will be so complete that it will seem too
much to read by most potential users, or the documentation will be incomplete
and confusion and mistakes will be made by the users. At present,
comprehensive testing is required to ensure such mistakes are not passed
to the ultimate consumer. But could we focus on the limitations of the
humans involved and find a way to allow the consumers to handle the greater
complexity of more detailed information? I don't merely mean indexes,
and subject groupings--we have that with books today, and the amount of
information out there still overtaxes these techniques. Maybe others, totally
new can be created, perhaps building on only recently available technologies
like hypertext. This is a really difficult problem--it is not sufficient to
just employ a database and KWIC and GREP. Technical librarians still do
better in most tests from a Type I and Type II error point of view than do
automated retrievals--because of their shared (common sense) knowledge of
the subject areas. How can we improve on their capabilities and make these
widely available? Here projects like CYC might offer new technologies that
could yield solutions for our future CASE builders. Or, perhaps work on
Prescient Agents will yield fruit. Getting a rich set of possible solutions
will improve our chances of finding ways that work for a large set of
people in a large set of circumstances.
I believe that one of the reasons why we sometimes seem to make little progress
in the CASE area is because it is so widely acceptable to ignore the main
source of problems, human limitations, and focus on simply algorithmic
solutions in which people's limitations play no part. Often in fact, the
human is rather enslaved to serve the computer's need in search of some
algorithmic formalism that will rule out human variation.
There has been relatively little focus on real empowerment and augmentation
of human capability in novel ways of late. The mouse, windows, menus
were demonstrated by Engelbart in 1968--now all focus seems to be on merely
reusing the same elements over and over again with little appreciation for
how they will actually affect human ability to deal with complexity through
augmentation of memory, communication or reasoning. I agree with Ben
Schneiderman that perhaps the eagerness to standardize user interfaces to
the point where new ideas are not percieved acceptable is a kind of laziness.
Perhaps it is even another symptom of the desire to paper over the
human factor and get on with algorithmic work.
I say this not because I am in search of a guru or leader to show me how
to get on to the novel solutions. I've been around long enough to know that
if I'm going to follow this direction I can't wait for some leader to come
along--I'll have to just set out with my own human limitations and all and
see where it takes me. I hope that I'll meet a number of friendly fellow
travelers along the way.
For those of you who have hung in here for this whole long thing, thanks.
As a reward, let me leave you with a pertinant joke concerning a similar
profession often accused of ignoring the human details:
A physicist, a chemist and an economist were stranded on an atoll
with just one tree and a few cans of beans. How to get the beans out of
the can? The physicist suggested that they climb up the tree and drop the
cans on the sand multiple times until the physical stress on the cans caused
them to rupture. The chemist concerned by all that exertion suggested that
they put the cans in the seawater of the lagoon and wait for it to rust the
cans to the point where they could be torn open. The economist (or was he
really a software designer?) claimed all these ideas were too complex and
would take to long. Beginning his own suggestion he stated:
"ASSUME a can-opener. Now it becomes easy..."
------
Scott McGregor
Atherton Technology
mcgregor@atherton.comrst@cs.hull.ac.uk (Rob Turner) (02/28/91)
Scott McGregor writes: >CASE (COMPUTER AIDED Software Engineering) it is curious--have we >forgotten that it is the HUMAN that needs the aiding? But that is what CASE means. Computer Aided Software Engineering ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This means that the human does the software engineering, aided by the computer. It doesn't mean that the computer does the software engineering, aided by the human. If only ... Rob