Is The Technical Debt Metaphor Actually Helpful?

by

The project triangle is a well known model to many, even the most junior of software developers know it.

screen-shot-2016-09-14-at-10-13-48-pm

According to the experience of the author of this post, almost all software projects end up behind schedule. And this is given that project managers are well versed in the significance of the triangle; the idea being that when things on one edge begin to degrade a trade-off needs to be made on the other edges to compensate. So when a project runs behind schedule the scope may have to reduced in order to stay on track.

However, the rendering of the model above is incomplete, it should really look something like this:

project-management-triangle-v2

The above version of the is not nearly as popular as the initial one, especially since quality can be a very nebulous term to define for those working on software projects. However, it is widely known that when a schedule is tight, quality is the first thing to be sacrificed. This leads to there being a general understanding of what lack of quality looks like, even if defining quality itself can be difficult.

Lack of quality is present when simple features begin to take up huge work effort due to previously existing code that is either a miss or severely lacking in tests (amongst other signs of poor code quality).

In order to deal with this lack of quality that developers were consistently running into but unable to address, the term technical debt was coined. Technical debt was a clever way to ensure that everyone, even those without technical knowledge, could understand what happens when things are traded-off during a software project. All you need is an understanding of a basic financial concept: debt.

If you don't pay back your debt, it accumulates interest and becomes harder to pay off the longer you wait.

Despite the ingenuity of the technical debt metaphor, its benefits may be a little exaggerated.

If you look at how organizations are organized you will begin to see why the metaphor has limited benefits. When an idea is pitched it can eventually turn into a project with a dedicated budget and product manager. Once that project is completed the application becomes a part of the businesses portfolio and is seen as a product. At this point the product is handed over to a product owner who is, most often, not the same person as the project manager.

What ends up happening is that the project manager will incur debt, to get the project completed on time, only to pass it off to the product owner who has to pay it off. After this, the product owner may continue to incur debt in order to keep maintenance costs low and receive praise for this. They may end up being promoted from the product and the leaving the technical debt to the next person.

When organizations are dominated by silos, even if everyone understands technical debt, and its consequences, they may chose to ignore it and pass it off to someone else. If this is happening, then does it really matter that technical debt is so widely understood?

To read the full post visit here.

Filed in: Technical Debt
Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|