What is Technical debt?
Technical debt is a term used in software development processes describing trade-off between choosing a quicker short-term solution that results in long-term consequences. Like financial debt, technical debt accumulates interest in the form of the extra effort to overcome problems that appear in the future.
In the financial world, a loan can be taken to pay for something with the intention of repaying that loan back with the added cost of interest. In a similar way, taking on technical debt can allow a company to achieve a short-term benefit, such as a faster time-to-market launch.
The danger is when there’s unawareness of technical debt and not planning to repay it in the future. Imagine falling into debt without knowing you’ve done so or not knowing what the consequences are if you don’t pay it back?
Technical debt can be managed effectively as long as it’s acknowledged and taken on deliberately. Whether you’re an organisation with commercial software products, or a solo developer creating software for clients, it’s important to be aware of the existence of technical debt and learn how to plan for it.
This article will cover the basics of what is technical debt and how to begin planning its management in software projects.
Definition of Technical Debt
Technical debt is a term used in the context of software development and has seen increasing interest as a subject area of study in recent years. Software development practitioners and researchers are now acknowledging technical debt as a challenge in the management of software projects and one that should be taken seriously.Â
However, technical debt itself is nothing new and has always been around. The term was first officially recognised from a description given by Ward Cunninghman in 1992. He described technical debt like this:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite…Â
The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
– Ward Cunningham, The WyCash Portfolio Management System
The definition of technical debt has somewhat evolved since Cunningham’s initial description. How technical debt is defined varies and it can be referred to in different analogies and metaphors when compared to its financial counterpart.Â
However, the general consensus on technical debt is the idea of describing a debt in the context of software projects that accumulates from choosing short-term benefits with potential negative long-term effects.Â
If you’re making a decision now that will cause your product to be more costly to maintain, scale or fix in the future, that is technical debt.
Where can we see the occurrence of technical debt?
Take a commercial software product under development. It’s not quite ready, but under pressure to be released into the market. Technical debt can appear by making a decision to launch the product without taking it through its full testing cycle due to the time constraints.Â
The long-term consequence of this is the cost of having to fix any issues that arise in the field. The extra effort that will take to address quality issues of a shipped product can be viewed as interest on the accrued technical debt.
Where there is software being built for commercial purposes, there is always the danger of accumulating technical debt.Â
If you work as a developer for an organisation, It’s likely you’ve witnessed technical debt.Â
Ever been part of a team that pushed a product out before it was production ready? And only for your team to later spend countless hours trying to fix bugs, refactor the code to improve maintainability or even address core architectural issues? All while juggling the pressures of other software projects? Then you’ve experienced the effects of technical debt.
Importance of Technical Debt Awareness
Don’t ignore it
“I think that there were plenty of cases where people would rush software out the door and learn things but never put that learning back into the program, and that by analogy was borrowing money thinking that you never had to pay it back.”
– Ward Cunningham Explaining Technical Debt
Technical debt becomes dangerous when one is oblivious to its existence or its purposely ignored. The interest on debt accumulating over time may reach a point where it becomes unmanageable and impractical to clear the debt. This is what you want to avoid.
Technical debt isn’t just a buzz term you should ignore. It heavily applies to many core aspects of software development and every developer should at least be aware of what it is. Technical debt continues to impact software organisations at a larger scale and it’s time we start learning to manage it.Â
That’s why in recent years studying technical debt and its management has become a hot subject amongst software engineering researchers and practitioners. Understanding technical debt is even more crucial if you’re in a software leadership position. By simply knowing what it is, you can already start shifting your mindsets and making decisions that take into account the effects of accumulating technical debt.
Making informed decisions
Martin Fowler, a well renowned software development author and speaker also added to the description of technical debt through a quadrant describing how technical debt can be classified:
If you’re in the bottom half of the quadrant, it means you’re unaware of technical debt and its effect. (Now that you’ve taken the time to read this article you should no longer be here!).
If you’re in the top half then you’re fully aware of technical debt. It’s now up to you to decide if you want to ignore it (left side) or if you want to take it seriously and make a plan for it in your management processes (right side).
This quadrant shows that by simply being aware of technical debt you can be more placed to better manage it and reduce the effects of its impact.
Basics of Technical Debt Management
Know the types of Technical Debt
The analogy of technical debt to financial debt makes it easier to communicate; however, it can be complex to effectively manage. To understand what causes technical debt you can start by becoming familiar with the different sources of it.Â
The way technical debt can manifest can be in different forms. Let’s go through the common types faced by most software organisations.
- Requirements: The gap between the captured product requirements and what was actually implemented.
- Versioning: Problems that arise with not using a clear versioning system or having a disorganised repository.
- Build: Problems with the building process that make it complex or difficult.
- Test: Any shortcuts taking in testing or a lack of tests.
- Defect: Any bugs or failures found in the software.
- Design: Technical shortcuts taken during the design stage.
- Architectural: Decisions made that compromise quality and maintainability.
- Documentation: Refers to documents on the project that are out-of-date, incomplete or a code base that lacks comments.
- Code: Refers to poorly written code that doesn’t follow best coding practices.
- Infrastructure: Using tools, technologies or configuration that are not optimal for the software solution.
Being aware of types of technical debt will allow software teams to identify its sources in their projects. The process of regularly analysing sources of technical debt can allow more deliberate decision making to be made that anticipates the accumulated debt cost.
Integrate effective management processes
Technical debt is not usually something engineering teams can 100% avoid. However, at the very least they should be aware of the consequences of accumulating this debt. By doing so you can plan to come back and pay back the debt and its interest.
Technical debt is often discussed along with the practise of Agile software development. Proper use of Agile practices can be seen as one of the keys methodologies to implement to better manage technical debt. In fact Ward Cunningham who first defined technical debt is also known for his impact in pioneering some of the concepts of Agile development.Â
How can a management strategy like Agile help with tackling technical debt? Take the concept of backlogs in Agile practice, which is a list of tasks that is being worked on by a software team.Â
Maintaining a backlog can act as a way for management to plan tasks that are targeted towards technical debt. Backlogs can include activities that will help address technical debt items such as planning time for code refactoring or improving test coverage.
Integrating a proper management process into software development teams can be a very effective method to tackle technical debt over time.Â
Conclusion
If someone asks you now What is technical debt? Can you describe it? If not, read this article again or read some other ones on the web! It’s important you get your head around it.
You can checkout other articles that I believe cover the basics of technical debt quite well such as from agilealliance.org or from sophilabs.co.
Also checkout this YouTube video from Ward Cunningham himself explaining technical debt!
Technical debt will source from different areas and accumulate different costs for different teams.
Being aware of technical debt allows teams to begin thinking of how they can set up methods to manage it in relation to their own set of unique challenges.
This is just the start of a series of technical debt topics. There’s much more to know about technical debt and learning how to overcome it.
Subscribe to our newsletter to receive updates and ensure you don’t miss out on future posts on this topic!
Did you find this article useful? Also checkout other articles you may be interested in below: