Technical Debt tracking supports projects to “do it right”

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”.

Would you recommend this article?


Thanks for taking the time to let us know what you think of this article!
We'd love to hear your opinion about this or any other story you read in our publication.

Jim Love, Chief Content Officer, IT World Canada
Donna Lindskog
Donna Lindskog
Donna Lindskog is an Information Systems Professional (retired) and has her Masters degree in Computer Science from the University of Regina. She has worked in the IT industry since 1978. Most of those years were at SaskTel where she progressed from Programmer, to Business Analyst, to Manager. At one point she had over 48 IT positions reporting to her and she has experience outside of IT managing Engineers. As a Relationship Manager, Donna worked with executive to define the IT Principles so departmental roles were defined. As the Resource Manager in the Corporate Program/Project Management Office, she introduced processes to get resources for corporate priorities. In 2003 she was given the YWCA Woman of Distinction Award in Technology.

Featured Download

IT World Canada in your inbox

Our experienced team of journalists and bloggers bring you engaging in-depth interviews, videos and content targeted to IT professionals and line-of-business executives.

Latest Blogs

Senior Contributor Spotlight