Quantifying Technical Debt

I’ve written about the concept of [technology debt](/understanding-the-cost-implications-of-your-software-technology-purchase.html) before, in regards to COTS systems. But what about when you have control over the source code?

Dilbert on Spaghetti Code

There are a number of Software Engineering considerations that can lead to increases of this debt.

Architecture & Design: Please, no spaghetti code.
Duplication: Use of inheritance and polymorphism.
Coding Standards: These can differ per language and per business. Note considerations around driving down complexity.
Comments: Too little or too many can lead to issues.
Performance: The earlier performance is considered, the better, but note that Computer Scientists can easily and unintentionally increase complexity by optimizing code into cryptic yet efficient functions. Compiler-friendly may ultimately mean unmaintainable in the real world.
Security: Similar to performance, the earlier security is considered, the better. It should be baked into the process. Consider coding methodologies like OWASP and CERT that cover input validation, error handling, access control, and logging to name a few.
Unit Testing: Step 1 on the road to automated QA. If it’s hard to unit test, it may be too complex.
Bugs & Potential Bugs: The earlier they are found, the less debt is incurred.

As you may have noticed, many of these topics influence complexity. It should be no surprise that the more complex the program, the more technical debt it’s likely to have. Best practice is to balance each driver of technical debt to the extent dictated by the software project at hand (which is constrained by the resources allocated to it and the deadlines demanded of it). More code, faster - the mantra of Continuous Delivery - is useless if it results garbage code. Use of a code analysis tool like SonarCube can assist in quantifying technical debt. You also get the added benefit of automated Quality Gates to encourage your developers to perform the balancing act.