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

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