Second law of thermodynamics
According to the second law of thermodynamics the entropy of an isolated system never decreases; such a system will spontaneously proceed towards thermodynamic equilibrium, the configuration with maximum entropy. Systems that are not isolated may decrease in entropy, provided they increase the entropy of their environment by at least that same amount.
In layman’s terms, it means that any process that introduces changes into the system will only increase the disorder in the system, unless the disorder is passed onto the environment.
The law of thermodynamics is equally true for software systems as well. Any change introduced into the software will increase the complexity and disorder in the system. If this disorder is not managed, it will lead to more disorder.
The measure of disorder in the system is termed as “Technical Debt”.
Whenever new code is introduced into the system, the Technical Debt increases. If the technical debt is ignored for too long, reducing it becomes almost impossible as time progresses as more and more functionality is crammed with tight deadlines.
What’s worse is that in most software companies, the stakeholders and management do not know this is happening. So, no time is set aside for reducing the technical debt.
A good indicator for management that the debt is increasing is when features are taking longer than ever before to be implemented or when fixing a defect results in many other defects being opened. From the developers point of view, the indicators are that code is abnormally of high complexity, in-flexible and you are unsure what components will break if you modify the code.
In the previous section, we mentioned a couple of indicators that managers and developers could use to instinctively tell whether they are building up a huge technical debt.
However, in order to have a solution that is going to work long-term, there needs to be a more measurable indicator of technical debt.
Measurement of technical debt provides us two key aspects:
SQALE stands for Software Quality Assessment based on Lifecycle Expectations. The SQALE method measures an application’s technical debt in terms of the time it will take to fix the issues.
Once the technical debt is calculated, a health rating based on SQALE density is given.
The SQALE density formula is : Remediation cost / Development cost
It is also the same as : Remediation cost / (Cost to develop 1 line of code x Number of lines of code)
SonarQube is an open platform to manage code quality and track technical debt. It tracks the technical debt using the SQALE rating described previously. Because it integrates easily into any CI process, build softwares and repositories, you can get access to live data on your team’s technical debt.
SonarQube uses its own implementation of the SQALE model. Of course, it is configurable to use different models.
So, for instance, if there are 10000 lines of code, a technical debt of 20 days and each line takes 0.01 days to implement, the scale density would be : 20/(0.01 x 10000) = 0.2
The below listing gives a sample SQALE density and their mapping to SQALE Ratings. In our example, the SQALE rating would be B. If the debt is less than 10% of the time that has already gone into the application, the rating is A.
<=0.10 the rating is a A
.11 to .2 the rating is a B
.21 to .5 the rating is a C
.51 to 1 the rating is a D
anything over 1 is an E
It also does a lot more than just measure technical debt. It covers the 7 axes of code quality:
Not only it provides key insights into the various aspects of the code, it does so in a graphical manner using a web interface. This makes it a very useful tool not just for the developers, but also the management and other stakeholders.
Some key features of SonarQube are:
A live demo of SonarQube is available at http://nemo.sonarqube.org/