How I define “legacy” systems
In their hit singles “The Living Years”, Mike and The Mechanics crooned, “Every generation blames the one before”. I believe we frequently encounter this concept in our world of software engineering.
Ask any engineer what it will take to fix an issue or evolve a complex business critical system. We often resist change. We detail all the flaws and poor design choices in the solution. We emphatically state that there is no quick fix. We label them as legacy systems and point an implicit finger at the “other” team.
Driven by an innate inner belief, we also push for a complete rewrite using modern techniques, architecture, and tech stack as a solution for the problem. We radiate confidence that a new tech stack will remedy all shortcomings and the business will never be constrained.
No software engineer consciously crafts code which can’t be maintained, extended, or evolved. On the contrary, we use our skills to carefully architect solutions. We add multiple layers of indirection to safeguard “ilities”. We spend extra time and energy on design and implementation, bordering on over engineering.
Yet the inevitable happens. Shiny systems are soon labelled legacy. Some sooner than others. Why?
In my experience, “age” is an inaccurate & insufficient parameter to define legacy systems. Neither is the tech stack, architecture, or the time spent in design and implementation.
Instead, I propose.
Any system which induces fear and uncertainty with every change is a legacy system.
Feature requests for such systems spread fear, anxiety, and nervousness across a team. We pull up our defences, dig in, and fight the inbound feature request. We claim not to understand all implications. We ask for more time and demand extended “regression testing” rounds to validate and deploy. We carefully make the change and start to worry about the next request.
This definition (based on fear factor) has an interesting implication. We may be rewriting a system on a new tech stack and creating legacy systems at the same time. Work being carried out under several digital transformation initiatives could be adding more to the legacy ecosystem. Reflect and recall the time when a rewrite was worse than the legacy system?
How do we keep this fear factor in check? How do we prevent it from spiralling out of control? In the subsequent instalments, I will share lived experiences in a hope to keep systems the shiny things they were meant to be.
If you are interested in joining us on our journey, please check out our careers page.
