Communications of the ACM, December 1997, pp 113--114, "Technical Opinion"


			Programming as a Discipline? 


Nigel Ward (nigel@sanpo.t.u-tokyo.ac.jp)


Programming is not just an activity, it's a discipline, with its own
value system --- or so I believed.  This article describes a
experience that shook my faith.

A few years ago I started to build a system for understanding speech.
I wanted to do so in part because speech understanding seemed to be an
area where I, as a Programmer, could contribute.  Of course there are
already hundreds of people working on speech recognition and
understanding.  But the predominant research style in speech is an
Engineering one \cite{roe-wilpon,arpa95}, which seems to lack
several qualities which a real Programmer could provide:


-- One missing element was {\em ambition}.  Rather than aiming to
incrementally improve an existing system to achieve a slightly lower
error rate, I aimed at an optimal model; that is, a prototype of an
architecture powerful enough to support optional interpretation.

-- The key to this seemed to be the full {\em integration} of different
sources of knowledge.  That is, to make sense of speech signals, noisy
as they inevitably are, I aimed to exploit syntactic constraints,
semantic preferences, the local context, etc., seamlessly and online
as the input is received.


-- The best way to arrive at an architecture for this seemed to be {\em
introspection}.  Since humans can understand speech, I aimed to build
a system that mimicked that process.  To do so, rather than undertake
a full scientific investigation of how people understand, I took the
simpler approach of just imagining what I would do, if someone handed
me a speech signal and asked me to figure out its meaning.

-- Finally, to produce an extensible system, I aimed for a clean, {\em
aestheticly pleasing design}, specifically, one that was modular,
declarative, parallelizable, etc.


That, in a nutshell, was what I thought a Programmer could contribute.

And many people agreed that this was a good research strategy.  I
remember one computer science conference where I outlined my goals and
plans and a hundred people were nodding in understanding and agreement
at every point.  At speech conferences, on the other hand, my
presentations were received coldly, although I didn't understand why.

Anyway I set to work, fleshing out and implementing my vision of the
ideal speech understanding system.  After three years learning and
building and debugging, I had a system that worked, taking speech
inputs from a microphone and outputting representations of their
meaning \cite{snl-wkshop}.

I then evaluated its performance.  It was terrible.  It was completely
outclassed by the systems built by plain old Engineering approaches.

Re-reading the literature showed that my attempt was not novel, and
neither was my failure.  There have been many similar approaches to
speech understanding, as surveyed in Klatt (\citeyear{klatt}) and Ward
(\citeyear{second-thoughts}) --- after exciting starts, all have faded
away without achieving much.  The reasons for this include specific
technical aspects of the speech understanding task, as discussed
elsewhere \cite{second-thoughts}; but the root cause of the failure
lies, I believe, in the value systems of Programmers.

The specific aspects of Programming which led me and others astray
were, in fact, the four points above.  To recapitulate, making the
contrast with Engineering practice clear: 1.~Ambitiously wanting to
build a radically new, high performance, general purpose system
straight off, rather than accepting the need to build up know-how
through a succession of limited but useful systems.  2.~Prizing full
integration, rather than just the amount of integration worthwhile
\cite{moore94}.  3.~Aiming at introspectively plausible processing,
rather than identifying real issues.  4.~Relying on aesthetic
principles of design, rather than just designing a system to get the
job done.  These are discussed further in \cite{me-jetai}.

Of course, these tendencies are not invariably bad.  They often pay
off, and so have become some of the core values of the Programming
community.  {\em Ambition} is important in a fast-moving field. {\em
Integration} is an obvious good, to the millions of people who work on
systems to get information from where it is to where it's needed.
{\em Introspection} also is often useful, as seen by the multitudes of
communications protocols, operating systems, etc.~which exploit
anthropomorphic metaphors.  {\em Principled Design} is another obvious
good.

But these values and tendencies are not infallibly useful.  They have
led astray many researchers in speech understanding, and in other
fields too.  In Human-Computer Interaction, in Artificial
Intelligence, and in Robotics, it can been argued that a Programming
mind-set is often a liability
\cite{newman94,paul-cohen,brooks-reason}.

Software, as a relatively new field of human endeavor, allows a new,
more exciting methodology than plain old Engineering.  In my software
classes, therefore, I always tried to instill the students with a
sense of Programming as a Discipline, complete with its own mind-set
and values.  But the experience with speech understanding has humbled
me.  Maybe Programming should, after all, be considered not a
discipline, but just a skill, like writing or drawing.  And maybe we
should train students to be Engineers, etc., who can program, not
Programmers as such.

\bibliography{/home/sanpon/nigel/z/bib}