“I need a job,” the younger banker admitted, bracing for rejection. “But I understand if my past bankruptcy gives you pause.” The older banker studied him for a moment before responding firmly, “You repaid every debt, showing integrity and resilience. There’s no better type of banker.”
Years ago, I read a similar dialog somewhere–likely in a Ken Follett’s novel. Today, it bounced back suddenly thinking of technical debt in software projects.
In software technical debt is a metaphorical concept that describes the consequences of taking shortcuts, or making compromises, in the development process. These shortcuts may be necessary to meet tight deadlines or deliver features quickly, but they accumulate interest over time and can impact the long-term health and efficiency of a software project.
A less explored, but equally essential, concept is that of technical credit.
While technical debt embodies the negative consequences of shortcuts and compromises, technical credit represents the deliberate investments made in the software development process to yield long-term gains.
Both words, debt and credit, have Latin origins and have evolved over centuries to their current meanings. Debt signifies an obligation to repay, while credit denotes trust and subsequently the inclination to concede new debt. Technical debt can help a team to deliver features more quickly; technical credit of the team is the trust that any debt will be repaid keeping the software highly maintainable. High maintainability allows new debt to deliver more features more quickly in a virtuous circle of development.
Technical Credibility
Unlike financial debt, technical debt is not intentionally sought but rather tends to accumulate organically. For this reason, the technical credibility of a team assumes relevance as it measures the potential of the team to fix what needs be fixed timely.
When used for business reasons, and not for mere laziness, and when reduced below a safety threshold, technical debt is even useful to growth. A proven record of recovered technical debt represents a credit for the team and an allowance to emit other technical debt in the future. The sore point of technical debt is not much the quantity of it you have at a certain time, but how the team is able to manage it. Managing debt means knowing how to reduce it and knowing how to keep it to a minimum. This is the measure of the technical credit of a team.
On the Way to Acquire Technical Credit
Some developers write code as it comes, linearly, without paying attention to readability, duplication, organization and comments. Tight deadlines are only a mitigating factor, but not a complete excuse for neglecting these aspects. I have seen way too many developers delivering functional yet mediocre code with the promise to return on it, at a later time, to clean it up.
Well, this later time to refactor the code will never come. Being aware, helps acquiring higher scores of technical credibility.
Rather than looking at SOLID principles and other acronyms as the tables of law, one should give them a relevance akin to that of personal hygiene. Just as maintaining personal hygiene is essential but cannot by itself cure or prevent any serious illness, these programming principles, if overlooked, may lead to issues but will never be the root cause of major problems in a project. Mastering SOLID principles reduces the likelihood that more and more technical debt accumulates in your code. Seeking SOLID regardless, though, has no value per se. Being aware, helps acquiring higher scores of technical credibility.
Unit tests are often presented as a must. As I see things, the real must here is testing software and even more in general having a working strategy to keep the code working for the customers.
Per se, unit tests do require code that lends itself to be tested. This aspect is known as testability. More than just having hundreds of unit tests for the sake of the code coverage magic number, I would aim at having high levels of testability in the codebase. Testability alone is not sufficient to get the benefits of unit tests. At the same time, though, testable code makes it easier to write actual tests. And writing unit tests encourages developers to write clean, modular, and well-structured code.
From Debt to Credit
Addressing technical debt is crucial for long-term software stability and efficiency. Paying back technical debt can be a nuanced process because teams typically can’t halt their work, clean up the code, and resume. Instead, work on the recognized technical debt is often merged with ongoing development efforts.
Technical credit is akin to making strategic investments in code quality, architecture, and development processes. These investments may involve allocating extra time and resources to ensure that software is not only functional but also robust, scalable, and maintainable. Unlike technical debt, which incurs long-term costs, technical credit may generate long-term profits by making the impact of technical debt much less harmful and minimizing the maintenance costs of a product.
As in finance, technical debt and credit run on the edge of the same razor.
Pragmatic Opinions 