I am encouraged that projects have begun to track their technical debt. As Kevin Casey writes, “The name is more self-explanatory than most tech terms.” And Product Plan says an article in the Information and Software Technology Journal defines technical debt in very specific terms:
“Technical debt describes the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations…”
The same Product Plan article expands on the metaphor for technical debt, “Conceptually, technical debt is an analog of financial debt, with associated concepts such as levels of debt, debt accrual over time and its likely consequences, and the pressure to pay back the debt at some point in time.”
For decades, there have been logs of outstanding bugs found in testing but not corrected before the project is implemented. The term technical debt adds the concept that there are consequences to those decisions, and that there are strong reasons to prioritize the follow-up to fix things and clear that list.
Most of us are aware of workarounds that were left in place permanently and eventually cost too much. We may have seen a system with poor performance that slowed the work of key workers and/or was missing functionality that impacted the customer experience. All of these are important reasons that technical debt should be cleared up. There are other reasons too.
Generally, people do not purposefully create poor designs or code with bugs. Good ethics, as defined by CIPS, asks us to STRIVE TO ACHIEVE HIGH QUALITY IN BOTH THE PROCESSES AND PRODUCTS OF PROFESSIONAL WORK.
One of the interesting concepts that has been offered by Martin Fowler is the Technical Debt Quadrant that talks about the prudent but inadvertent technical debt that is created as we learn during a project and realize how the project should have been done.
The people creating these projects want them done right, and continue to be frustrated when business decisions implement the system before they can be proud of the quality of their work.
An asana article says, “Any unresolved debt more than 90 days old should be treated as critical.” It describes two ways to address technical debt and says, “Similar to paying off a credit card, both approaches allow you to pay off small increments of debt until the grand total is paid off.”
I would agree that it is urgent to clear this debt for business reasons, but also because of the impact on the staff. After describing several other impacts, Kevin Casey describes the human toll of technical debt and the talent troubles that it may flag. He says:
“Finally, unsustainable technical debt can be both an underlying cause and a symptom of greater problems in your organization – a crummy culture, broken processes, and so forth. This means a technical problem is also very much a people problem.”
Casey also cited Christian Nelson, vice president of engineering at Carbon Five, who said, “It has a significant human toll. Organizations that don’t take technical debt seriously – and dedicate time to keep it under control – will have a harder time retaining talent, and in the worst cases, a harder time hiring as well.”
It is very important, therefore, that we give our support to staff that are trying to “do it right”.
