Legacy Software

Legacy systems may be defined informally as 'large software systems that we don't know how to cope with but that are vital to our organization'. Legacy software was written years ago using outdated techniques, yet it continues to do useful work. Migrating and updating this baggage from our past has technical and nontechnical challenges, ranging from justifying the expense in dealing with outside contractors to using program understanding and visualization techniques.

Even the best practices of refactoring are really a joke in the context of a large legacy application.

Big rewrite [of a legacy system] is a loser’s proposition. It’s as stupid as adding more people to a late project

Every new line of code quickly becomes legacy. When that legacy mounts, it forms a significantly massive pile of software, which cannot be ignored. … what we can do intentionally with such piles, from abandonment to evolution and many things in between.

Legacy software was written years ago using outdated techniques, yet it continues to do useful work. Migrating and updating this baggage from our past has technical and nontechnical challenges, ranging from justifying the expense to dealing with offshore contractors to using program-understanding and visualization techniques.

As the code written today becomes part of tomorrow's inexorably growing legacy, preserving these stories becomes increasingly important. It's costly to rely upon informal storytelling to preserve and communicate important decisions; it's incredibly costly to try to recreate those decisions and their rationale when the storytellers themselves are gone. Insofar as a software development organization can preserve its stories in a system's written architecture, it can make evolving that system materially easier.

In real archaeology, you're investigating some situation, trying to understand what you're looking at and how it all fits together. To do this, you must be careful to preserve the artifacts you find and respect and understand the cultural forces that produced them. … Code becomes legacy code just about as soon as it's written, and suddenly we have exactly the same issues as the archaeologists: What are we looking at? How does it fit in with the rest of the world? And what were they thinking?

Legacy software systems represent a significant investment but often become difficult to maintain as they age. Not only does technology evolve beyond them, but business needs change and may require adding or modifying functions.

Rebuilding a legacy system has some parallels to the restoration of a work of art … The restoration involved far more than updating the code: the development team also had to understand the existing architecture, add new functionality, and develop a long-term hardware migration plan.

One thing we know for certain is that the dominant programming language of today is the legacy language of tomorrow. Sometimes languages are sidelined due to fashion, but changes are generally due to new languages being applicable to a wider or different class of problems than their predecessors. Maybe one day this process will stop, but it seems unlikely that you’d lose money betting on it to continue for a while yet.

Software systems must continually evolve to meet ever changing needs. However, such systems often become legacy systems as a consequence of uncontrolled maintenance combined with obsolete technology. To control maintenance costs and preserve complex embedded business rules, companies must evolve their legacy systems.

Migrating legacy systems and developing new systems for client/server environments has dominated the software development tool market in the '90s.