Skip to content
DV
  • Articles
  • Journal
  • Micro
  • Links
  • Now

Tag: tech debt

link

Technical debt is not a thing

User Avatar of Dmitri Vassilenko Dmitri Vassilenko
· May 31, 2022 · 2 minutes to read

Technical debt is not a thing

So, in order to strategize – to decide what work to do in what order – we need to estimate, at the very least:

t: The amount of value that will be created by doing a given task
P: The amount of labor required to do the task


“Spend at least 20% of our time paying down tech debt” is not a principle. It’s an excuse to substitute our arbitrary personal taste for a realistic, evidence-based appraisal of cost and value.

I like the push to actually quantify tech debt and its repayment. 20% feels like a way to avoid thinking critically about the time investment.


“Technical debt” is just what we call it when the deferred value takes the form of a decrease in our team’s velocity.

There’s more to tech debt than just reduced productivity. There’s impact on users, such as due to inconsistent or slow functionality. There’s impact on the business due to higher security risk or breached SLAs because time-to-resolution is longer. There’s morale impact to employees, which reduces retention, etc. etc.


One way is to adopt the simple model of a time horizon. Suppose a team declares the following as their goal:

To produce the most value possible over the coming year.

This team has a time horizon of 1 year. So, when there comes a proposal to make a particular improvement to their productivity (be it a process fix or some automation or whatever else), they can estimate:

How many hours of labor it will take to implement
How many weeks it will take to complete that labor
How many hours of labor it will save them over the year (the remainder of the year, that is, after subtracting the weeks spent implementing)

In this way, productivity investments can be evaluated each on their own merit, rather than being lumped together into the “technical debt” pile.

While it’s useful to always have a time horizon in mind for any work, I don’t think this would actually solve any of the problems the author lists here. Whether the time horizon is a quarter, a year, or five years, direct work is likely to squeeze out all the indirect work, especially if they’re compared as equals. As flawed as 20% rule is at least it acts as a sort of “protection” against feature work completely consuming all the planned time.


Leave a comment
Post navigation
User Avatar

Dmitri Vassilenko

  • githubGitHub
  • twitterTwitter
  • mastodonMastodon

Backend distributed systems developer, living in southern Ontario, Canada. Occasional rock-climber, frequent video-gamer. Jack of no trades, master also of none.

Keeping notes on things I learn.
Writing to think.
It's a mess, but it's my mess.

← 🕸💍 →

You can use an RSS feed reader rss/atom feed icon to be notified of new posts. Just add the URL of any page into it and it should show the available feeds. Subscribe to a category (top menu bar) by using its URL.


If you'd like to receive my posts by email, please fill out the form below.

Lists*

Loading

Misc

  • Site changelog
This site is powered by WordPress and styled with the Autonomie theme