Comments on book review - (nf)

[mwm at ea.UUCP]

#R:uvacs:-130500:ea:5700007:000:1741
ea!mwm    May 25 15:58:00 1984

>To rephrase my previous statement:  just because personal factors are
>important does *NOT* mean they are the only important factors.  It is
>an objectively-verifiable fact that some peoples' preferred styles of
>programming turn out code that is poorer, by almost any realistic
>measure, than other peoples' preferred styles.

Yes, but will those other people (the ones with the poorer code) turn out
better code if you make them use your style of programming? I write better
code using iterative refinement than I do when I try to do the design
completely and totally from the ground up. For some reason, the designed
code isn't as flexible as the refined code. The following quote from me
(which you quoted out of context) sums it up:

>   .....You should use whatever method gets the results you need, preferably
>   minimizing over pain to you....
>
>What about minimizing over pain to the other folks who are going to have
>to maintain your code after you're gone, or maximizing over quality?  If

In that case, maintainability is part of "what you need". You dropped
that when you dropped the context. If the code I wrote was unmaintainable
and maintainability was part of what I needed (it almost invariably is),
then I obviously chose the wrong method.

>Experiments and quick kludges are often in a different category from
>production software, but I know of a good many kludges that have been
>pressed into "production" service because the resources to do them
>over again, right, weren't available.

This is all to true. This is why I spend a fair fraction of my time trying
to convince the people on rug row to let me spend a little extra time doing
it right the first time. It generally saves time (and money) later.

	<mike