Quality by Design, Part 2: Design for Maintenance: Healing Legacy Code
Introduction
The sorry state of software in many organizations is attested to by the way that people talk about "legacy systems." Nobody seems to be excited about working on a legacy system, even those that are mission-critical or that handle the bulk of an organization's revenue stream. Sometimes it seems as if no one wants to work on legacy systems, except maybe as a precursor to replacing those legacy systems.
The problem is that many organizations have let their mission-critical systems fall into an abysmal state where nobody in the organization really understands these legacy systems any more. Even worse, the organizations have failed to train their developers in the technologies they need to know to look after these mission-critical applications. No wonder it takes forever to get a simple change made on these mission-critical systemsnobody in the organization knows how to write COBOL. It would be laughable if it weren't so sad.
As Trygve Reenskaug once said, "As time passes, only COBOL lasts." The reality is that in the 1970s and 1980s lots of mission-critical applications were written in COBOL or similar vintage languages such as Assembler, FORTRAN, PL/1, and RPG. Even now, in the age of the Internet, Java, and web services, most companies are still dependent on applications written in these "legacy" languages. The Y2K fiasco didn't kill off all these mission-critical applications; they're just as important as they ever were.