Red Green Repeat Adventures of a Spec Driven Junkie

Technical Debt: Take Time then Move Fast

One area that caught me by surprise is that a technical leader needs to make a decision on reducing technical debt.

Problem with technical debt is it the team incurs it by serving the business (i.e. moving fast). Yet, it is not attractive to business leaders to pay it back (i.e. “We asked for this, not create a mess doing it.”)

So, what should a technical leader do?

Do Nothing

Leaving the technical debt to get so large that the business must pay it back. I view this as extreme: “This will get their attention.” and honestly, irresponsible as a leader. Most of the time, this means a “total system rewrite”, which never goes well for any of the parties involved:

  • business: moves slower as they can’t meet their customers’ needs.
  • competitors: grow larger as they gain new customers and features.
  • team: frustrated as they are doing things over again, but differently.

Do It Right the First Time

The other extreme is to incur zero technical debt by Doing the Job Right the First Time™️. This is another extreme of forcing the technical debt issue upon business leaders, except from the beginning.

This is similar to doing a full system rewrite:

  • business: moves slower as they can’t meet their customers’ needs.
  • competitors: grow larger as they gain new customers and features.

Except:

  • team: are doing things at their own pace.

I have to ask: how responsible is a technical leader if they are not serving those that feed them? Depend on them?

Balance: Take Time then Move Fast

I learned of another way from Sandi Metz when she was on NYC.rb’s Practical Object-Oriented Design in Ruby panel:

Engineering must take the time to reduce technical debt.

The early days of the system, there is no technical debt - “Hello green field!”. As things change, there will be technical debt. Sometimes it’s needed. What should happen next?

Ideally, engineering adds an extra 10% time to their stories to continuously remove incurred technical debt.

This is an elegant solution. Technical debt should not be the purview of business leaders. At the same time, they should know when they have asked the technical team for too much, but not too late. Engineering should signal to them of the incurred technical debt by taking extra time then moving fast again.