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.
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.
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.
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,
- 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.
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!
- 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.
That's it for today. 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.