Re: Specification Story

[Jonathan Siegel <jmsiegel@yahoo.com>]

The computer industry has for many years tried to work
on the assumption that programmers can work from
specifications without having to know anything about
the business of the field they are working in. There
are numerous modeling languages for writing
specifications. Most are so precise that they are
incomprehensible to non-programmers: it is impossible
to use them to communicate with a client. This means,
in my view, they are useless. The purpose of
specifications is to communicate a client's needs. If
the client can't understand specifications so as to
meaningfully critique them, their precision has no
value. 

There is, therefore, no substitute for  developers
learning enough about the client so that they can
speak with each other in some sort of common language.
The traditional approach has been to filter this
communication through multiple layers, with
specifications written by specialized intermediaries,
so that the programmers can focus on programming and
need not trouble themselves with business issues. But
we've all heard of the game of telephone.

It's been estimated that about two thirds of all major
software development projects either fail completely
or have to be significantly rewritten. I suspect the
fact that programmers are frequently isolated from the
purpose of their work, and address their client's
needs only through specifications that the client
couldn't understand if he saw them, has a significant
impact on this rate. 

My experience as a systems analyst tells me that
people have ideas about what they want -- they have a
list of problems with their current situation, for
example, or some questions they would like answered.
But finding out what they really want, let alone what
trade-offs they would be willing to make based on
realistic costs, is quite another matter. For a
completely new system, people can rarely come up with
an accurate complete picture of what they want right
off the top of their heads. Their ideas are usually --
and quite properly -- somewhat vague.

One useful approach to analysis is to provide
something in front of them to work with -- a mock-up
or prototype -- as a starting point, and having people
critique it. A teacher of mine, Frank Tesar, suggested
on a project we did that we announce that we had
deliberately made a really bad mock-up because we
wanted to hear as much criticism as possible. (I've
been grateful for this suggestion many times since). A
mock-up provides people with a tangible picture that
enables people to start talking in more detail about
what they really need. This usually occurs throgh
criticism. People will often find fault with a
prototype, and provide a lot of useful information,
when they'd simply approve written specs describing
the same thing! 

In short, somebody has to listen to people talk about
what they need, and set up an environment conducive to
talking effectively. Specs are a memo of that
conversation, but not the conversation itself. The
analyst needs to come up with a spec development
process that can result in as much useful information
as possible. Successful spec development is thus  a
highly interactive process, a process of discovery in
which not only the developer but the client often ends
up learning something about their business and needs. 

It is a complete fallacy to believe the client's needs
are "out there," fully formed, and the analyst simply
discovers them through questioning and rights them
down. Rather, the analyst takes the client through a
process of thinking about and discovering what they
need. This process is always inevitable in any
reasonably complex task, for most people simply do not
think through all the interactions involved -- that's
what the analyst is paid to do. Refinement is
inevitable. Better to  progressively refine the specs
now, rather than progressively refine the (much more
expensive) system later. Yet current theories of
software engineering assume, as a given, that clients
not only always know exactly what they want, but are
always perfectly capable of articulating it precisely,
and often in specialized systems modeling language, to
boot.

Jonathan Siegel