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.
