Is Technical Debt Always Caused by Business Decisions?

Developing the projects, you may face circumstances that will require the speed up of the development process. For example, you need to bring the app to the market in three months to make considerable revenue, release a product on a specific date or meet the deal’s requirements.

You go to the development team, who will inform you that they will need six months to build the app. So you ask them what they can do to speed up the development. 

You make simpler UI/UX, reduce some of the functionality, take fewer complex tools, and avoid automotive tests. All of this is pushed to the next stage or later work. This is when the technical debt appears.

Technical debt is usually a result of prioritizing release or development speed over well-written code and better solutions in the long term by choosing quick fixes. It sounds like founders and managers are the ones to blame for debt, as they require their development team to sacrifice quality over fast results. Is this always true?

In our article, we will discuss the problem of tech debt, who is responsible for it, and find out the most common reasons for it to appear. 

Reasons for the technical debts 

Don’t jump to conclusions that technical debt is something horrifying. It is inevitable in any project. Understanding the reasons will lead us to find the real cause of why technical debts appear in the first place.

Tech debt is usually caused by making shortcuts in development and may affect writing clean code, creating clear documentation, building clean data sources, or performing proper testing when the team has to speed up the process to meet a deadline. It happens in situations when in terms of business success, it has to be released faster, or when the resources or information are limited.

Another cause may be a lack of technical knowledge. If the team consists primarily of junior developers, who are expected to build a complex solution, they are more likely to create tech debt due to the absence of the guidance and mentoring. That’s why finding the right people for your project is important.

At the initial project stage, a poor understanding of project requirements may result in debt, as they will change along the way, and the team will try to figure out the functions in the process, which means a lot of useless code and changes. All this will also lead to rework.
 

Due to the codebases’ legacy that now has to work together, mergers and acquisitions can make the debt worse. The problem with legacy systems is that they make up a system of complicated interdependencies which also result in debt and a langsam process of fixing the whole product. 

The technical debt quadrant includes deliberate, inadvertent, reckless, and prudent causes. Understanding what square caused a debt will help you find the background and intent of your code issue.

• Reckless and deliberate debt is caused by prioritizing speed over quality, functionality, or other issues mentioned above.
  
• Prudent and deliberate debt comes when the benefits of the quick product release are higher than the quick delivery risk. The stake of the product is low at this stage.
  
• Reckless and inadvertent debt appears when the team does not have enough knowledge or instruments to produce the best code but is trying to do so. The team may not be aware of the errors they are making. 
  
• Prudent and inadvertent debt occurs when the team finds a better solution after implementing the code.

Types of technical debts

Deliberate debts are usually made on purpose to meet specific deadlines and the inadvertent happens without prior understanding. Thus, there are different types of tech debts: intentional and unintentional.

The first one is a conscious decision of the company to optimize at the present moment. Intentional debt may be long-term or short-term. Long-term debt has strategic reasons and occurs proactively, like meeting deadlines. Short-term debt occurs reactively and usually for tactic reasons, like using existing resources. The time of “paying off” the debt depends on the type of debt.

Unintentional technical debts usually happen due to a poor understanding of projects or tools, poorly written code, or accidental mistakes. The worst thing about an unintentional technical debt is that the team can only assess it when the software has already been integrated or they completed the software. 

How to manage a technical debt

As we mentioned before, a certain amount of tech debt is inevitable and doesn’t bring you troubles unless you postpone repaying it. If new depths occur and you never reduce the existing balance, such an approach may not only cause problems with the maintainability of your product in the future but even ruin your project. 

For some teams, it is hard to communicate and track tech debts — especially those which weren’t made intentionally. As a result, it may take much longer to find and fix the gap in the code base. 

So the most important is to include your debt in your tracking system: set the task, estimate resources, and schedule. Track your tech debt progress with the help of a debt backlog. The debt becomes critical if it hasn’t been resolved for more than 90 days. 

To deal with accidental debts, you should refactor your system systematically when it’s in a steady state. It will prevent the team from over-engineering, which results in slowdowns. Tech leads and product owners set the time to fix the tech debt caused by design decisions or changing requirements.  

Who is responsible for tech debt? 

As you can see, technical debt is not always a problem caused by business decisions. It is one of the reasons why there is time pressure, and the developers have to push some of the solutions for later or choose the easier way to resolve issues. This scenario is way better, as the debt can be easily tracked. In the end, it’s the responsibility of tech leads and project managers to pay the debt when it is suitable. 

But sometimes, tech debt is the problem on the development side, as your team may not be skilled enough to build the product in the best possible way. To avoid this, in the first place, you should take the team composition carefully. If you lack technical knowledge or want to focus on your business goals rather than try to find and manage developers yourself, you can always find devoted technical partners who will be in charge of the process. For example, here at KITRUM, we have 6 years of expertise in composing development teams for various kinds of projects in different domains through outsourcing or outstaffing. 

Ensuring the project’s requirements are clear and finalized will also help you avoid overwhelming technical debt. Of course, some changes may occur during the development process, but understanding the purpose and functionality of the project is essential. 

A technical debt is hard to avoid and if you wait until every line of code is perfect before deployment, your company may not exist for a long time. Good management, appropriate and thorough testing, realistic deadlines and expectations are the keys to reducing tech debt and fixing it at the right moment.