Dealing with technical debt is one of the greatest frustrations and demotivaters to development teams.

Technical debt is accumulated through out the software development lifecycle. Over time, the code becomes less and less clean which results in making changes more and more difficult.

Technical debt is usually the result of not being given enough time to solve a problem which results in any of the following:

• shortcuts,
• low quality code,
• poor documentation / no comments,
• a lot of compiler warnings
• “temporary solutions.”

Every minute spent on not quite right code is interest spent against the debt.

Technical debt = Work to be done = Principal Impact = Lost productivity = Interest

How to manage technical debt

Before you can manage technical debt, you need to define what it is at the project level and organization level. If you don’t define it and set goals you won’t get it!

The organizational stakeholders and project stakeholders need to define what quality is acceptable. If your company has any compliance or legal risk, you might need to spend time with legal determining what the bare minimums to meet those requirements are.

Use Metrics to Quantify Technical Debt

Creating metrics or key performance indicators for development can be difficult. Quantifying technical debt can start with some relatively simple tools to setup though.Number of rule violations: this metric calculates the number of rules violated from a given set of coding conventions.

Code Violations: If your coding conventions are standardized and you’re using a rule system to enforce them it should be really easy to monitor them. ESLint OR JavaScript Standard Style are wonderful tools for doing this with JavaScript. In my blog article 10 Tips To Become a Better Node.js Developer I discuss using a bunch of these sorts of tools.

Code coverage: it’s really important to have unit tests so we can prove that a unit of code is correct. Generally, you want 50 – 75% code coverage for any code that is being changed. Aiming above 75% is really difficult and will likely result in relatively useless tests that cover impossible exceptions.

For JavaScript developers, mocha + chai + istanbul are excellent at working together.

Cyclomatic complexity: this can be a really good measure to use for determining clean code. This metric is about determining how many functional paths there are in the code by analyzing all of the control statements (if/else/else if/, switch, etc). As the number increases, the difficulty in maintaining the code increases.

Compiler warnings: I like to include the number of compiler warnings as they are usually an indication of a potential problem or a future potential problem.

Bugcount: as technical debt increases, quality of the software decreases. The number of bugs will likely grow. Monitoring the number of (critical) bugs that pop up is a simple but useful metric to track.

Any other static code analysis tools and techniques could be really good potential metrics. It’s really handy to include these tools as part of your continuous integration / continus deployment tools.

You should pay back technical debt as part of your scrum process

Project planning and activity prioritization should consider repaying some of the debt during every release cycle. Agile considers the source code as one of the major deliverables – not normally things like documentation.

Codes that is hard to understand or change is often code riddled with bugs or future bugs and likely there’s some inherent security risks in the code. Part of the debt should be added into every sprint, but it shouldn’t ever be the sole focus of a sprint.

Items that should be changed should be added the product backlog with some sort of quantified estimate. Debt related items should be treated the same as any other regular item in the product backlog.

Take Responsibility

As a developer, it’s important to take responsibility for actions and push back when the business tries to keep reprioritizing new features over improving the codebase. Doing this isn’t hard if you can explain the why and how it will impact clients in the future.

Be understanding

Pretty much, no business can or should completely freeze development for years to rewrite or pay down technical debt. The best way to do this is to slowly refactor and spend a few people days during every sprint on it.

Summary

The only way to get the business to give you time to resolve some of the technical debt is to be transparent about the quantity of problems and what the potential impact is. If you aren’t monitoring the technical debt and reporting on it frequently the business won’t honestly know about the problem and won’t let it be prioritized.