Becoming a Great Programmer: Use Your Trash Can | Hacker News Reader

Becoming a Great Programmer: Use Your Trash Can

javaworld.com

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.

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.

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.

The two big variables are the skill of the architect, and their understanding of the real problem.

Rewriting is valid if the new architect is more skilled and understands the problem better. Unfortunately it's quite likely that the new architect doesn't understand the problem better, in which case the new architecture will likely be worse than the first.

To complicate matters, the problem may change over time as well. So if you sink the time into a rewrite, there's no guarantee the new version solves the latest version of the problem any better than the first.

Given the uncertainties, I have to see a real solid reason and clear benefits before doing a rewrite. Just because there are some code smells or a lot of bugs doesn't mean I can come up with a better architecture necessarily. I'd rather refactor a bit at a time and see what shakes out.

> The two big variables are the skill of the architect, and their understanding of the real problem.

I read the article as discussing when to throw your own code away and start over. Under those circumstances, aren't you more skilled today than you were when you wrote the original? Is your understanding of the problem better or worse?

For that matter, is it even the same problem, or has the problem itself changed since you first wrote the code?

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.

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)

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

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.

Reply on news.ycombinator.com