Measuring Technical Debt
We all are familiar with the term technical debt and how bad it can be for a company but how do we get our arms around how much technical debt we have? In this post, we’ll first address the types of technical debt then answer the question of why pay it down at all and finally jump into a few approaches for how to keep track or estimate the amount of technical debt in your system.
Types of Technical Debt
There are at least five different types of technical debt: design, coding, testing, documentation, and bugs. Let’s cover each quickly:
- Design – this is debt that is associated with poor or quick designs. Typically this happens when you don’t include technical operations (system administrators, DBA’s, network, security, etc) and quality assurance into the design. Often when rushed these team members get left out of the design process.
- Coding – this is what most people think as pure technical debt…poor or sloppy coding. This could be cutting & pasting of code, creating excessively long methods instead of breaking them apart, not adhering to naming conventions, etc.
- Testing – when you skip creating the unit tests or automated integration / regression tests this builds up debt. The interest on this debt is often paid every release in the form of extra manual testing.
- Documentation – if only one person understands part of your code base because it’s not documented thoroughly enough this is debt. You pay for it when that one person then becomes the bottleneck for lots of projects.
- Bugs – not always considered debt but bugs in the production code are debt that if it accumulates too much becomes a big hinderance to the usability of your service.
Why Pay Down Technical Debt?
Most people hear the term “debt” and understand the crippling affect that it can have on a nation or even one’s personal finances when left unchecked. The same is true of technical debt. When left to grow out of control you end up with scalability problems, sometimes availability issues, and much slower development of new features. As you start to pay down this debt you will gain lower maintenance costs, increased productivity, greater scalability, and often even higher availability. But before you decide to pay your debt down completely to zero you need to consider what the ROI would be and to do that you need to understand how much debt you have. Technical deb is like bugs in a SaaS product, the cost of getting them to zero isn’t worth the effort in most cases.
Let’s start with some qualitative ways of estimating how much technical debt you have in your system. Usually teams, especially ones with senior developers who have been around a while, know when the code is getting “spaghetti-like”. Often it just requires you asking the developers how the clean the code is being maintained. Another, less direct method, is to listen for indicators such as “don’t worry about documentation, just check it in” or “the only person that knows that is Brad” or “if I touch that everything breaks”. These are all signs that you have a lot of technical debt built up in the system and you had better start paying it down soon.
Some teams, however, prefer a more quantitative approach. For these teams we recommend two estimation methods. The first one is proactive, trying to keep track of debt as you accumulate it and the second is reactive, trying to estimate the amount of debt once accumulated. The first approach is for whenever you ask your team to release a feature faster than they normally would, you are incurring technical debt and therefore you should track it in a bug or feature tracking system. Put the estimate alongside the debt-feature of how long it would have taken the engineer to complete the feature as they normally would have minus the time already invested. This will provide a reasonably accurate estimate of the amount of debt.
For those that already have a bunch of technical debt but haven’t kept up with it in a tracking system, try looking at the cyclomatic complexity of the code. Eclipse has a metrics plug-in that can calculate this for you. While there is no conversion from complexity to technical debt, McCabe, the originator of the term and calculation for cyclomatic complexity, suggests that 10 is a good limit to start with and therefore anything above that should be considered an indicator of debt.
No matter what method you use to estimate or keep track of your technical debt the important thing is to address it before it gets out of hand.