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

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.