Practical Programmer
Curtis or Soloway, or see my discussion in my recent book
Software Creativity 2.0 (that
discussion is found in the chapter
“Creativity and Software Design:
The Missing Link”).
Now, all of that understanding
of design that Curtis and
Soloway produced was almost
monumental in its scope. We
now understood, in very believable ways, that software design as
practiced by its experts was a
trial-and-error iterative process.
This may not have been a terribly acceptable discovery to computer scientists who presumably
had hoped for a more algorithmic or prescriptive approach to
design, but to software designers
in the trenches of practice, it
rang a clear and credible bell.
That summarizes the mostly
good news I mentioned in the
first paragraph of this column.
But now here’s where the bad
news takes over.
As I mentioned, it was the
expectation of Curtis and company that, once they learned the
true nature of software design
from their studies, they would
then package some kind of
design solution approach (be it
process and/or tools) and pass it
on to practitioners. In fact, that
was the rationale given for the
funding that allowed those wonderful research studies to be conducted in the first place. The
MCC would be known, throughout the software engineering
world, as the place to go for help
in solving the problems of software design.
But it didn’t work out.
Remember that essence of
design, the iterative process, I
discussed earlier in this column?
Well, all of it happened inside
the mind, at the speed of human
thought. Attempts to enhance
the iterative process, such as by
jotting down notes or even using
computer-based tools, simply
slowed the process. The mind
could do things much faster than
the hand could record its workings, and speed was of the
essence in that highly iterative,
somewhat complicated process.
I remarked at the time that
what we needed was a mind
amplifier, a computer-based tool
that could record all those wonderful workings of the mind as it
went through that iterative
process, and convert what it
recorded into the results the
mind would eventually produce.
Big HA! No such tool was available, even in the minds of the
artificial intelligence scholars of
the day.
My computist-in-training son
even envisioned a solution, based
on my imaginings, of a main-frame computer on wheels that
would be hard-wired into the
mind of the designer and would
follow him around. Even bigger
HA! The idea was as laughable
then as it is now.
But wait! A recent issue of
ACM TechNews included the
headline “scientists use monkey’s
brain signals to control robot”
[ 1]. The author of that article,
and the scientists who had conducted the research, were excited
about the prospect of using brain
signals to control robots, so
that—for example—paralyzed
people might be able to use their
thoughts to move their bodies.
And that’s a hugely laudable
application of such a technology. It
could be life-enhancing in unimaginable ways to paralytic or severely
motor-impaired individuals.
But I couldn’t help but think
back to the dreams of Curtis and
Soloway, and mine, and even my
son’s, to provide computer support for the software design
process. Like so many other wondrous applications of computers
over the decades, we may at last
be on the verge of finding a way
to transfer those design discoveries of Curtis and Soloway into
something the practitioner software designer can actually put to
use.
I’m not holding my breath,
but I find the prospect pretty
exciting. Perhaps all that big HA
stuff will not be so funny after
all. c
REFERENCE
1. Gaudin, S. Scientists use monkey’s brain signals to control robot. Computerworld Careers
(online), Jan. 16, 2008;
www.computerworld.com/action/article.do?c
ommand=view-
ArticleBasic&articleid=9057319.
ROBERT L. GLASS ( rlglass@acm.org) is the
publisher/editor of the Software Practitioner
newsletter and editor emeritus of Elsevier’s
Journal of Systems and Software. He is currently
an honorary professor in the ARC Center for
Complex Systems at Griffith University,
Brisbane, Australia.