Why is technical debt often de-prioritized in an agile environment?

Tyler Van Gorder
|
March 17, 2022
The strongest steel is forged from the fire of the dumpster.

Key Takeaways

We are working in an agile environment!

In an "agile" environment, a product team will always focus on adding business value.

I think we can all agree that the tools and libraries available to software developers tend to change and evolve very quickly. A typical software project will use a large number of these third-party libraries and invariably there will be "drift".

As a contrived example, if you build a "small" web service that relies on five third-party libraries and those libraries each have 10 transitive dependencies, you suddenly find your service has 50 dependencies!

Continuing with our example, our service enters production and does it quickly because of all of these great third-party libraries. This pattern works so well, your company decides to introduce nine more services using all of these great, new tools.

Everything is fine...

Quick math: 10 services x 50 dependencies = 500

That is 500 "things" that contribute to a company's technical debt. Upgrading dependencies or implementing "best practices" are often de-prioritized over adding business value until there is a specific, triggering event that impacts the business:

  • A security vulnerability exists for one of your third-party components.
  • Your team has found a terrific Stack Overflow post (which contains an anti-pattern) and you find this pattern has been duplicated 800 times in your codebase.
  • A specific version of a library on which you rely has entered "end of life" and is no longer supported.

That regular expression was legendary

Have you ever found yourself in a company "war room" where all hands were on deck to address a production outage? You, being resourceful, find the root cause and write a regular expression to fix the issue across the codebase. Except, this type of automation is spawned as a reaction to the current dumpster fire at hand.

In the next series of blog posts, I will be introducing a better way in which to automate the work involved when addressing your technical debt.

Colorful, semi-transparent Moderne symbol breaking apart like a puzzleColorful, semi-transparent Moderne symbol breaking apart like a puzzleColorful, semi-transparent Moderne symbol breaking apart like a puzzle

Back to Blog

Colorful, semi-transparent Moderne symbol breaking apart like a puzzleColorful, semi-transparent Moderne symbol breaking apart like a puzzleColorful, semi-transparent Moderne symbol breaking apart like a puzzle

Back to Engineering Blog