Technical debt - Part 1 - What? Why? How does it affect your business?

What is Technical Debt?

Technical debt. Sounds scary, doesn't it? We'll show you the bad, the good and everything in between. This part will be more theoretical, but no less important. At the end of the article we have also prepared a real life example of technical debt and its implications. Now that we've said that, we can get on with it.

Wikipedia describes it like this:



In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

While the description is generally somewhat correct, it is not that simple. Technical debt is a hidden cost of every IT project, but not every case is dangerous or caused by bad decisions of your development team (as you will see in the explanation below).

The word “debt” is no coincidence, as it has many attributes in common with economical debt. It is absolutely important to “pay” it back regularly. Ignoring and accumulating the technical debt can lead to fatal consequences, in worst case scenarios even bankruptcy. In the software development world that means such a software, that doesn't work or can't be further developed which leads to significant investment losses.

Fun fact: In the American study "The cost of poor quality software in the US" from 2018, Herb Krasner calculates that the overall cost of poorly made software is approximately $2.8 trillion. By comparison, that's more than the GDP values of most of the world's countries.

Most Common Types of Technical Debt. Technical Debt Examples

So, let's see what types of technical debt you can usually encounter. Martin Fowler has great article, which we agree with. There are basically 4 types of technical debt.

1. Prudent & Intentional - This is a calculated bet. Team knows that the technical debt is accumulating, but they decide to continue delivering the project. This solution is acceptable, if the risk is small or the possible yield from the earlier launch is high enough to cover the "repayment" costs of the initial technological debt.
2. Reckless & Intentional -  This is the worst one. The development team intentionally chooses the shortest path to get the the final goal, while not taking care of implications of technical debt, arising issues and higher costs later down the road.
3. Prudent & Unintentional - The team is knowledgeable, capable, uses best practices and chooses the best solution known to them at the time. The problem is that IT as an industry is constantly evolving and every year there are new ways to approach and solve different issues. This is also the reason why we mention that technical debt is part of every IT project. Over the years, there are better ways to solve the same issues, so to improve your project, you refactor. Agile Manifesto actually has great opening line:
   
   
   We are uncovering better ways of developing software by doing it and helping others do it.
4. Reckless & Unintentional - Team is ignoring design practices or clean code, usually because of the lack of experience, without even realizing how much problems it's getting into.

Most Common Causes For Technical Debt

Now we know most common types of technical debt, but what are the most common causes beside the ones mentioned above?

• Time pressure,
• insufficient testing,
• outdated technologies,
• lack of any documentation,
• messy code,
• wrong architecture,
• lack of skills of the development team.

Time - Cost - Quality

Business world has couple of "golden rules" and here is one of them. From the well-known trinity of Time - Cost - Quality, you can have only two. If you push your development team to build something cheap and fast, you won't get quality. If you want quality and fast delivery, it won't be cheap. That stands in custom software development as much as anywhere else, if not more. The wrong choice of two of these three options can often cause the technical debt.

We are not nerds and we understand that sometimes technical debt is unavoidable and is something that even makes sense in a particular case (e.g.: rapid MVP development for market validation). In this case, when you have limited resources and want to test the whole project as soon as possible, it may not make sense to build a complex architecture ready to scale to millions of users, prepare great automated tests, different sandboxes, whole CI/CD pipeline and other important aspects of modern development. You just focus on getting it done as quickly as possible. And that's okay as long as you understand the risks and costs involved in the future (even complete rewrite of the first version of the application could be required in some cases).

The thing is, calculated technical debt is sadly usually only a small percentage of projects.

What we usually encounter in Moravio when for example rescuing projects, is the exact opposite or more accurately, reckless & intentional technical debt from the description above. The technical debt is neglected, constantly increasing, undocumented and unmanaged.

There is also one more thing, which should be said. The IT industry is evolving like no other in the world. Technologies that are state-of-the-art this year may have significantly better major versions or alternative technologies next year.  That's just how it goes. You should always try to keep your project updated. We are not saying that you need to update on the first day that a new version of the technology is released (on the contrary, we strongly discourage this because of the bugs that usually appear in the first few days), but it is advisable to keep your project on the latest stable and long-term supported version within a reasonable interval. In a way, this can also be called technological debt in itself, which is why at the beginning of the article we talk about the fact that technological debt is part of every project.

How Does Technical Debt Affect Your Business?

Simply put, a lot. Here are just some examples:

• development speed and new feature cost,
• maintenance cost,
• development team satisfaction,
• customer satisfaction,
• your business processes,
• communication,
• last but not least your reputation.

It all depends on the nature of your business. All of this can also be directly or indirectly converted into monetary losses.

Main Thing To Take Away From This Article

Think of technical debt as a living part of your project. Set aside time for your developers to address it. Monitor and document it (simple updated JIRA task or Confluence page can do wonders). Work with your technical debt and continuously take chunks out of it. That's the only way to keep it under control in the long run. If you don't, many times higher costs will probably catch up with you sooner or later.

One Real Example of Technical Debt

In Moravio, beside providing Dedicated Development Teams, we also do Co-development & Outstaffing and Project Rescue.

It is on one of the projects we rescued that we want to show you today's example. The project was very neglected and the client from abroad approached us very late. The client was also not very experienced at that time. So he didn't notice the problems himself until it became clearly visible that something was wrong. Project was 2-3 major versions of PHP and Laravel framework behind, messy code, wrong architecture, thousands of unnecessary database calls, tenths of unused or not updated NPM packages, six different libraries handling images, one big file for CSS and JavaScript, wrong URL routing, no documentation & tests. You name it.

What were some of the results?

• It took more than 5 seconds to load most of the important pages. In extreme cases, some pages took more than a minute to load!
• Very slow development, because the code was very messy and not organized at all. One example can be that Laravel Blades were used in completely wrong manner. The Laravel Blades also contained JavaScript and PHP logic, i.e. what should have been in the Controller/Service/Repository was directly in between the HTML of that Laravel blade.
• The project was vulnerable to security threats. The reason was that it had very outdated versions of all the used technologies, which were no longer supported. In addition, it was in a state where it was no longer possible to update the core of the Linux server system without updating the technology of the project, which caused additional vulnerabilities to security threats.

Don't worry. We've successfully solved all the problems, but the example above is a great way to see the technical and business problems you can potentially run into.

This part was little bit more theoretical. In next part, we will explain what to look out for to discover technical debt, how to deal with the technical debt and few more examples from our personal first-hand experience.