Analysis of Techdebt.org, the Open Database on Technical Debt
Analysis of Techdebt.org, the Open Database on Technical Debt
Join the DZone community and get the full member experience.Join For Free
Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner.
TechDebt.org is the first collaborative & open benchmarking dashboard on Technical Debt and Software Quality. The site provides you with several metrics regarding the technical debt for a large panel of applications. Information is anonymously collected thanks to ScertifyTM Refactoring Assessment , an open-source plugin for Sonar. Whenever an audit is performed on Sonar, the plugin anonymously collects some metrics and passes them to the site.
2013 began with good news from the front of war against technical debt. The fight had taken a good turn, with an overall increase of project's quality on TechDebt.org. Few months later, it is now time to take a look at database's evolution and see if we are still following the good path.
1 Database evolution
It has been a while since we took a look at TechDebt's database evolution. Since our last review in January the database has kept growing as more and more people contribute to it, through the use of Scertify Refactoring Assessment , our open-source plugin for Sonar.
Illustration 1 : database evolution over time
Since mid-January, the number of lines of code analyzed has grown from 526.54M LOC to 803.87M LOC. This represents 9.2M LOC added each day. Even more impressive is the increase of the number of project analyzed. In mid-January, the audits came from 3442 projects. In three months, more than a thousand of projects (an average of 12 projects a day!) have been added and TechDebt now covers 4525 projects. This is really important to see new projects coming into the database. Indeed, as more and more projects are added, with various characteristics, various languages, this allows us to get a more precise view of technical debt. Furthermore, those projects come from very different contributors, like open-source teams, development firms and various industries. This is really important to us as it allows to get a global view of technical debt, without restricting to a particular kind of applications.
To all of you who contribute to this database, many thanks for making this possible. If you want to stay anonymous, this is totally all-right. However if you would like to take the opportunity to let people know that you care about technical debt, do not hesitate to contact us to be added to TechDebt's contributors page.
Going back on illustration 1, we see that the overall technical debt is now around 50K work days, or 21M dollars. This represents a growth of 70%, while the growth of projects lines of code is of only 65%. This means that, in average, the newly added projects have a more important technical debt than those previously in the database. We will go deeper in the analysis in the next sections.
Illustration 2 : LOC by language
After this global overview of the database, let's take a closer look at the various metrics.
2 Metrics' history
TechDebt's dashboard presents various indicators that allow to monitor how the war against technical debt is going on. If you remember our report from January, we started the year with a small decrease of the technical debt. The question was : is it going to last?
Well, sadly the answer is no, it didn't last. As you can see on the various charts in illustration 3, the technical debt has restarted its growth.
Rules compliance is still quite good with 75.79%. However, in the same time the number of blocker violations is still alarmingly high and keeps increasing. There is now an average of 277.18 blocker violations per audit. If we combine this two indicators, we see that rules compliance remains stable while the number of blocker violations increases. This means that other violations with a lower criticity are suppressed, otherwise the rules compliance would decrease. This is a good point, however when fighting technical debt, one should first take care of blocker violations. Of course they are often more expensive to correct, but they are also more dangerous.
Here is an interesting article about how to prioritize corrections when fighting technical debt : link.
Two other indicators confirm the growth of technical debt : the average complexity per class and the code duplication. The average complexity per class is now of 15.67, while it was nearly one point lower in mid-January. The more complex a class is, the more difficult it is to test, to maintain and to make evolve. Violations regarding complexity are considered as blocker, since a good design is the base of every application. On the contrary, too complex classes can have huge impact on an application's life and can cost a lot in maintenance.
Code duplication is now of 7.34% while it used to be 6.64% in January. Code duplication should be avoided since it decreases the maintainability and evolutivity of the application.
Illustration 3 : metrics evolutionsSo, as we have seen, the good start of this year has not been confirmed, but it is never too late to start tackling technical debt.
3 Debt write-off thanks to automatic refactoring
One efficient way to reduce an application's technical debt at low cost is to use (semi-)automatic refactoring features such as those available in ScertifyTM. This allows to get rid of many violations in a few clicks, thus considerably reducing the application's technical debt.
The panel “Debt write-off” on TechDebt.org illustrates the refactoring opportunities for the Java language. As you can see, 33.5% of the technical debt could be corrected through (semi-)automatic refactoring features of ScertifyTM. This represents 17.93K days saved or approximately 7M of dollars, which is quite significant!
Illustration 4 : Debt write-off possibilities
The chart “Repartition by Quality domain” shows the refactoring opportunities according to the rules' quality domain. We observe that efficiency, maintainability and testability are the fields where the most rules can be corrected. Reliability also exhibits good possibilities, even if most of the rules require some contextual configuration. Those rules are considered as being “semi-automatically” refactorable.
Illustration 5 : Debt write-off possibilities by quality domain
To sum up, we have seen that despite a good start in 2013, with a decrease of technical debt, the growth has restarted. However, this is not fatality and every one is able to take pragmatic actions to efficiently manage and reduce technical debt. One key factor is to detect it as soon as possible, so do not hesitate to try ScertifyTM Professional trial version to see how you can fight technical debt directly into Eclipse.
Thanks for reading till here and see you soon for more TechDebt.org news!
As always, if you have some remarks or if you would like to see specific things in the next month's review, please let us know in the comments!
Published at DZone with permission of Armel Gouriou . See the original article here.
Opinions expressed by DZone contributors are their own.