Don’t let the numbers fool you
Eduardo Aguado’s latest article about technical debt, earlier this week, has created some controversy inside and outside Optimyth. I would like to give my point view, and I think a comment in Eduardo’s article is not enough. Technical debt is something that is worth measuring, it provides valuable information, as Eduardo said, but it is true that you have to look beyond the cold numbers. And bear in mind that what we are trying to do here is to quantify a metaphor!
So how do you look beyond? What is that valuable information it provides? and, are the numbers really useless?
Let’s start from the beginning. To calculate the debt you have acquired on an application, you have to measure using a quality model. That is, a set of rules, metrics, indicators and scores that will tell you how well or how bad your application was developed. The lower your scores the more debt you are likely to have. What is the quality model you should use? the one that fits your company needs. So the debt is not the same if you measure against quality model A or quality model model B. Make sure you always measure with the same one and that it is meaningful for you.
Okay, now we have a number, an amount of money (or time) you have to “spend” on your software to reach the appropriate scores that, according to your quality model, would mean that your software is “good” enough and you won’t be spending extra money paying interest in the form of expensive maintenance for example. Beyond the number itself, it expresses in monetary or effort terms how far you are from excellence. That is valuable information. Is it going to be exactly 547 hours effort? I wouldn’t bet my life on it, we are estimating so you can expect an error in the number. Yesterday at CERN, they announced that they found the Higgs boson and still there is a (tiny) uncertainty in their measurements. Measures and estimations have to be tweaked over time.
Let’s scratch under the surface of the number a little further. Now you want to know how to redeem the debt in comfortable payments. You need an action plan to fix the violations to the rules in your quality model and recommendations to improve other metrics with the goal of getting closer to your target quality scores. If your quality model, as it should, have its rules prioritized by importance and categorized by different quality aspects, the action plan will reflect those priorities and aspects so you can decide where to start.
So far, so good. You have measured your debt and you have an action plan to redeem it. The metaphor is producing very valuable information beyond the cold number. But as Eduardo pointed out, why do you want to redeem the debt if my application, as is, generates 2 times the amount of the debt? Two reasons: interest rates and risk.
The interest rates you pay may be still low and you could neglect them given the revenue generated by your application, but you are still exposed to the intrinsic risk of having a debt. The circumstances may change so the interest rates grow off the roof -your customers demand new functionality that forces you to a major refactor of the code base because that quick and dirty implementation that helped you ship fast, but is the seed of most of your technical debt-. Or you may be forced to pay back your debt in one month because your company has been acquired and you have to adapt to a new framework and you are not prepared.
The takeaways of all this. Measure your technical debt, put it in context and control it as much as you can beyond the cold numbers.
And one more, wouldn’t it be nice to have a tool with a proven quality model for different technologies that helps you measure the quality of your software -including technical debt- and give you an action plan based on your configurable goals? And if I tell you that is a free service in the cloud? Start taking good care of the quality of your software development.
Thanks for reading.
Meet the author Javier Salado
Marketing and content manager at Optimyth Software and editor of this blog. With 20+ years experience in IT, he has done everything you can do in the software industry: developer, designer, architect, project manager, pre-sales and product marketing. One-man band for corporations and start-ups.
Leave a Reply
Follow us
Subscribe
button in the bottom right corner