tl;dr -- Avoid referring to technical debt as a thing, especially to business partners and stakeholders. We evolve technology; we don't take time to rebuild and rearchitect without solving a specific customer problem.

Technical Debt

I’ll usually refer to technical debt as a tool, like taking a loan out, we can do it, it might help accelerate efforts or reach the finish line sooner, but we’re leveraging ourselves. Unless we put a “payment plan” in place, we’ll ultimately end up bankrupt.

Technical debt is a tool we use sparingly.

How do we decide to take on technical debt? We're deliberate:

Product Managers and Engineering Managers work to ensure:

  1. We’re explicit when we take on debt, “Hey guys, we’re taking out a loan and incurring some interest.”
  2. We’re explicit about how we intend to pay back the debt, “Here’s where we’re reserving capacity on roadmap/plans to back this debt back.”

How do we pay down technical debt? We favor doing it opportunistically.

When a product team is taking on new work, we should think about each software change/additions/improvements we’re planning, and think about the systems we need to change, and then ask ourselves a few questions:

  1. What’s the right way to make this change? IOW, without cutting corners and incurring technical debt. (Avoid getting trapped by the sunk cost fallacy on existing code.)

  2. What would that cost to do it right from a delivery timeline perspective?

  3. Is there some technical debt in our way we haven’t fully paid back yet?

    • Is now the right time to “accelerate our payments” and fix this for the new change?

  4. Can we do this right and deliver on the customer outcome with a reasonable delivery timeline?

    • If yes, then we should always prefer this option and not take on any technical debt.

Thoughts on Managing Legacy Software

Avoid automatically calling any old or arcane software technical debt.

I've seen many technology leaders make this mistake and sometimes leads to poor decision making and ultimately wasted effort rebuilding systems that don't provide real and measurable value to customers or the organization.

"This system was designed years ago, nobody understands it, let's rebuild it the right way!" -- Some Software Engineer (also, me, at some point early in my career)

We must prioritize changes to systems and technology with specific and measurable outcomes for customers, the team, or the organization.

What do we instead?

If technology/software/systems are working and providing commensurate value, and there we aren't necessarily planning changes in this area, why are we devoting any energy to rebuilding it?

Let's instead make it easy to manage and change! We can do this by:

  1. Ensuring the right instrumentation and monitoring are in place.

  2. Ensuring the right build-and-deploy automation is in place.

Questions to guide whether we should consider rebuilding/investing:

  1. What's the rate of change for this system/technology?

  2. Is there an inherent risk of maintaining this technology? Vendor support, warranty, community support, etc.

  3. If the answer is "yes" to either above, then it's probably a good candidate to start evolving toward more modern modular technology.

"Poised to Deploy" as an Operating Philosophy

Finally, here's a great keynote from the 2016 Velocity Conference (that I attended!), where Richard Cook talks about the value of adapting systems continuously.

He argues that it's not the system that we need to focus on; it's the ability to make changes and adapt the system that leads to value creation. He calls it being "Poised to deploy." "Being unable to deploy is an existential threat."

I regularly emphasize the importance of instrumentation and build-and-deploy tooling for all systems as a first step. This makes it inherently easier to change the system and evolve and adapt it to customer needs.

Poised to deploy: The C-suite and adaptive capacity

"Resilience is sustained adaptability. Being continuously poised to deploy is the ideal state to grasp opportunities and cope with challenges. This sustained adaptability is expensive and requires full-on DevOps. We are exploring how this all works, and the results are surprising and encouraging." -- Richard Cook

Poised to Deploy

  1. Knowing what the platform is supposed to do;

  2. Knowing how the platform works;

  3. Knowing what the platform's behaviors means;

  4. Being able to devise a change that addressees 1,2, and 3;

  5. Being able to predict the effects of change;

  6. Being able to force the platform to change in that way

  7. Being prepared to deal with the consequences