Developers have the choice to implement new features in two different ways: one is to do it quickly and messily, which will make future changes very hard. The other is a clean and smart solution, which takes longer to implement, but makes changes easier in the future. But why should the sponsors of a project accept higher costs for a clean implementation of a feature if the same feature, implemented with a messy solution, delivers the same functionality and costs less?
Although messy code works perfectly for customers if it delivers the desired business value, this will lead to an uncontrollable code base, extremely specialized developers and eventually to an inflexible software product. A sufficient amount of messy code may bring a whole software development department to a standstill.
Technical debt can take many forms, including deferring bug fixes or skimping on automated testing. It can also mean waiting to restructure or refactor the code until after a release. These activities buy you time in the short term but cost you in the long term. A disciplined agile team may make the decision to incur technical debt but will then pay off that debt as quickly as possible. Undisciplined teams may never pay off their technical debt.
If technical debt is not paid off, it accumulates just like financial debt, and just like financial debt the interest will continue to accrue. Didn’t fix a known bug? Now it’s out in production and your users are calling you about it. Time to put aside the new features you are developing and get that patch out! Deferred a needed refactoring? Now your developers are struggling to add a new feature that should have been easy. And what was that brilliant refactoring idea you had, anyway?
SonarQube shows you what’s wrong in the present – from the macro level to the micro. It also reaches back to the past to show you where you’ve come from; start analyzing a new project on day one and you can get a great perspective on how its technical debt has grown (or not) along with its size. SonarQube tackles technical debt by measuring the 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.
Fixing Technical debt
Test Driven Development
Refactoring (directly linked to a known requirement)
Automated Tests (Unit tests and Functional Tests)
Agile best practices