Comments on book review - (nf)

[mwm at ea.UUCP]

#R:cubsvax:-21900:ea:5700004:000:1685
ea!mwm    May 15 20:15:00 1984

/***** ea:net.lang.c / utzoo!henry /  1:02 pm  May  9, 1984 */
I've heard too many people say "well, everybody knows that <THING> is
all just a matter of personal taste, so I'll do <THING> any way I damn
well please and you have no right to object".  Admitting the importance
of personal factors does not imply admitting that they are the only
important factors.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry
/* ---------- */

Sorry, Henry, but in programming, the personal factor *is* the dominant
one. You should use whatever method gets the results you need, preferably
minimizing over pain to you.

However, you should consider one thing that nobody seems to have mentioned:
what do you want the code for? Is this an "I need it yesterday" program?
Is it a program to experiment with a language? Maybe to experiment with a
concept? Is it a tool you're going to use and probably modify later?

I use different styles for each of these type of programs (I tend to choose
different languages, too!). If I've got the time, I tend to design the user
interface, then choose the algorithm, choose the language, and code the
program using iterative refinement. I find that this leads to more
maintainable code than any other approach I've tried - including the
Yourdon Overplanning approach.

Of course, one of the times I worked with a team, I used the Yourdon
approach. I had to, as the other team members weren't capable of choosing
an algorithm, and just barely capable of coding it [I got code from team
members that wouldn't compile, for Finagle's sake!]. But this is just a
case of fitting the programming style to the individual.

	<mike