

Becoming a Great Programmer: Use Your Trash Can - estherschindler
http://www.javaworld.com/community/node/2537

======
dnaquin
Seldom a good idea. And faulty in so many ways. eg.

 _It's long been a tenet at the Schindler bitranch that when you find a block
of code with several bugs, it's time to dump the whole file and write it again
from scratch. It's faster than trying to squash all the bugs in your bug
factory._

So now you've traded bugs you know about for bugs you know nothing about.

The real key isn't rewriting, it's refactoring. And in my opinion, should be
done almost continually.

~~~
gruseom
Actually, the idea that most bugs are produced by faulty modules, and that
such faulty modules don't produce fewer bugs as a result of efforts to fix
them (and so are best thrown out), is one of the few interesting results
produced by experimental studies of software development. So I don't think it
should be dismissed so cavalierly.

I don't have time to track down the original sources on this, but I do
remember that one of the places I read about it is in Robert Glass' _Facts and
Fallacies of Software Engineering_ , which is worth reading because it's (a)
well-grounded in the research literature, yet (b) not stupendously boring.

It's worth noting that the findings in question have to do with rewriting
faulty _modules_ and not to do with rewriting entire systems (which is a quite
different matter). But this is also what the OP was talking about, so I think
this evidence, for what it's worth, supports her claim.

~~~
jwilliams
Agreed - the distinction is between (1) the code is simply buggy and (2) the
code is full of bugs because the design is wrong/inadequate.

I've realised over time that fixing a bug in a decent design is a lot of the
value (of software). A single line of bugfix can be worth reams of new code.
It's why banks are still running COBOL mainframes.

------
kaens
I do think that the necessity of what the article talks about varies from
project to project - but it strikes close to home in reference to my current
project.

I'm working for a client doing something like centralizing a whole lot of
decentralized data for use within an industry - the project has been attempted
by other people in the industry before, and failed horribly - I suspect
because few businessmen understand the problem they're trying to solve (and
"enterprise-ready code-monkeys" are a dime a dozen).

I'm lucky enough to have a client that understood that the first functional
version of what we were developing was more or less a throwaway version. It
helped us get a handle on the _exact details_ of the problem, but couldn't
last. I'm currently working on the third iteration of the application as a
whole, and (not to toot my own horn but) we have a pretty impressive, stable
app now.

If we wouldn't have done some major re-writing from the early versions, the
app would be utter fucking hell to maintain or develop at this point. Since we
did, the codebase is understandable, the architecture is correct for what
we're trying to do, and maintenance is not much of a pain.

------
joe_the_user
Hmm,

Actually, I suspect you need to redo a particular program design an infinite
number of times to get it perfect. That said, if you are going to accomplish
something, you need to hold onto that imperfect thing you just finished _at
some point_ and use it - or equivalently let go of the thing and let the
company use it...

Unlike art, programmers can't get hung up on perfection. Rather than being
_artists_ , programmers are _artisans_ (producing thing with perhaps beautiful
craftmanship but still forced on the use of those things)

~~~
harpastum
I disagree. My experience has been that no matter how well thought-out the
first version is, there are always a few extra features added, or previously
major features abandoned. These types of changes represent a distinct shift in
the structure of the program, but are often simply tacked on or hacked out,
respectively.

On the other hand, this article is simply stoking the embers of the long-
standing war between refactoring and rewriting, without adding a whole lot to
the debate.

Some other insightful opinions on the issue:

Joel Spolsky: <http://www.joelonsoftware.com/articles/fog0000000069.html>

Jeff Atwood: <http://www.codinghorror.com/blog/archives/000684.html>

Ronkes Agerbeek: <http://www.ronkes.nl/blog/?2005-04-15-neverrewritecode>

~~~
joe_the_user
Actually, I wasn't saying that you should always use the first version (or
that you should always use the second version) but simple that at some point
you need to release and that the result you release will be imperfect(I have
edited my original post to reflect this).

I would actually agree that one should not rewrite existing, _production_ code
for the purposes of using it in the same application. The main reason is that
the compromises that you remember as silly actually happened for important
"semi-major" reasons you have forgotten about. Development can feel like a
huge "rolling jello" activity _but_ that jello-rolling produces a "compromise
path" which cannot be found by deductions from first principles.

The reason to rewrite code from scratch is to produce a _different
application_.

Any serious application, produced over a matter of months, has so many man-
hours in it that it impossible for even the creator to comprehend the sum-
total of compromises which it involved and their motivation. Thus the
"character" of a particular application can almost never be recaptured by a
rewrite.

