Evaluate your technical debt with Sonar
The technical debt is a well-known concept that was invented by Ward Cunningham in 1992 and that he’s recently talked about in this video. Since then, it has been discussed and developed numerous times in blogs and articles. I am not going to describe it in great details here, I rather recommend that you read what it is considered as the reference article on the subject, by Martin Fowler. Here is an extract of this article that gives a synthetic view of the metaphor :
In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.
This metaphor seems to be accepted by many developers already and every day someone tweets about the urgent need to pay back his technical debt. But beyond the concept, when time comes to evaluate the amount to be repaid, there is simply no literature on how to calculate the debt or at least approach it. It’s like borrowing money to buy a house but 2 years later having no way to know what is the remaining debt and how much interest are being paid each month :-).
As stated by Martin Fowler, developers are good and sometimes make deliberate choice to borrow in order to buy time. That’s true when starting a new development as you know exactly the amount of technical debt… that is to say 0. But when extending or maintaining a legacy application, that’s another story as nobody knows exactly how bad it is. Further more you might even not be aware that you are borrowing money, when a developer simply does not follow best practices. That is why, evaluating even roughly the technical debt is very useful.
Before introducing this Sonar plugin, here are few funny and relevant quotes on the concept :
- Maintaining an application without any unit tests is like borrowing money each time you add or change a line of code
- Skipping design phase is like borrowing money to get a very “quick” and “predictable” return of investment
- Refactoring is like paying down the principal
- Development productivity decreases when interests grow up
- Managers don’t care about code quality, just ask them to pay the debt in order get their attention
- Bankruptcy is logical extension of technical debt uncontrolled… we call it a system rewrite
When discussing source code quality, I like to say that there are seven deadly sins, each one representing a major axis of quality analysis : bad distribution of the complexity, duplications, lack of comments, coding rules violations, potential bugs, no unit tests or useless ones and bad design. As you know already, Sonar actually covers 6 of them but the seventh one (bad design) should probably start shaking :-) as it is a matter of time it gets covered as well.
From this observation, we decided to build new metrics that reflect how much effort is required in order to get a perfect score on the various axes. In other words, what is the cost of reimbursing each of the debts in the project. By combining the results, we obtain a global indicator that we report in $$ to keep it fun ! Along with this indicator comes the repartition of each axis, i.e. how much did each axis participated to the technical debt.
The current version of the plugin is 0.2 and uses the following formula to calculate the debt :
| Debt(in man days) = | cost_to_fix_duplications + cost_to_fix_violations + |
| cost_to_comment_public_API + cost_to_fix_uncovered_complexity + | |
| cost_to_bring_complexity_below_threshold |
Where :
| Duplications | = | cost_to_fix_one_block * duplicated_blocks |
| Violations | = | cost_to fix_one_violation * mandatory_violations |
| Comments | = | cost_to_comment_one_API * public_undocumented_api |
| Coverage | = | cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of coverage is the objective) |
| Complexity | = | cost_to_split_a_method * (function_complexity_distribution >= 8) + cost_to_split_a_class * (class_complexity_distribution >= 60) |
Beyond the calculation that is a broad approximation of the reality, the technical debt measure is precious as :
- it is a consolidated metric on projects, modules…
- it can be followed in the TimeMachine (historical data, trend)
- it enables to compare projects
- it is possible to drill down on it even to… the class
As a first version, you probably noticed that we took some options, however most of the values for costs can be adjusted in the plugin configuration.
The plugin has been installed on Nemo, the public instance of Sonar, that now calculates the debt of more than 80 Open Source projects. The plugin relies only on the available Sonar extension points and is good example of advanced metrics that can be computed with Sonar.
I am going to stop here on the technical debt for today, but would like to simply mention what we plan to add to it next : interests, debt ratio and project risk profile. I let you now go back to Sonar to install this new plugin as I am sure you want to know what is the technical debt of your project…
What a brilliant posting.
This posting shows me that buying companies must
insist to review the code they buy! If they do not,
the selling / implementing company can build up a big
technical debt and got the buyer locked! And so get a
competitive advantage (hoping to clean the debt later…
*rofl*).
If the buying company reviews the code they might
see good code and the product will be able to
change and grow for a long time. So the product will
be a good investment.
You might argue that the selling company will not allow
their sourcecode to be reviewed by buyers. But if the buyer
just does it with the eyes at the customer location and they use
metrics tools like sonar there is no risk to steel code
or ideas. And if the outcoming metrics are good this would
be a further argument to buy the product.
So it might be time to establish a new notion for this like
“buyers metrics review” (BMR) as a common principle for
selling / buying software. A long way to go but perhaps a
good start now…!
Best Regards
Stefan Edlich
By Stefan Edlich on June 22, 2009 at 11:23 am
Have you already thought about what such a metric could cover ?
Olivier
By Olivier Gaudin on June 23, 2009 at 10:21 am
I do not mean a special metric. It could be a mix of any useful metrics as the technical debt metrics you have given.
The point I meant was that we should fight for a common understanding in software development:
* The developing company “must” use something like technical debt. For internal quality and for marketing!
* The buying company must insist on getting real technical debt numbers to ensure they buy a system of substancial quality.
This should be a part of a software quality manifesto and a common procedure between the seller (developer) and the buyer.
Best Regards
Stefan Edlich
By Stefan Edlich on June 23, 2009 at 11:16 am
This plugin is really cool. Keep it up.
By Lars Vonk on September 25, 2009 at 1:28 pm
What an amazing concept. Great job!!!
By Jeff anderson on October 24, 2009 at 3:56 pm
Wasn’t it Jerry Weinberg who first came up with the notion of “design debt”?
http://en.wikipedia.org/wiki/Gerald_Weinberg
By Steve Wall on November 6, 2009 at 6:22 pm
Hi guys,
Cool article. In terms of a prospective measure of bad design, could package cycles perhaps be one of the elements?
I’ve found that seeing cycles is often the smoke that leads to the gun that killed the design…
By Jan Naude on March 10, 2010 at 4:32 pm
That is it ! http://docs.codehaus.org/display/SONAR/Technical+Debt+Calculation
This is going to be available in version 1.0 of the plugin : http://docs.codehaus.org/display/SONAR/Technical+Debt+Plugin
Olivier
By Olivier Gaudin on March 10, 2010 at 11:18 pm
Maybe it’s just a way to make few aspects of s/w development get more attention from the business managers. Whatever it is, it seems good idea similar to Value Engineering concept. What I like to know is what factors has gone into calculation of costs.
Say if we take this case
Duplications = cost_to_fix_one_block * duplicated_blocks
What is the split of cost_to_fix_one_block? If someone says it’s 1 hour, what criteria did they used to come with this value?
fix the block itself — may also mean that you may be adding a new method which will hold the new block. So, you may need to add a test case to cover that also..etc
By Navjot Singh on April 2, 2010 at 12:18 am
You’re right Navjot, all costs have been defined according to our own experience and are “just” approximation. What is important is not so much the absolut values but the tendency and debt ratio.
By Freddy Mallet on April 2, 2010 at 6:27 pm
Is there API to get below information separately.
1) cost_to_fix_duplications
2) cost_to_fix_violations
3) cost_to_comment_public_API
4) cost_to_fix_uncovered_complexity
5) cost_to_bring_complexity_below_threshold
By Mallari Kulkarni on February 28, 2011 at 1:40 pm
Hello Mallari, please use the Sonar mailing list to ask such question. Thanks, Freddy.
By Freddy Mallet on February 28, 2011 at 5:29 pm
Excellent post!
By Priya on July 5, 2011 at 10:22 am
Thanks for this post. Very informative!
By Manilal on May 8, 2012 at 6:13 am
Does sonar has Technical Debt plugin for .NET?
By Chirag on August 9, 2012 at 5:22 am