Debt (Tech & Life) —Should you Worry?

Debt is NOT ALWAYS BAD. Though one has to be aware of the Debt and the quality of the Debt. To Quantify the Debt right tools are needed; and to avoid accumulating Debt conscientious Developers are needed.

Debt be it in Life or in Technical world can be categorised as both Good or Bad.

“Debt is something, usually money, borrowed by one party from another.”

As everything in life Debt also has two attributes, Good / Bad.

Life:

Good Attribute is the returns on the Debt and the Bad Attribute requires you to pay interest and the Principal amount.

If Returns are more than the Interest + Principal then we would call it Good Debt and if returns are less than the (interest + Principal), let’s call it Bad Debt.

Tech:

Just like in real life, even in technology we tend to accumulate Debt. In Tech life though Debt can be accumulated knowingly or unknowingly.

As in life Debt may be good or bad.

Debt accumulated knowingly

Sometimes management has to go with a solution that is not well written/designed solution. These type of scenarios lead to accumulation of Debt knowingly.

There is a production issue. Developer quickly puts together a sample dirty solution to prove his thought process. The solution turned out to be great to prove developer’s point.

Even though the solution put together was not coded cleanly , was using old/decommissioned technology and had some design flaws; it was still pushed to Production for immediate consumption because the solution was solving a pressing issue.

Debt accumulated unknowingly

There are cases when Debt is accumulated unintentionally. It could be because a great technology of the past now has security loopholes; It could be because less competent developers added dirty code and code was not reviewed etc.

Good Debt

Sometimes even though the application has debt, but that application doesn't require any upgrade, is not exposed to security threats, and is doing its job perfectly well.

Such Debts are Good Debts as these applications do not have any interest payment (in terms of maintaining the code).

Bad Debt

On the other hand, a debt is a Bad Debt when its on an application that :

• requires regular enhancements
• is on an deprecated technology
• is exposed to Security Threats
• has several developer owners.

These Debts are Bad, as these debts mean

• more efforts from developers for same enhancements
• unsupported technology leading to support issues / bad user experience
• exposing entire organisation to security risk.

When should I worry?

You would have realised by now that I would say you have to worry if you are carrying Bad Debt. I would also add to say “not all Debt is Bad to carry”.

A Debt may help you in achieving something that can not be archived without Debt (ex: time taken to write debt free application).

If the solution is more valuable than the interest payable for carrying the debt; then you should “Knowingly” carry such debts.

Though in general try to always be Debt Light.

In reality, if the Debt in the Code is not cleared during initial Phase, as application size / complexity grows, efforts required to remove the debt grows exponentially. And with the Debt grows the Interest i.e. the impact to the solution deliveries (delivery delays/quality/security vulnerabilities etc).

Best Practises to minimise Debt

The best among all practises for any team to ensure proper Debt in the Code/Solution, is well aware Architect and Developer Team.

Other than that here are some tolls that can be used to check any miss-outs.

• Static Code Analyser (IDE) : All Developers should follow Static Code analysis tools. Some tools such as Lint Tool should be part of the IDE. Developers should ensure that they are fixing any Lint issues.
• Code Review : As part of the process, all code and Designs have to be reviewed for any design issues, code smell, security vulnerability.
• Deep Analysis : Use tools that would deeply analyse the code from all perspective such as Complex Code, Complex Design, Code Coverage, Security Vulnerability etc. One such tool is SonarQube.
• Enforce discipline using CI Pipeline : Ensure that the Pipeline does not build the artifact if there is any Debt that the team does not want to carry.