Legacy and Technical Debt
The concepts of legacy systems and technical debt are related and sometimes used interchangeably, but they actually refer to different things. It is worth understanding the differences and the relationship between them, because it helps you plan the right actions to take.
There is a tendency to call anything that is less than perfect technical debt, probably because it creates a false legitimacy, as technical debt is part of the agile ethos now These legacy systems sometimes get described as technical debt, but this is an unhelpful label to apply, as it implies that the journey to legacy was intentional.
As architects, we have all encountered systems that are too hard or risky to change. When you ask about it there is a sharp intake of breath and - “You don’t want to be changing that …”. When you hear this response, you know you have a legacy system on your hands. The system often continues to run successfully without problems, until something changes. There area lots of ways things can change: an interface is updated, the operating system changes, or the business products the systems support change. It is then too expensive, too risky or just too hard to update the software or hardware to accommodate the change.
Maybe there is no documentation, if the system is written in a language that has dropped in popularity engineers might be scarce, or hardware no longer produced. If this is the case you need a legacy transformation, but what if things aren’t yet this bad and we have technical debt.
The term technical debt was first used by Ward Cunningham, one of the authors of the Agile Manifesto, way back in 1992. He said that some suboptimal designs or coding practices, which are shortcuts to save time, are like financial debt: It is OK, and even beneficial, to borrow against the future, as long as you pay it off quickly by refactoring the code. Unfortunately, all too frequently the last part of the statement gets ignored which has led to technical debit becoming a significant problem in many organisations. At some point the level of unaddressed technical debt can get so high that it becomes too risky or expensive to fix, and you have a legacy system, purely because of overly complex badly designed code. It is imperative that you avoid this be taking remedial actions, these will vary depending on context, but start to address the issues alongside current product development, don’t let the problems get worse, how do this is a whole new topic.