Re: Strategies for maintenance of horrible code?

[eyepopslikeamosquito]

in reply to Strategies for maintenance of horrible code?

Yes, it would have been cheaper and faster to throw this code away and start over

Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch.

I agree with adrianh. If a component is not broken, don't rewrite it. Rewrite a component when you find a number of bugs in it. But first write a regression test suite for the component. I've seen many folks over the years throw out old code, rewrite it ... and introduce a heap of new bugs in the process. If you come into a new company and introduce a swag of new bugs in previously working code, you will start to smell very badly.

See also:

• Swallowing an elephant in 10 easy steps
• Dealing with sloppy code
• Becoming familiar with a too-big codebase?
• Analyzing large Perl code base.
• What is the best way to add tests to existing code?
• Perl Medic: Transforming Legacy Code by Peter J. Scott
• Working Effectively with Legacy Code by Michael Feathers

[GrandFather]

Actually, just writing the tests is often a damn fine way of finding bugs. No exactly what OP is after at the moment, but something that is at the forefront of my mind because I'm in the middle of writing a set of tests (in Perl :) for some XML processing C++ code and turning up a pile of bugs as I go.

However it does suggest another test avenue: write test harnesses for modules so that you can exercise them in isolation and better understand how they work. If the test harness ends up part of a regression test system so much the better.

[tinita]

Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch.

uh oh. why does this remind me of perl 6? =)