Just in case you have accumulated tech debt and are prone to do so, it is better if you have a debt ceiling. It would help in retaining the debt to manageable proportions as even after proper cleaning of each and every feature there may be some faults let here and there which might accumulate gradually over time. Therefore, introducing a debt ceiling is probably the best practice to address tech debt and manage it to keep your codes clean and qualitative as always. When you tech debt would hit the ceiling, you would be alerted about the debt accumulation, the doors would be closed and disallow all further and new developments and everybody in the team would focus to get the code cleaned so that it goes back to the baseline.
Set It At Right Height
Care should be taken to properly fix the height of the ceiling. If you keep it too low, you would hit the ceiling often and have to clean it up regularly, more often than required which would mean loss of time, effort and money. On the other hand, if you keep the ceiling too high then lots of debt would get accumulated which may make the cleaning process difficult and time taking, if not impossible. This would once again mean a waste of time, effort and money as well. Therefore, setting the ceiling limit to the right level is a major concern and for that you should know how much debt you can take without affecting the business.
Quantify Well To Set
At this point, it is required to know the ways to quantify
technical debt accurately so that you can set the ceiling limit as well as the baseline to the perfect level. It may seem difficult to quantify technical debt but actually it is very easy to measure the amount of technical debt accumulated in your code. You can pick any scale from one to five and ask the team members about how they feel about the code and give numbers accordingly. According to this scale the debt baseline should be ideally set at 4 and the ceiling at 3, because debt affects inversely.
The Possible Metrics
There are several possible metrics to measure and quantify technical debt and you can learn more about it if you
visit here. Among them all such subjective quantification process and quality metrics is most loved by the developers. It is not only simple but it also visualizes the quality of the code along with it so that the developers come to know how much care should be taken to rework on the code. You can also use other metrics having different objectives like duplication metrics and test coverage metric to put some more input to the discussion and help the developer with subjective opinion.
Avoid Vicious Cycle
Just like any monetary debt, with having a tech debt ceiling in place you can avoid the vicious cycle of debt. You are also helped to get rid of the broken window syndrome wherein any new code developed is as bad as the existing ones. No matter, how you measure it, you should always stand by your code quality.
