Understanding technical debt. Really?

Enrique Dans has recently published an article named "understanding the concept of technical debt" in which the professor of IE focus on explaining what is behind technical debt and its effects, using the recent British Airways IT outage as an example of it.

Since the article was published I have seen it appearing several times on my twitter timeline and LinkedIn homepage. Surprisingly (at least for me), the feedback on the article seems to be positive, so I have decided to share my thoughts on it and why I disagree with some of mr. Dans points.

Let's start with the technical debt definition itself. The article links to the wikipedia defintion of technical debt, which defines Technical debt (also known as design debt or code debt as"a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".

So far so good. The problem is that after linking to this definition, the article goes on and links technical debt to the existance of legacy systems, stating that it "has its reflection in the persistence of antiquated and non-migrated software developments to more efficient technologies".

From the above statement it seems that newer technologies are more efficient in terms of technical debt than older ones. I think that by implying that, we are just oversimplifying the problem.

It is clear that legacy systems are not prepared on their own for solving most of the challenges that digital transformation raises. Digital technologies are definitely more efficient for solving those challenges, and that is of course the main advantage of the so-called "digital pure players" which IT history has started recently in terms of software evolution.

Does this imply that every company with a long IT history and legacy systems is doomed to have a lot of technical debt? Not at all. I have been fortunate enough to work for first level companies both in the banking and insurance sector that take good care of it despite of still strongly basing its core systems in mainframe platforms.

On the other hand, one may think that every start-up or digital project based on the latest technologies is blessed with no technical debt, right? Not at all. Here you can find some examples to demystify it (surprising to see that projects born 10 years ago have an estimated accumulated technical debt of 20 years!). And even so you are a pure digital start-up, if you want to scale you will definitely end up needing to integrate with partners, regulators, customers, suppliers systems, so welcome to the jungle!

The real scenario for most companies is not either legacy or pure-digital IT, is actually a mix of legacy and more recent digital software architectures. IMHO, a strong governance of the natural evolution of IT systems to adapt to business change is what makes the difference. This nice article from Martin Fowler can help understand this.

What does this governance take? In my experience, it can be a mix of:

• Crossing the IT-business chasm and strong IT architecture leadership: strong communication between the two is key to take prudent decisions that can avoid technical debt in the long term. And this does not only imply to avoid fattening legacy systems because they are more productive, it also implies to not fall on the "fashionista" trap. A good IT architecture team is the one that can work together with business areas and translate technical design principles in an adequate manner in order to evaluate important decisions on IT systems evolution that can imply technical debt. In case this debt exists (it will) at least everyone has to be aware of it and its consequences.
• Having the adequate resources: I have to agree with mr. Dans on this one. It is more difficult to find good professionals to program COBOL systems that it is to find good web programmers. It is a matter of aging (I like the IT cowboy naming :)), so mainframe systems are clearly becoming more sensitive to technical debt due to a lack of qualified resources for its evolution in the future (but again, this does not mean that they are, by nature, worse in terms of being prone to it). Nevertheless, again, being a fashionista and incorporating the latest technologies is not always a good idea. Programmaing frameworks are evolving so fast that newer does not mean better.

I know that this topic can be very passionate and of course it will require further discussion. What are your opinions on technical debt? Do you think legacy systems are the ones to blame? What factors do you think are key to it? I will be happy to chat:).