Comments on book review

[Henry Spencer]

John Crane comments:

   If you built a house the way some of you seem to think you should build
   a program, we'd be in trouble. The software sevelopment cycle is more
   that just a textbook approach. It is a reality in the commercial world
   of industrial-strength business software.

The contention that the software development cycle is more than just
a textbook approach is half true, but only half.  If one defines "textbook
approach" as "a long and convoluted procedure that is unnecessarily
complex for any real purpose", then clearly the s.d.c. is more than
this.  Advance planning is a real necessity.

Unfortunately, the s.d.c. is a "textbook approach" in another, related
but not identical, sense:  "something that sounds good in the textbook
but ignores important real-world complications".  Specifically, John
says:

   You gotta plan ahead. If not how do you know what you are going to
   build and how will you know when you've built it?

What we're going to build is "something that satisfies the customers".
We know we've built it when the customers are happy.  Since the customers
*INVARIABLY* cannot specify exactly what they want in advance, the idea
of "plan first, then implement" is preposterous.  An iterative approach
is inevitable and necessary.  Places that claim to follow the s.d.c. but
still produce quality software are always REALLY following an iterative
approach, even if they don't admit it or recognize it.

The classic symptom of rigid adherence to the s.d.c. is that the first
release of the new software package is a piece of garbage, the second
release is starting to be useful, and by the third or fourth release
the thing is actually fit for humans.  Note that what we have here is
the iterative approach in disguise, usually at far greater expense (to
both the suppliers and the customers) than if it had been done explicitly.
The prevalence of this approach within the industry is clearly indicated
by the intense reluctance of many organizations to be the first customers
for a new product.

Note that when I say "the customers *INVARIABLY* cannot specify exactly
what they want in advance", I don't mean that they have absolutely no
idea what they want.  They generally do have a rough idea, and some
advance planning based on this is wise.  But even if they are willing
to write exact specs for everything in advance, using the system will
change their perceptions of how they want the details to work.  In the
prevailing s.d.c. approach, the result is major rework jobs before
subsequent releases, rendering obsolete much of the detailed advance
planning done during the "development" phase.

This is not to say that advance planning is futile for major software
packages.  On the contrary, it remains very important.  But the pretense
that every detail can be spec'ed in advance is silly.  Advance planning
time is best spent identifying issues, gathering data, running experiments
with real users, exploring general approaches, and generally doing things
that will be valuable regardless of how the final details come out.  There
is nothing wrong with trying to draw up a detailed spec in advance -- it
can be a very useful way to explore the problem -- provided you recognize
that it's unlikely to bear much relation to the final result.

I can hear the system-development-cycle folks lighting their afterburners
now.  Just remember, folks:  you, too, use the iterative approach.  Your
users know that, even if you don't.  And they wish you'd admit it.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry