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

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 :-)

• Perl Medic: Transforming Legacy Code by Peter J. Scott
• Working Effectively with Legacy Code by Michael Feathers
• Object-oriented Reengineering Patterns book now available as a free download

• 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

• Backdating strict
• sed/awk/grep to Perl
• Working with old code
• Splitting program into modules
• Searching for duplication in legacy code
• Perl archeology: Need help in refactoring of old Perl code that does not use strict
• Reading Someone's Program
• Code Structure Changes
• Perl Elitist Code vs Functional Code
• Meaning of "Clean" Perl code
• How to retain perl in-house code
• Cleaning up unused subroutines
• documentation best practices for internal modules
• Rule of Three (wikipedia)

• 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)

• The future of Perl? by BrowserUk (2014)
• Re^4: The future of Perl? (Legacy Code Quotes)

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

• Re: Winning people over to better development practises (TDD)
• Effective Automated Testing
• What is the best way to add tests to existing code?

• Looking for help for unit tests and code coverage on an existing perl script
• Needing help on testing
• How do you test end-user scripts?
• A brief question about testing/best practices
• How to write testable command line script?

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

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

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

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

Debugging this code is a whole different game, and I'd really appreciate some input from other monks who've dealt with this type of problem.

I'd recommend reading Perl Medic and Working Effectively with Legacy Code (the latter isn't Perl specific - but is chock full of useful advice).

I would not spend any time fixing the code if it's not breaking (assuming you're not being paid to review/fix the code). However evil it may be - if it's doing it's job leave it alone.

Instead - every time you need to fix a bug or add some new functionality just test/refactor the bits of the evil code that are touched by the changes. I've found incrementally adding tests and refactoring to be much more effective than any sort of "big bang" fixing things for the sake of them approach :-)

If you are being paid to do a review/fix then Perl::Critic might give you some useful places to look.

Definitely agree about the approach of sorting things out with gradual refactoring and tests as the need arises. The problem with the "Big Bang" approach is that you have the potential for a very long stretch of time where there are two forks of the code: ugly shipping code that will need to be fixed and refactored as bugs are reported, and pretty nonfunctioning code that will need to incorporate those fixes as they are uncovered, resulting in a perpetual loop of "it's not quite ready yet."

Check out Suggestions for working with poor code and some of the replies.

What tools are you using already and on what platform? For a large range of "detail" debugging there is nothing like as good as an IDE with a good integrated debugger. For a higher level view of where things are going Devel::TraceCalls may be handy, although it's output can be rather voluminous.

1) Ensure there is sufficient functional and technical design documentation against which the routines can be tested.

2) (updated) Make sure there is a sufficiently detailed project plan to include tasks for: systems analysis, functional and technical design, test planning, test script writing (e.g. using Expect), developing, unit-, integrated and functional testing, rework and implementation, to include a GANTT chart of the work done so far and by who to what % of completion, to avoid getting the blame for not meeting poorly conceived targets over which you had no control.

In response to formal testing against the plan, I find it a useful aid to bug-fixing to monitor execution with perl -d, setting breakpoints and examining variables to hunt down which line of code causes each failure.

The Doxygen perl extension creates docs that are great for seeing what classes re-implement what methods etc. Also the UML::Sequence sounds intriguing - it pupports to generate a sequence diagram by monitoring code execution.