February 3, 2022
Software development is a challenging process with many hurdles. There’s always looming deadlines, financial pressures, and unexpected bugs. Often the first priority of developers is getting the applications working. In the process, they compromise on code quality which leads to technical debt. As the technical debt accrues, the risk for something catastrophic happening goes up. So business leaders and managers need to understand the implications of letting structural problems accumulate. They can use a tool called maintainability index to help them get a better idea of unaddressed problems in their code.
In order to solve any problem, we need to first understand the nature of the problem. So, you might be wondering what does technical debt mean or look like.
Suppose you have been building an application with two features. Your developers spend too much time perfecting the first one. So they are already late on the next one. They try to catch up by hardcoding code for the second feature with the intention that they are going to fix it later. They manage to make it work but it needs to be redone in the next iteration of the software to make it more efficient. However, your business executives decide that they want a new feature as soon as possible. So the inefficiency in the second feature never gets fixed. So you have gotten into a technical debt that needs to be repaid through investing human work hours in the future.
Now imagine the above situation happening multiple times. Just like a small financial debt can snowball into a large one, multiple technical debts can create large headaches down the road. One of the big problems with technical debt is that it’s not often visible. In most cases, the project managers and technical leaders might not even be aware that technical debt is accruing.
Maintainability index (MI) has been around in the software industry since the early 1990s. It's a great way to add visibility to the problem of technical debt. Here is the formula for calculating MI:
V = Halstead Volume
G = Cyclomatic Complexity
LOC = Number of Source Lines Of Code (SLOC)
CM = Percent of lines of Comment (optional)
The original formula looks like this:
\(MI = 171 - 5.2 \times ln(V) - 0.23 \times (G) - 16.2 \times ln(LOC)\)
There are other variations. For example, Microsoft Visual Studio uses the following formula:
\(MI = MAX(0,(171 - 5.2 \times ln(V) - 0.23 \times (G) - 16.2 \times ln(LOC)) \times 100 / 171)\)
Even though the formulas look complex, the result produces a number that you can easily understand. Here is the break down:
80-100: Good Maintainability
80-65: Moderate Maintainability
65-0: Poor Maintainability
So, you might be wondering, how do these numbers help technical debt? You can use the maintainability index as one of the metrics to check the health of your code over time. If you notice that your code quality is going down that’s an indication of increasing technical debt. So you have an accessible way to measure and track the entropy of your code.
You can also group code areas and measure the maintainability index separately to pinpoint problems. Then, you can put more resources on problematic code segments to bring down your technical debt.
It’s important to remember that the maintainability index is not a perfect measure. It doesn’t take into account things like bad naming conventions or unnecessary comments which can make code harder to maintain. However, if your development platform provides a maintainability index, it’s an essential tool to keep your code cleaner and stay out of technical debt. It will help you avoid dire situations in the future.
