Re: ::scr Development Sins

["Simon Kinahan" <simon@xxxxxxxxxxxxxxxxxxx>]

> Which is shattering my most preciously held belief - Brooks' "Always
> plan to through the first two away" (which lets me put off stuff I
> don't want to do now until 2 versions' time)

I think they're reconcilable. Brooks actually said to plan to throw one
away, because you will anyway. Looking at that chapter of "The Mythical Man
Month", what he seems to be saying is that it is necessary to build
prototypes, rather than doing a Big Design on paper and then trying to write
a production piece of software in one go. I'm doing it right now actually,
and carefully focussed prototyping brings out all kinds of technical issues
I know I could never discover by meditating on a mountaintop (this view is
shared by the 2 smartest people I know, before anyone makes the obvious
joke). On the occasions where I've actually tried to start writing a
production system without doing some experimental stuff first, its generally
needed so much rewriting and become so frustrating, I gave up.

This seems to cohere with what Joel said about shipping code building up
"experience" of its operating environment that no individual developer or
group thereof will have. The point the two share is: You can't understand
everything your software needs to do, until you actually try to make it do
it. Things like Extreme Programming seem to come from a similar standpoint
with regard to building up knowledge of what your users really want by
making frequent releases and being prepared to rewrite small sections of
code constantly. Come to think of it, users are a part of the operating
environment. The most important, and most complex, part.

Brooks also warns, again in "The Mythical Man Month", against the second
system effect. The seems very like the Big Rewrite that Joel is arguing
against. Its where the senior engineers, often those most detached from the
realities of the code face (I've been guilty of this myself, BTW), with the
success of the project established by the first release, try to do the
second release "properly". This inevitably means replacing the simple but
successful "hacks" in the first release with "elegant" solutions that turn
out in fact to be impossibly baroque and require a degree in mathematics to
use. If anyone says the words "filter" or "predicate", I still wince ...

On the other hand, I'm not convined I agree with Joel. Some system rewrites
seem truly necessary, and I suspect they can be done in a way that takes the
lessons of the old codebase into account. However, I'm sure they should be
done while looking at the old code in an adjacent window. Then it actually
becomes very like an exercise in understanding through refactoring. Having
said that, the only system rewrite I ever watched from the sidelines was a
disaster: the new system was less stable than the old, and the promised 5x
speed increase never emerged. There was definitely an aspect of second
system effect there.

> The thing is I hate how code accumulates cruft - stuff you've grafted on
> to add new functionality, those little hacks and features crowbarred in
> that don't really fit in with the architecture.

Yeah, I know. I think we - especially the OO generation of software
engineers, though I'm sure its always been true - like to build nice
abstractions and then write the actually application code as manipulations
of those abstractions. When someone comes along and says "The first
character of that needs to be capitalised", or some such fiddly thing, I
just bung in the code to do it at the top level without really thinking
about it.

There seems to be a difference between the way I code when I writing new
stuff, and the way I code when I'm maintaining old stuff. Code added to old
stuff tends to be much less carefully thought out. I'm trying to reduce the
extent to which I do this, but I've noticed that more than a few developers
do the same. Thus cruft is born, I think.

Simon