AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

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.

erase debt

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.

Qualitative Approaches
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.

Quantitative Approaches
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.

Comments RSS TrackBack 8 comments

  • seo tutorial

    in September 12th, 2012 @ 02:08

    Hello. magnificent job. I did not expect this. This is a great story. Thanks!

  • Outlet Michael kors

    in September 12th, 2012 @ 05:08

    Very cool, some wonderful points! I appreciate you making this post available, the rest of your site is also well done. I hope you have a great day.

  • Brittany H Martin

    in September 17th, 2012 @ 22:11

    You need to participate in a contest for among the finest blogs on the web. I’ll advocate this web site!

  • like this

    in September 20th, 2012 @ 05:01

    I didnt search this, but I love this, found it enlightening! Keep up the awesome work!

  • timothykgoadpolo blog

    in October 8th, 2012 @ 19:21

    nice and thanks.

  • samedifference

    in January 13th, 2013 @ 20:27

    A fascinating discussion is worth comment. I think that you should publish more about this topic, it might not be a taboo matter but usually people do not talk about these topics. To the next! Many thanks!!

  • www.prointegrated.com.my/images/banners/vuosyo.asp

    in April 21st, 2013 @ 18:55

    Normally I do not article on blogs, but I would like to say that this publish seriously compelled me to do so! truly great pos

  • www.troglerhof.it

    in May 21st, 2013 @ 11:51

    What I love about blogs is which they spark an concept in my brain. When that occurs, I feel as I need to comment with the hope it may be interesting to some individuals. Because you will find plenty of blogs and forums with numerous points of view, they question your comprehension. It is at these moments when you have important insignt other individuals might not have had, together using the blogger him/herself. I find myself coming back again to to your writings only simply because youve a number of very good insights and also you have been at this a very long time, that is really inspiring and tells me you understand your stuff. Keep triggering imagination in other people!