In our last blog about tech debt, we discussed ways in which you could explain the concept of technical debt to non-technical individuals in your business. It’s important for everyone to understand the concept because otherwise, misconceptions can occur, and tech debt can gain a reputation for being a showstopper or not relevant at all. But it is an essential aspect of a company, and if myths about it circulate, it can be misunderstood.
Technical debt explains the inherent complexity of an underlying system using financial debt as a metaphor – in that you have to pay down some of that principle each time you change the system else, that principle is overwhelming.
This blog will uncover and explain some of the most relevant myths and truths about technical debt and offer you some solutions.
7 of the most important technical debt myths and truths
1: Myth – Tech debt only impacts engineers.
Truth – If only that were the case.
Tech debt affects many (most) individuals and teams directly or indirectly within a company, which is why it’s so important to understand:
- Leadership – engineering costs may increase, work completion may be slower, and objectives may not be met. In addition, there may be increased customer issues or lower customer satisfaction.
- Developers – tech debt can be frustrating for developers because it can prevent them from delivering work quickly and affect quality. If this frustration isn’t managed and reduced, then retention issues may threaten.
- Customers – may experience more system issues and bugs, which can impact product releases and scheduling (and add frustration!).
- Customer support – quality issues can occur, which may mean more work through more calls, queries and complaints.
Suggestion: It’s essential that engineers express tech debt in a way that makes sense for their audience. For example, the above list highlights how it will affect different groups, and this is a good start as you must ensure that all departments and individuals understand technical debt and how it might impact them.
Given that tech debt is used as an umbrella term for all sorts of issues (see myth 3), it can be really helpful to break down particular bits of debt into their impact on each of these stakeholders to enable sensible conversations about fixing it a bit at a time.
2: Myth – All tech debt is of the same severity.
Truth – Absolutely not!
Using the financial debt comparison, is all financial debt the same? For example, is debt to your friend of ten pounds the same as a bank loan of thousands of pounds that you can’t pay back the same?
Exactly.
With tech debt, you can have extreme severity debt, such as insufficient test coverage or high severity that might be in the form of code that is hard to read or is too complex for its intended use. Equally, you may have low severity debt, such as slow test times, which will not be the same as the riskier debt.
Suggestion: You could keep an inventory of the different debts and their severity. However, what may be more valuable is feedback from your colleagues. The area where the technical debt metaphor falls down is that you don’t have to pay it back unless you touch that part again; therefore, you may choose just to handle it as you get to it.
3: Myth – A company’s tech debt refers to one big technical issue.
Truth – In reality, tech debt isn’t one out-of-control thing but many different tech issues.
For example, as above, there will be different cases of tech debt within a company, with some issues being more severe than others. You can feasibly identify each tech debt issue and rate its size and impact on the business and its priority and cost to fix, as it’s not all equal.
Suggestion: If you created an inventory, you can use it to record each tech debt issue and prioritise. Otherwise, you can prioritise the debt you know exists.
4: Myth – All tech debt is intentional.
Truth – Tech debt comes from different causes.
Yes, there will be intentional tech debt caused by skipping process steps, taking shortcuts to meet deadlines or errors in logging code information. However, even though this is intentional, it doesn’t mean it’s caused by laziness or inadequate skill because sometimes shortcuts are required for several reasons.
But tech debt can also occur unintentionally, for example, when code is managed by someone inexperienced or carried out incorrectly due to time constraints etc.
Another significant unintentional source is tech debt incurred because the needs of the system have changed, i.e. code/systems that were good when they were written can become sources of technical debt as the business changes and develops.
Suggestion: There’s a key point here about learning from technical debt. For example, when you build a system, you learn about it. Therefore, debt is also around not putting that learning back into the system and letting it go to waste.
In addition, CTO Craft community member, CTO Jacob Midtgaard-Olesen explains, ‘You can’t avoid having to improve past mistakes, old designs, slow code, entangled UX etc. But I find that investing in how teams continuously improve, scale, enhance etc., the solution removes the majority of the “debt” conversations.’
5: Myth – You must do a full rewrite to fix tech debt.
Truth – When tech debt builds up, it can cause panic, and individuals may worry that only a complete rewrite can fix it.
However, this isn’t true, and it can lead to despondency and feelings that it can’t be fixed (or will be a huge task to do so); therefore, more coding shortcuts are taken, and the situation gets worse! If individuals think the only solution is a complete rewrite and they begin this, but it’s complicated and time-consuming, it might get rushed and once again (you guessed it), more tech debt occurs.
Complete rewrites are risky endeavours for engineering teams to take on. For example, if you commit to a complete rewrite while you are doing it (and it’s certain that it will take longer than planned as these projects can take years), you are not delivering value to customers for the business.
Suggestion: Carry out a series of fixes or a few at once. Use the inventory to highlight which ones are the high-priority issues and attack these first, but be careful not to go head first into a complete rewrite.
6: Myth – Tech debt is down to one or two people.
Truth – It can be down to many people.
As mentioned above, it doesn’t always occur by mistake or by an inexperienced individual. There are several causes, and tech debt can occur over time when old features are no longer relevant and their code isn’t refactored or removed.
Suggestion: Tech leaders must ensure that no one blames others for tech debt, as it will have multiple causes and should be managed and owned as a team, so everyone takes responsibility and works towards fixing it over time.
7: Myth – Bit rot doesn’t exist.
Truth – Actually, it does.
Bit rot refers to gradual fixes and enhancements over time, creating a loss of structure and causing tech debt.
Suggestion: Essentially, ‘all code is liability’, and in the long run, maintenance of code often costs more than the original cost of creating it. For this reason, a team should always consider how they can shrink their system (by removing features that provide little value) and the easier work of considering what to add to the system.
As a team, you will need to review code as some will be obsolete, and refactoring will be the only form of prevention.
Community member Chen Wang explains, ‘You have to pay down debt as an obligation, and you can choose what to do later when you have the option in hand. Coupling that with the lean start-up approach, it becomes a game of taking a risk by intentionally cutting corners to achieve short-term goals, with a downside risk of refactoring out those code defects later.
Your organisation must understand what tech debt is and its impact on productivity. By replacing myths with truths and solutions, not only can the rest of the business speak the same language as tech professionals, but they can work together to support tech leaders and keep tech debt under control. If everyone is aware of technical debt, you can work continuously on the key issues whilst retaining a healthy balance between developing new features and tackling technical debt.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more!