Re(2): rebuilding working code

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

Comment on Re(2): rebuilding working code

Replies are listed 'Best First'.
Re: Re(2): rebuilding working code by chromatic (Archbishop) on Jun 02, 2004 at 20:42 UTC
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."	[reply]
Re^3: rebuilding working code by adrianh (Chancellor) on Jun 02, 2004 at 22:38 UTC
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 :-)	[reply]
Re: Re(2): rebuilding working code by rje (Deacon) on Jun 03, 2004 at 18:37 UTC
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.	[reply]