Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Limits of the Technical Debt Analogy

DZone's Guide to

Limits of the Technical Debt Analogy

The concept of 'Technical Debt' is a useful one to explain and justify decisions made in project design and management, but is it always useful? Does it have its limits?

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

The triangle of project management is a well-known model, used through and through for ages.

Triangle of Project Management

I assume most software developers, even junior ones, are familiar with those:

As for my personal experience in the software industry, all projects have been behind schedule, with only a few exceptions for small projects (some man-months). The reason might probably because initial estimations were too low, either by accident or on purpose, but that is a subject best tackled in another post.

Now, Project Managers also have been taught about the Triangle of Project Management. The idea behind this figure is that when things start to go badly, in one or more of the edges, one has to make tradeoffs on the other(s) edge(s). For example, when the project runs behind schedule, scope might be reduced to keep it on track.

However, the above triangle is wrong - or at least incomplete. The real model should look like this:

Triangle of Project Management

This version of the model is rarely shown, plus quality is hard to define, hard to measure and doesn’t appear in most dashboards. In essence, when schedules run tight and/or costs start to over-burn, nobody cares about Quality anymore (if anyone did before). It’s a death march toward delivery here and now, and nothing should stand in the way.

I wrote it’s hard to define Quality. That’s true even for software engineers. Even widely accepted metrics such as link:{% post_url 2014-10-05-your-code-coverage-metric-is-not-meaningful %}[code coverage^] are not meaningful. Lack of Quality, however, is universally acknowledged by programmers: a seemingly simple feature takes ages to develop because the existing code is a tangled mess, or there are no/not enough tests, or… (insert you favorite here).

Because software engineers are despite widespread rumors not only creative people but also communicative ones, they came up with the concept of technical debt:

Technical debt (also known as design debt or code debt) is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".

Technical debt can be compared to monetary debt. If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Unaddressed technical debt increases software entropy.

— Wikipedia

That was a stroke of genius! Even people who were clueless about code, software development and software quality could understand finance fundamentals. If you get indebted to the Great Bank of Software, then you’ll have to repay your debt later… plus interest.

However, I’m afraid this idea has only marginal benefits compared to the previous situation, because of one very persistent trend, silos. Think about organizations work: when an idea forms, it gets translated into a project, with a dedicated budget. To steer the project is the Project Manager. Now, if the project succeeds (and yes, it happens), the application becomes part of the assets portfolio and is considered a product. It’s assigned a Product Owner, who in most cases is not the same person as the Project Manager. In layman’s terms, the Project Manager incurs the debt and ru(i)ns to the next project while the Product Owner has to pay the debt!

An "interesting" development is for the PO to continue to incur technical debt to lower maintenance costs in order and thus improve his career path, get promoted as fast as possible and pass the buck to the next poor sap in the line.

In this great age of silos of everything, projects, departments, information systems, budgets and of course responsibilities, even if everyone can understand technical debt, many choose not to care about it - and leave the next guy to handle the problem they created in the first place.

Of course, it’s not specific to software, as political figures, unfortunately, prove every day…

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
costs ,development ,technical ,work ,technical debt ,manager ,solution ,project manager

Published at DZone with permission of Nicolas Frankel, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}