Let's Talk Tech Debt

Welcome to my Theory Thursday newsletter where I dig into various different theories and models relating to management, leadership and bits which sit on the edge of software/product development.

This is a set of sub-articles that live alongside my main newsletter which I publish every Saturday morning.

Today’s article is a little different to my other Theory Thursday posts, mainly because it’s more technically focused than simple management theory.

This post was born from some conversations I had with some fellow friends in the industry, particularly around a company we knew of that was struggling with some crippling technical debt and now facing some financial issues. Money was put into the wrong places, so instead of building out a stronger engineering team that focused on moving away from the technical debt that once allowed the product to get to market fast, the team remained small and unnecessary middle management was brought in with little effect.

Before we get stuck into the detail, let’s define technical debt to make sure we’re on the same page.

What is ‘technical debt’?

A simplistic view of technical debt is “it’s the result of prioritising speedy delivery over perfect code”. When I say “perfect” I mean well-engineered, thought out code that is easy to read, easy to change (extensible), has good test coverage, and can be shipped frequently.

You could also look at technical debt in terms of cutting corners in order to save time or money today, knowing that you’ll have to go back and fix it later on. However, there are a few more levels to technical debt than just this simplistic view.

If we break it down further, we can look at intentional vs unintentional technical debt.

Intentional Technical Debt

Out of the two options, intentional technical debt is the more measured approach to taking on less-than-ideal builds to a system or product. They are often calculated decisions which factor in a number of things like:

• Time constraints ?
• Budget constraints ??
• Skill constraints ???
• Feature constraints ??

The decision to move fast and take a hit in some of the areas identified in the above list can provide some advantages:

• Quicker to market
• Prevents overengineering
• Flexibility
• Faster feedback

If you're finding this article interesting, please continue reading where you left of over on my Substack here:

The Manager's Mindset - Let's Talk Tech Debt