Comments on book review

[Raymond Chen]

>>   The referenced article refers to the textbook approach to programming, i.e.
>>design, program, debug.  The book in question even suggests that failing to
>>plan the program out carefully before writing is dangerous and bug-prone.  The
>>author of the article asks if anyone actually programs that way, and what 
>>people think of that approach.
>>   Well, I for one subscribe to the notion of "stepwise refinement" or
>>(more poetically) "creeping elegance."  The idea is to write a program that
>>(1) is small (2) does at least some of what you want the final program to
>>do, or shoots in that direction (3) works and (4) is easy to modify.
>>   This makes it possible to program almost bug-free, and to catch bugs almost
>>as soon as they occur (so you don't have to go on a bug-hunt later on).  The
>>idea is to keep adding to the program until you get what you want (or maybe
>>something better).  A big plus to this approach is that the program remains
>>modifiable - one of the reasons for the high cost of software maintenance
>>(I suspect) is the tacit assumption that the program will never have to be
>>changed.  If you know for a fact from the word go that mods are coming, you'll
>>write a better program most of the time.  And certainly one that is easier to
>>fix and improve.
>>   So no, I don't believe in plan-code-test.  I believe in plan a little, code
>>a little, test a little, plan a little, code a little, test a little....
>>   Long live Yourdon!
>>
>>   Best,  D Gary Grady, Duke University
>>   {decvax or whatever}!mcnc!ecsvax!dgary

Fine.  Incremental programming can be a wonderful thing.  I think, though,
that you're missing the point of the book and that is that you don't start
putting code into your computer until you know *exactly* what that code
is going to do.  After all, the idea behind programming incrementally is
to do it in small steps so you can make sure that each step works.  What
that book was coming down on was what a lot of people tend to do and that
is to sit down at a terminal with the specifications/goals and start
typing a program without taking some time to make sure that what they're
going to do will work, or even to make sure that they understand in toto,
what the program is supposed to *do*.  No matter how you write the system,
the idea should be to avoid design/logic errors, and in most cases, make
it extendable and maintainable.

-- 

The preceding message was brought to you by --

		Ray Chen
		princeton!tilt!chenr