Legacy software as a valuable inheritance

Legacy software is often seen as something negative. Wiktionary has a depressing definition of a computer system that has been in service for many years and that a business still relies upon, even though it is becoming expensive or difficult to maintain. I have never liked that definition, because obviously if you keep investing in something for many years, it must be bringing some value to you. As Woody Zuill pointed out to me when I met him recently, the original definition of legacy is much more positive:

Legacy as a valuable inheritance

Something inherited from a predecessor; a heritage

Legacy software embodies years and years, even decades of compromise between the desirable with the possible. The emergent result of this design activity is not only software but also an organization that relies on it. The organization, the technical system and the people involved form a highly complex joint cognitive system.

When legacy software is done right, it is very much at the core of the business. It forms a sort of DNA or operating system intricately linked with the business. A legacy like that is a wonderful inheritance from our colleagues in the past. Sometimes, it is even a legacy from ourselves.

It is providing value, and therefore we want to keep it and so we work on it.

Video with Woody Zuill on legacy software

Wait a minute, why am I quoting Woody Zuill on legacy software? Isn’t he the guy most well-known for “no estimates” and “mob programming”? Indeed he is, but when we met a few weeks ago, we recorded a video about legacy software and legacy innovation. I think some of you will be surprised to see another aspect of him when you watch this:

The onion theory of legacy software systems

A field where onions are cultivated at a large scaleSource: Rainer Haessner via Wikipedia | CC BY SA 3.0

Is your software landscape a field of onions or a scrapyard of old crap? Those are two fundamentally different ways to look at legacy software systems.

In the video, we discuss the onion theory of system development. In brief, just like an onion starts from a seed, than grows to a first ring and then another and another, so does a software system grow from a sleek, well written core from some long forgotten mainframe system. The rings keep growing with middleware, API:s, service buses, orchestration layers and so on. We have many excuses for doing things this way, but the main reason remains – we do not dare touch the core, that legacy from our long forgotten predecessors.

A lot of the knowledge of our predecessors is hidden in the software. We cannot re-engineer that knowledge. In effect, the system is the specification. We need to keep refactoring, removing parts not needed because they cloud the parts we need to work on. Just like we need to exercise our whole bodies, we need to work the whole system.

No quick fix

A working complex system must emerge from a working simple system. It is naïve to think that there will be any quick fixes to legacy software. Just think about ventilation in new buildings. Have you ever had the experience that a meeting room is not well ventilated? It takes a long time of fine tuning to get the ventilation right in a building, and that is not a very complex system compared to the legacy software that powers your business.

Image sources

About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services ...


  1. Glen Alleman

    You may have fallen victim to the “sunk cost fallacy”
    This is not about the software, it’s about the holistic integrated cost of the business processes, now and in the future.
    For example https://hbr.org/2014/06/why-the-va-couldnt-keep-up-with-it

    I work a program in another Federal Agency that is spending huge amount of money maintaining legacy systems, when a simple switch of a state of the art ERP system, would cut the M&O spend to ZERO and release large amount of committed cash.

    This notion of W’s fails to consider the balance sheet “obligatory cash flow” of the legacy system, as well as all kinds of other issues — Security, interoperability with other systems, cloud computing, declining resource pools.

    This is a IT Governance and Strategy issue NOT a developer’s view of the value of the legacy system

  2. Pingback: Legacy systems, a definition - Greger Wikstrand

  3. Glen ALLEMAN

    Since you reposted, I have another observation on legacy systems.
    In our domain, legacy means Heritage systems. Trusted sources of capabilities to be used and reused on future programs.
    The picture in the post is an example.
    The notion of onions may be valid in the absence of a legacy or heritage architecture. This is one of the roles of architecture – to serve as a platform to heritage and current systems integration.
    You are correct in there are no quick fixes for legacy systems. But that is not limited to just legacy systems, bit for any complex system.
    The notion “A working complex system must emerge from a working simple system” must be tested by the architecture of the resulting system. It may well be that the “simple” systems provide little or no value in the absence of the connectivity to form the complex system.
    I sense that W calls complex systems from his experience, but those systems are actually simple when compared to actual complex systems – GPS II/II, the air traffic controls system, the electric power grid control systems in the US (run by the Department of Energy) and other Sofwtare Intensive System of Systems

    are some thoughts on SISoS

Leave a Reply