Designing applications is often done with an eye on meeting deadlines. But trying too hard to cut development time can come at the expense of code quality. While many company directors are aware that there is a price to pay for building software quickly, they do not necessarily grasp what compromising code quality and its upkeep over time involves. Known as “technical debt”, this can have damaging consequences for the company’s budget. Find out how to keep this technical debt under control.
TABLE OF CONTENTS
- Technical debt: a definition
- Technical debt can be intentional or not
- The causes of technical debt
- The damaging consequences of technical debt
- What type of technical debt is your company facing?
- Finding the right balance between speed and quality
Technical debt: a definition
A software development project often includes a software design, formalised or not. Writing the code, if it follows best practice, ensures the consistency of the project and makes its maintenance easier:
- corrective: fixing software bugs,
- evolutionary: adding new features to the software.
Technical debt arises when best practice has not been followed while writing the code of your solution. In that case, a neglected software design will create future costs to be repaid in the form of additional development time, and increasingly frequent bugs. Technical debt should therefore be settled as early as possible to avoid tying up your teams unnecessarily.
Technical debt can be intentional or not
- Unintentional technical debt is due to defects: the design not being followed, coding rules not being followed, and so on. There is no benefit to be gained from this type of debt.
- Intentional technical debt is calculated in advance. Since favouring design quality increases the workload, the developers of a piece of software may choose to sacrifice quality in order to gain a benefit. For example, if a new version of the software has to be delivered quickly, sticking to the ideal design may jeopardise delivery of the product. In this situation, the objective (the release of the new version) takes priority. The intentionality of technical debt would therefore be to take on short-term debt in order to support the long-term evolution of the project. The key would then be to repay that debt quickly, once the objective has been reached, to avoid interest accumulating.
Would you like advice and support on this subject? Contact us
The causes of technical debt
When developing a solution, you can anticipate many things and spend a large part of your time planning your project or perfecting your code. But there are always a few things beyond your control that can lead to technical debt. These are:
- time pressure: development teams often release applications that are not complete because of the pressure to deliver the product within a limited timeframe. Development teams may even cut performance and quality in order to reach the market faster.
- constant change: even complete applications finished on time can be obsolete by the time they reach the market. Ever-growing customer expectations, the rise of new market opportunities, new cyberattacks and developer turnover create permanent challenges for IT managers.
- obsolete technology: modern application development generally involves several coding languages, frameworks and libraries, which may become obsolete or unsupported each year. Today’s Python could be tomorrow’s Visual Basic.
The damaging consequences of technical debt
Low-code specialist OutSystems surveyed many IT leaders around the world about technical debt, its cost, its origins and the solutions considered to address it. More than 500 of them concede that this debt is a problem they have to fight against on a daily basis. The results of this survey are eye-opening:
- Companies are currently said to be losing 6 000 € per second to maintain outdated lines of code.
- On average, companies spend 28% of their IT budget fighting technical debt. Whereas barely 33% of that budget is allocated to innovation.
- The larger a company grows, the more this problem intensifies: small and medium-sized enterprises spend 27% of their IT budget on technical debt. Large companies spend 41% of their IT budget on technical debt.
- 51% of large companies state that technical debt harms their conquest of new markets.
- 64% state that it will have a major impact on their future business.
- 69% state that it limits their capacity to innovate.
- 32% say that one of their biggest concerns is errors that only come to light after release to market.
What type of technical debt is your company facing?
In the quest for speed, is technical debt always harmful? To answer this question, it is useful to use Martin Fowler’s “technical debt quadrant”. This quadrant categorises the type of technical debt according to intent and context.
- Prudent and deliberate: when the team knows it is accumulating interest. Yet it prefers to face the consequences later. This decision is acceptable if the stakes are low enough or if the gain from an earlier release outweighs the costs of the technical debt.
- Reckless and deliberate: when the team may know the consequences and could avoid them, but still favours speed over quality.
- Prudent and inadvertent: when the team learns how the solution should have been implemented after the implementation.
- Reckless and inadvertent: when the team lacks the experience and blindly implements the solution. The team does not realise it is getting itself into a gigantic mess.
The left-hand side of this quadrant must be avoided at all costs.
Finding the right balance between speed and quality
Software quality and performance are paramount to a good user experience. Speed, for its part, is essential to reaching business objectives on time. Managing technical debt therefore requires a balance between quality and speed.
The best way to manage technical debt is to work on it continuously and to allow your engineering team to:
- see codebase problems,
- report and log those problems,
- prioritise and resolve them.
In this case, you therefore need to:
- Make it easier for your team to track and visualise technical debt.
- Have a space through which your team can discuss these codebase problems.
- Integrate your technology debt work into your existing workflow.
How to reduce technical debt
Reducing technical debt is not about rewriting everything, but about making it visible and repaying it regularly:
- Audit what exists — a Well-Architected cloud audit maps security, cost and reliability risks and prioritises the work to be done.
- Refactor continuously — build debt repayment into every iteration rather than into a “big project” that is put off indefinitely.
- Automate — automated tests, CI/CD and infrastructure as code reduce future debt with every release.
- Maintain operational upkeep — MCO (updates, patches, monitoring) stops debt from building up through obsolescence.
- Get support — an outside view from consulting and architecture helps in arbitrating between speed and quality.
Conclusion
If technical debt is not kept under control, it can grow very quickly and considerably affect your company’s budget.
The pressure put on teams to produce solutions ever faster, the regular turnover of developers within teams, or the obsolescence of development languages and frameworks are the primary causes of this technical debt.
But be careful, not all technical debt is necessarily harmful. It is up to you to work out which type of debt you are facing, thanks to Martin Fowler’s “quadrant”.
Finally, to keep it under control, you will need to find the right middle ground between speed and quality. Surround yourself with experts to do so.
The Premaccess team advises many companies on this subject. Do not hesitate to contact us.
Would you like advice and support on this subject? Contact us