Given the ever-increasing attention to technical debt, it is no surprise that it is on the minds of many top level executives these days. Technical Debt is a wonderful metaphor developed by Ward Cunningham to help the managers, executives and non-technical folk understand that that development may be building up software liabilities along with software assets. There are a wide variety of different opinions on what technical debt really means for the business’s bottom line; however it is definitely worth measuring but like any metric, it needs to be put in the context as it applies to the business.
What does ‘technical debt’ actually mean?
Let’s start at the beginning. Technical debt can be thought of roughly as ‘work that needs to be done before a particular piece of software can be considered complete’. In software this is typically cleanup work that should be done to improve simplicity, robustness, or consistency in a given piece of software. Explicit technical debt can be incurred consciously and intentionally (eg: intentionally taking some shortcuts that reduce maintainability in a piece of software because it’s known that the component will have to be rewritten in the near future) or accidentally (a new developer isn’t familiar with the correct, or accepted method for solving a particular problem and implements a clumsy or brittle solution Basically, having a lot of ‘technical debt’ for a business means that the system starts to deteriorate and will become more difficult to maintain over time. If you think of it like financial debt, you have three different strategies to deal with technical debt.
- You can choose to continue to pay the interest (cope with the technical debt, having to deal with the extra effort in future development).
- You can pay down the technical debt in one lump sum by replacing the system. This is a risky and expensive choice.
- You can pay down the principal, thereby reducing the technical debt by incremental refactoring and redesign. Although it will cost you to pay down the ‘debt’ in the first place, there may be an opportunity to generate savings for the company in the long run.
Why Technical Debt is unavoidable.
The fact is all companies will accrue technical debt as it is unavoidable on any development project. There is relentless pressure on development teams to deliver new innovation to the market faster than ever before and this tends to lead to a continuing debt accumulation. After releasing the software, there is usually not enough time to ‘pay back’ the technical debt that the business accrued. There is only time to fix the critical defects (pay back the interest) as there is a new business requirement to be met.
Moreover, technical debt comes in two forms: explicit described earlier and implicit. Just like compound interest, the implicit form means technical debt will accrue over time. A company will accrue additional debt unless they find the time and resources to deal with increasing complexity and areas of poor structural quality in their software. The longer you defer repayment of the debt by delaying fixes, or the more you increase the debt by adding further workarounds, the harder it will be to pay it off. As this chart shows, it is more difficult to find the time to pay back the “principal” at once rather than continuous refactoring.
Figure 1 — Accumulation of technical debt over time. (Source: Jim Highsmith.)
The most important aspect of this metaphor is that you will have to pay down the technical debt at some point. Why? Because as Steve McConnell suggests “If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets”.
Good versus Bad Technical Debt
This might surprise you – not all technical debt is bad. Just like the real world, taking on debt isn’t always a bad thing and sometimes it is justified. For example, a business can benefit from it by writing software that will enable the business to meet their customer’s needs, gain market share and competitive edge.
However, you will want to make sure that your technical debt is ‘good debt’. Meaning repaying the technical debt will have to become part of your development process. The only way to do this is if you have visibility into the quality of your code, and the mechanisms to identify, measure, and control your technical debt.
Managing your Technical Debt
Does managing your accumulation of technical debt make sense? You bet it does. Managing the technical debt is a liability for those responsible for governing the costs and risks of software portfolio.
So how do you start? I would suggest understanding and reducing the existing technical debt in an agile way (iterative, prioritized, and focused).
1. Measure Technical Debt
You will need to take inventory of the debt you have acquired on an application. It is best to measure it using a quality model. By applying a quality model to your software, you can then calculate the amount of debt you have, and align it to your business needs. It’s about developing a common understanding of the existing technical problems for various levels of the team.
2. Establish Prioritization and Plans
Once you have established the amount of ‘technical debt’ your application has, the next step is to prioritize the amount of work that is needed to reduce the debt. Paying back debt needs to be treated as a standard component of your agile development. Debt repayment should be based on your business priorities. Application managers will have to allocate time and budget for both new development and ongoing quality improvement. However, this will be the biggest challenge, and requires support from the business at an executive level.
Attention: When you are prioritizing and planning repaying your debt it needs to be put into context. Ask yourself does the debt actually need to be paid off. For example, if the debt is part of a rewrite then it is smarter to leave it as is and address the feature in the redesign.
3. Track your Results
As with any development, you want to make sure that your remediation efforts reduce your technical debt. As mentioned above, repayment of the debt is continuous and should be done in sprints. IT Managers will want to periodically review their progress and set new targets.
4. Collaborate with other Stakeholders
It is important to share the results with different stakeholders with the IT organization and the business because strong intelligence will help your capacity to contain and minimize it. It will provide the business with a great understanding the cost and risk to the business if it is not controlled.
It is also imperative to create an awareness initiative on why managing technical debt is in everyone’s best interest. Managing technical debt starts with socializing the idea and then engraining it into the corporate culture. This will ensure you will have quality software.
Technical Debt is just a metaphor for the quality of your software portfolio
But at the end of the day, it’s important not to get lost ‘numbers’ and remember that technical debt is a simple a metaphor for the quality of your software. If you ignore managing the technical debt, it will have disastrous effects to your business.
If you would like to explore technical debt as it relates to software quality, I recommended listening to Thomas Cagley ‘s podcast with Ted Theodoropoulos from Acrowire.
*Image Credit: robanhk