Re: Strategies for maintenance of horrible code? (Legacy Code References)

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:

Nobody Expects the Agile Imposition (Part VI): Architecture - lengthy and at times heated discussion of refactoring vs rewriting of large code bases (perl5 internals compared to Jenga :-)

The Boy Scout Rule (apply the Boy Scout rule of "leave the campground cleaner than when you found it" to your code)
Re: Moving from scripting to programming (tips for writing industrial strength code that lasts a long time)
Unix shell versus Perl (explains why Perl is a better choice for large code bases than Unix shell)
Re: I need perl coding standards (Coding Standards References) (list of general references on code standards and style advice)

Swallowing an elephant in 10 easy steps by ELISHEVA (Describes how she tackles big problems to keep moving forward rather than going around in circles)
Dealing with sloppy code
Becoming familiar with a too-big codebase?
Analyzing large Perl code base.

Second-system effect (wikipedia)

Legacy Code References Added Later

Re: Using the perl debugger to look at a renaming files function (on Debuggers References) (on debuggers)
Re: Re: Re: Are debuggers good? by merlyn (aggressive approach to rewriting unmaintainable code)
"Your code sucks" by afoken (tales from maintaining legacy real-time code where bugs can kill people)

Strategies for maintenance of horrible code? by converter (on rewriting horrible perl code left behind by his predecessor)
Legacy Code by GotToBTru (some examples of poorly written legacy code)
There's Only One Way To Do It by jdporter (compares Perl with Java)

Bad Code References Added Later

Suggestions for working with poor code by Ovid (2001)
The joys of bad code by BUU (2004)
Need Bad Code by SleepyJay (2007)
Re^3: Where to place POD by hv (2024)

The Daily WTF
Competition: deceptive code by sfink (2008)
Things are not what they seem like. by Abigail (2000)
can someone help me? by xiper (2004)

Testing References Added Later

Updated: Added many extra references long after the original response was made.

Comment on Re: Strategies for maintenance of horrible code? (Legacy Code References)

Replies are listed 'Best First'.
Re^2: Strategies for maintenance of horrible code? by GrandFather (Saint) on Jul 12, 2006 at 08:38 UTC
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. DWIM is Perl's answer to Gödel	[reply]
Re^2: Strategies for maintenance of horrible code? by tinita (Parson) on Jul 12, 2006 at 12:28 UTC
Maybe. For another point of view, see Joel Spolsky on not rewriting from scratch. uh oh. why does this remind me of perl 6? =)	[reply]

In Section Seekers of Perl Wisdom