Technical debt: the nuts and bolts
When you have a lot of tasks to accomplish, you may either go through your to-do list until they are all completed or get some of them done and move others to a later day or week.
And that’s usually harmless. But sometimes more and more tasks pile up, making it impossible to accomplish them in a timely manner.
That’s exactly how technical debt works. Today, we’re going to cover this topic in detail, highlighting the challenges and characteristics of technical debt for each and every company.
What is technical debt
First things first, let’s start with the definition. Technical debt, also called design debt, is a term describing the “cost” of prioritizing speedy delivery over perfect code.
In order to ship features that meet business needs on time, companies have to make tradeoffs within their code. Also, shifts in the product strategy demand additional effort to support both the “new” and “old” logic due to their incompatibility.
Scenarios like these create technical debt within the product code.
Even though technical debt is “created” to deliver features quickly in the first place, you need to remember that building software is a marathon, not a sprint. In the long run, having too much technical debt makes it impossible to deliver new components. You will hit a technological wall, and what’s more, maintenance of the existing (unoptimized) code takes all of your teams’ time anyway.
Technical debt, just like any other type of debt, must be paid down at some point. In many cases, reducing technical debt helps you remain competitive.
By not paying technical debt back on time, the “interest rate” will continue to grow for any future repairs.
In some cases, debt is not necessarily a bad thing – and you can be sure that we’ll cover them later on.
Types of technical debt
We can recognize three types of technical debt (along with technical debt quadrants, which we are going to cover in detail in our next blog posts):
- Native technical debt is a debt resulting from poor engineering, immature business practices, or unstructured project management. Through training, sound practices, and wise business decisions, it can be avoided.
- Inevitable technical debt is a debt that cannot be foreseen or protected against. It is the result of the fact that when starting a project, we cannot predict with 100% certainty how successful it’s going to be. Therefore, some of the plans, decisions, and projects that are undertaken at the beginning of the work will be reevaluated during its implementation.
- Strategic technical debt is a debt that is incurred voluntarily, since the economic benefits outweigh the costs and negative consequences.
For example, an organization may consciously use abbreviations in order to bring a product to market at a crucial time. You have to be very careful when making this kind of decision, though. It is easy to forget about taking into account e.g. the cost of delaying the release of the next version of a product resulting from the time needed to repay the debt incurred during implementation of the first version, or worse, allowing the debt to not be repaid due to the influence of further pressure.
To spice things up, technical debts can simultaneously be debts of several types, containing elements of each kind.
Technical debt is also often put across in the form of four quadrants:
If you want to know more about this division, as well as types of technical debt, you may want to check out our article about technical debt quadrants.
Examples and scenarios of technical debt
In many cases, technical debt is incurred in one of the cases listed below:
- development of applications on a framework whose inefficiency eventually becomes a bottleneck,
- maintenance of a system that is not supported by its manufacturer and is threatened by external dangers,
- implementation of solutions that support old and soon-to-be-replaced systems,
- failure to maintain code readability, which becomes more and more problematic as additional code arrives,
- no use of scalable solutions in the case of slowly but constantly growing applications and their demand for resources.
The most common reasons for technical debt
We could list them all over and over again (which we actually covered in another article on our blog), but let us just mention a few:
The lack of a comprehensive concept
It results in the constant reworking of solutions as new requirements arise. The purpose of this process is to save time, but the result is that a lot of work has to be redone. This is often the result of a lack of awareness about the degree of complexity of the software system. Decisions regarding one aspect are undertaken without considering their impact on the other components (e.g. Integrating different systems without common data exchange plans).
External pressure to complete work faster
As a result, not all work is properly completed. There is pressure to deliver software sooner than expected, so it is released before it is ready.
Ignorance about technical solutions
Decisions are made by people unfamiliar with the specifications of certain software systems, or people do not know the system they are using (or only know it superficially).
A lack of information exchange, updates, team coordination, and documentation. Also, a lack of process owners. No designated people responsible for the processes and their results. This may also include a lack of competence of the people involved in the project, who take “shortcuts”.
No technological debt management
A responsible person is not appointed to ensure that no debt is incurred. There is no debt management strategy. Usually, you only react in a crisis. There is no awareness of debt. The emergence of debt surprises decision-makers.
Incorrect program implementation
For example, failure to take into account the organization’s business goals, a lack of necessary organizational changes, and changes in the position or tasks of employees.
No standards adaptation
A lack of adaptation to standards and good practices in the initial stages. Adapting to standards in the later stages may be significantly difficult, as overly rigid solutions prevent easy adaptation to additional requirements (no modularity, too many mutual dependencies).
Local, non-standard solutions may make it difficult to exchange data with business partners.
Technical debt consequences
It goes without saying that technical debt may have various consequences for your business. They can accumulate in much the same way as financial debt.
- Increased costs. In order to pay off your debt, you will need to increase your spending to create the right solutions.
- A major delivery delay. Delayed projects as a result of difficulties in assessing the complexity of implementation.
- Difficulty assessing the cost of repairs. The more debt, the longer it takes to implement new solutions, and this causes further increases in debt.
- A debt so deep that the whole project needs to be abandoned. There seem to be many errors in the created application, as well as incomplete functionality. When debt is substantial, it may be better to give up developing a project and begin a new project from scratch, as It would cost too much in the end for people to change the code.
- Low performance. Performance, reliability, quality, and endurance of software simply degrades.
Can technical debt be beneficial?
Technical debt, like a bank loan, does not have to be a negative phenomenon. Without it, many projects would never have come into existence.
A planned and carefully taken debt can bring a company quick business benefits at a relatively low cost.
Four scenarios should encourage entrepreneurs to take on technical debt.
#1 Iterations & gathering feedback
You need to work on your product quickly and iteratively when you’re dealing with a first big customer. Quickly moving in such scenarios allows revisions to be made to the product and feedback to be tested in a timely manner.
#2 Building an MVP
A small technical debt is acceptable when you’re trying to build out a minimum viable product and have yet to secure funding. The task of development is always cost-prohibitive. Bootstrapping doesn’t give you much flexibility in rewriting code that’s already working. You can accumulate technical debt until you’re in the position to spend.
#3 Making quick fixes in new features of an established product
In an established product, it’s okay to fix a few things when a new feature is added. Some killer new features may simply be a bad fit for your customers. The better you move forward quickly and accept that you may have to change things later, the less time you will have to devote to worrying about the things that matter.
#4 Premature release
The premature release of an application and fine-tuning it under debt-incurring conditions to receive valuable feedback from users. It can also mean lower software development costs if we know that a new version will be created from scratch soon anyway.
None of your scenarios meet those criteria? Then you might want to find out how to deal with the situation.
How to manage technical debt
In order to properly manage debt, it is worth determining both the causes and a strategy of action.
Companies that are aware of the consequences of debt incurring periodically look for answers to these questions. Even if the debt has not yet been incurred, it is worth identifying the risk of its occurrence.
Strategies for dealing with technical debt
There are several ways that a company can address technical debt. There are a number of factors affecting this choice, and there is no one-size-fits-all method. Below, you can find four strategies that are commonly used by companies to tackle – or not – technical debt.
- There is no debt management. React only in the event of a crisis.
- Conscious risk taking. Agreement on the costs of debt for the sake of other benefits.
- In-depth debt risk analysis. Immediate reaction to a problem to remove the cause, avoiding “Interest”.
- Long-term planning. Avoiding debt, repayment management (this is the recommended strategy).
How to tackle technical debt?
Achieving technical debt freedom is not always going to be possible. The question that you must answer is this: How can you mitigate the risks for your business?
To avoid technical debt (before it happens):
- Before incurring a technical debt, it is important to examine its size, impact on your business, and the associated risks. The aforementioned strategies may come in handy here.
- A regular investment in technology comes at lower total investment cost and fewer organizational requirements, so it works better towards avoiding technical debt than a one-off payment.
- The product owner should also be able to understand what technical debt is and how it affects your business. Also, the best way to avoid technical debt is to build a common understanding around what it is and change the mindset of your team.
To minimize technical debt (once it has occured):
- Make your entire team aware of the problem of debt and discuss a solution together. It is of utmost importance that the team knows how to identify, avoid, and combat debt.
- Break your application down into smaller, logical parts that can be refactored separately. Pay attention to the quality of the code, write automatic tests, and allow an appropriate amount of time for refactoring.
- Make sure you do not overburden your team with the delivery of new features unless there is a compelling reason to do so. Pay your technical debt off first, if possible.
- It may turn out that the total cost, seen as reasonable in the beginning, will end up increasing and increasing. The later that any adjustments (fixing, removing bugs, replacing parts) are made to the implementation, the larger those costs will be.
- People try to adapt their code to the standards already in place. If a given product has technical debt, other people may also follow the same development directions, creating additional technical debt. As long as one of the team members does not raise the issue of work standards, the current situation will last perpetually.
To sum up
While the Product Owner can help in paying-off the technical debt, by preventing, correcting pre-existing technical debt or prioritizing tasks etc., the full decision-making is down to the team. Planning and prioritization will assist in this process.
One thing worth repeating is that technical debt is not always clear cut. You may want to treat technical debt as financial debt. On the one hand, it allows us to buy things that we want or function at a certain expected level. On the other hand, it is dangerous if we do not repay the loan in a timely manner.
Consider employing a few additional people to assist in paying off the technical debt and implement improvements, so it will be possible to stay on track. This is considerably easier than dealing with partially functional code and having to put in so much work maintaining it that there isn’t time for any further development.