So one of the biggest challenges I’ve repeatedly heard about technical debt is that although the delivery team knows it exists, there is no easy way to measure the actual cost of technical debt. However, there are ways to help bridge the unspecific to the specific.
With technical debt, using a financial analysis of comparing addressing the technical debt now versus addressing the technical debt later (at a pre-determined point) will bring useful data to make informed decisions.
So how accurate is that data? What level of confidence will leaders place on it? One method to help bridge that trust gap would be to use technical debt evaluation tool like SonarQube that can give detailed counts of technical debt risks. This can then be used as a “ground level up” method of determining the full cost of fixing technical debt now and given as detailed evidence that this isn’t simply “developer guesswork”. From organizing the reported debt, the seven axes of Quality reported by SonarQube can then be mathematically estimated and used as supporting evidence.
The example chart gives a comparison that non-technical employees can understand. This speaks in clear financial figures and can be measured to determine progress and where key decisions can be made.
No longer does technical debt have to be the software delivery department wrestling with business. There can be a common ground for discussion, collaboration and agreement on how much effort should be made to resolve any accrued technical debt.
There are three primary types of Technical Debt:
- Naïve technical debt
- Unavoidable technical debt
- Strategic technical debt
Naïve technical debt is common where a specific best practice is not followed due to being unaware of the best design pattern, unfamiliar with naming convention, documentation guidelines or even coding guidelines such as following abstraction in development and having a method serve one purpose.
This happens more frequently with junior level developers, but even the most senior developers can miss things and as a result, create technical debt. My recommendation would be to use the guidelines in the books “Clean Code” by Robert Martin (http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) and “Pragmatic Programmer” by Andrew Hunt and David Thomas (http://www.amazon.com/s/ref=nb_sb_noss_2?url=search-alias%3Daps&field-keywords=pragmatic+programmer). This will include several Extreme programming principles such as code reviews, refactoring, TDD and pair programming to name some.
Unavoidable technical debt will happen due to upgrades in development tools that bring newer and often better ways to maintain custom solutions. Also, when scope changes are requested during mid development, that will have an immediate cost to it. What about adding a new feature to an existing web site so it better supports mobile devices? This too will increase the debt due to rewriting the system to support multiple modalities unless it was designed with that in the first place.
In some cases, like the last example, some unavoidable technical debt is really more naïve technical debt and can be avoided, but the third type of technical debt, strategic, is also avoidable, but instead decided (either intentionally or unintentionally) to be accrued.
For instance, skipping proper quality code practices like code reviews and refactoring in order to make a release by a certain deadline is an example of strategic debt. Continually placing refactoring tasks at the bottom of a product backlog or nowhere at all is another example of strategic debt. Strategic debt can be tackled by determining an actual financial cost of the technical debt and presenting to leadership in order to get buy in. This will be discussed further in future blogs.
This will be first in a series of blogs.
Technical debt is an interesting term that has been formed in the IT industry in order to have non technical businesses understand the cost of building code in a manner that causes higher maintenance and increased barriers to changing.
Technical debt is intended to have a financial consequence in it’s meaning to recognize it costs businesses tangible money, even though due to it’s complexity, technical debt is difficult to measure and hence difficult for non-technical business leaders to understand.
Technical debt if left unchecked, can make a company that depends on technology drag themselves to a complete standstill and often bring down businesses to liquidation. Technical debt will increase exponentially over time until it becomes unmaintainable. It’s happened before, even to the early days of the “killer app” Visicalc that was to be superseded by Lotus 1-2-3 and eventually Microsoft Excel largely due to technical debt. Only through regular code maintenance (via code reviews, refactoring) can technical debt be controlled over the long run.
I will cover types of technical debt and what they do in the next blog.