At what point do you quit adding features and patches to existing code, give up on it, and rewrite it from scratch the way it should have been done?

When you can afford not to do maintenance on the existing version and spend your time playing catchup by duplicating working (if ugly) features.

That is to say "not very often at all".

I think the idea that rewriting from scratch is good is one of the myths open source developers tell ourselves.

I think the idea that rewriting from scratch is good is one of the myths open source developers tell ourselves.

That's an excellent point, and I should probably have it tattooed inside my eyelids.

More specifically (or more agile-methods-dogmatically, I suppose), not being able to change bits and pieces of your code on an as-needed basis probably means that there's something missing from your project: a proper revision-control system, for instance, or an adequate test suite. Instead of throwing out your existing codebase (which probably does a lot of things right) and rewriting it from scratch, you might be better off asking "Why can't I refactor the existing code?" and acting on the answer.

On the other hand, "Plan to throw one away; you will, anyhow." Arguing with Brooks about software engineering practice feels sort of like arguing with Knuth about typesetting software. If your code does absolutely (or even nearly) nothing right, and you don't mind losing a mildly functional program while you recreate infrastructure, treating the current version as a giant prototype and starting again could be the right thing to do. Chances are good that this sort of thing is easier to do with a personal project than with mission-critical business code.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
% man 3 strfry

Arguing with Brooks about software engineering practice feels sort of like arguing with Knuth about typesetting software.

I'm willing to argue with Brooks and Knuth when they're wrong. :)

I interpret Brooks' comment above as countering the fallacy that you can know ahead of time exactly what you need to build and that you'll design it appropriately without having built it. In that vein, anything you can do to incorporate useful feedback into the coding process will help you produce the software you really need to produce. Remember, writing an operating system in assembly in the 1960s is a little more difficult than writing a business-logic server in Perl in the 2000s.

As for Knuth, I'll paraphrase what Bob Frankston once told me. "You can assume that the cost of memory access is uniform, but it's not."

On the other hand, "Plan to throw one away; you will, anyhow." Arguing with Brooks about software engineering practice feels sort of like arguing with Knuth about typesetting software.

Agile folk still throw one away. We just do it in teeny-tiny pieces instead of all in one go :-)

Actually, Brooks had changed his mind at least once since The Mythical Man-Month or wherever his quote is from. This from a teleconferenced lecture he gave in 1996:


Our designs are so complex we can't do it right 1st time by
pure thought.  To expect this is to be arrogant.  So, we
need a design + build philosophy that incorporates 
evolutionary growth.

    * no waterfall design!
    * no plan-to-throw-one-away design either!

Perl's fast "compile-link-load cycle" and CPAN library seem to be a big help to me when I'm evoloving applications.

Good Luck

Sweetblood

1. I am happily bopping along.
2. I run into an annoyance.
3. If that annoyance is really annoying (i.e., it pisses me off), I fix it.
4. If it isn't that annoying, I live with it ... until it pisses me off, then I fix it.
5. If I know the annoyance will severely piss me off in the future and I have time now, I fix it.

But, then again, I love refactoring code I just wrote three months ago. Over and over and over. Kinda like OCD, but easier on the skin.

I don't think preferences should determine your decision. It's a matter of judgement based on experience - a personal issue, certainly - but not preference.

Ideally, you never throw your code away. Agile methodologies such as frequent refactoring and testing help you avoid this: refactoring makes your code less messy; testing checks that your code meets your needs where your needs are specified within the tests.

Your code should allow the integration of new features, whether from CPAN or not. You need to take good care of it as it evolves. I like the pragmatic programmers' programming as gardening metaphor.

Taking responsibility for others' badly maintained, disorganised code needs some thought. As does dealing with your own badly written code. No matter how hard you try, it's easy to write rubbish. Sometimes you write bad code deliberately: you evaluate risk, experiment and learn.

So, when should you rewrite code? It depends on what you want to do. If the code won't evolve significantly, maybe you can throw a few tests round it and hope nobody asks you to modify it significantly. This happens less often than you might hope. Alternatively, you may find you can refactor much of it, writing tests as you break the code up into meaningful routines. If you find it hard to decide initially, why not set aside some time to experiment with refactoring? You may give up on this, but you will understand the code better.

A couple of months ago I chose to rewrite some code and only discovered its complexity as I got more involved with it. In the end, we gave up after spending too much effort completely overhauling the existing work. This reminded me of the importance of frequently, honestly evaluating work, understanding risk and recognising the positive aspects of failure.

Plan to throw one away refers to prototyping. If you don't prototype, you'll write and re-write as much code, in debugging and ading features ... except you'll be doing it with released code.

The other side of the coin is second system syndrome. It's discussed in Joel Splosky's article Things You Should Never Do. The basic idea is that you decide an evolving program has become so crufty that it can't be repaired or improved, it has to be totally re-designed and re-written. Nine or ten years later, Netscape 6 becomes available. The problem is that you are starting over, generating a totally new product, just like your competitors do ... except you have to remain compatible with your features while they don't.

The correct solution, according to Joel, is to adopt the eXtreme Programming concept of refactoring, that is, extracting code and encapsulating it into a routine. refactoring is inlining in reverse, if you know C++.

That is, instead of throwing it away, baby and bathwater and all, improve things, one item at a time. Take repeated code and convert it into a routine. Take a bunch of related routines and turn them into a module, or an object. Once concepts are separated, it becomes simpler to benchmark things, and replace a module with a different implementation, a different algorithm.

Of course, you need testing to determine whether changes break existing requirements. But you'll only regret writing tests until the first time you go back to do maintenance on existing code, and find you can verify correctness in a fraction of the time. Anyway, that's a topic for a different Seeker of Perl Wisdom.