What is your view of creating prototypes, and particularly on the question
of how faithful a prototype needs to be
to resolve the really tricky details, as
opposed to just enabling the marketing department to get screenshots so
they can strut the stuff?
Signed,
an (a)typical engineer
Dear atypical,
What do you mean by “formerly known
as trial and error”!?! Are you telling me
that this fad has died? As far as I can
tell, it’s alive and well, though perhaps
many of its practitioners don’t actually know their intellectual parentage.
Actually, I suspect most of its practitioners can’t spell intellectual parentage.
Alas, it is often the case that a piece
of good advice is taken too far and becomes, for a time, a mantra. Anything
repeated often enough seems to become truth. Mr. Brooks’ advice, as I’m
sure you know, was meant to overcome
the “it must be perfect” mantra that is
all too prevalent in computer science.
The idea that you can know everything
in the design stage is a fallacy that I
think started with the mathematicians,
who were the world’s first programmers. If you spend your days looking
at symbols on paper, and then only occasionally have to build those symbols
into working systems, you rarely come
to appreciate what happens when the
beauty of your system meets the ugly
reality that is real hardware.
From that starting point, it’s easy
to see how programmers of the 1950s
and 1960s would want to write everything down first. The problem is that a
piece of paper is a very poor substitute
for a computer. Paper doesn’t have odd
delays introduced by the speed of electrons in copper, the length of wires,
or the speed of the drum (now disk,
soon to be flash). Thus, it made perfect
sense at the time to admonish people
just to build the damned thing, no matter what it was, and then to take the lessons learned from the prototype and
integrate them into the real system.
The increasing speeds of computers
since that advice was first given have
allowed people to build bigger, faster,
and certainly more prototypes in the
same amount of time that a single system could have been built in the past.
the idea that you
can know everything
in the design stage
is a fallacy that
i think started with
the mathematicians,
who were the world’s
first programmers.
The sufferers of prototypitis are really
just chicken. Not putting a line in the
sand is a sign of cowardice on the part
of the engineer or team. “This is just a
prototype” is too often used as an excuse to avoid looking at the hard problems in a system’s design. In a way,
such prototyping has become the exact
opposite of what Mr. Brooks was trying
to do. The point of a prototype is to find
out where the hard problems are, and
once they are identified, to make it possible to finish the whole system. It is
not to give the marketing department
something pretty to show potential
customers—that’s what paper napkins
and lots of whiskey are for.
Where do I stand on prototypes?
The same place that I stand on layering or the breaking down of systems
into smaller and smaller objects. You
should build only as many prototypes
as are necessary to find and solve the
hard problems that result from whatever you’re trying to build. Anything else
is just navel-gazing. Now, don’t get me
wrong, I like navel-gazing as much as
the next guy, perhaps more, but what
I do when I delve into my psychedelia
collection has nothing, I assure you, to
do with writing software.
KV
George V. Neville-Neil ( kv@acm.org) is the proprietor
of Neville-Neil Consulting. He works on net working and
operating systems code for fun and profit, teaches courses
on various programming-related subjects, and encourages
your comments, quips, and code snips pertaining to his
Communications column.
