Reframing Tech Debt

> I had this idea of maybe simply having a "tech debt team"

Please don't do this. If it's one team's job to clean up the messes other teams leave, you've created a terrible incentive for other teams around working clean.

I remember one place where each project had a fixed-in-advance schedule and engineers were rotated among projects based on whoever was available when the project officially started. Since people rarely worked in the same area of the code base from project to project, the incentive was to get something working and then GTFO. The code of course got steadily worse. So then the company would compensate with major rewrites of the most garbage-y sections.

I've also found the term quite dangerously misleading. The 'tech' part of the statement makes it sound like the 'debt' that is getting in your way it's purely a concern of the engineering function, where it should be a concern of the business. The 'debt' part is also confusing - I have seen non-technical stakeholders thinking it can be dealt with like financial debt with more revenue or VC rounds in one lump sum, we don't have to worry about it because are a growing startup and debt is normal.

Two alternative explanations I've begin to use over the last few years that have helped:

1) Inertia / Inert Areas - the reason this 'debt' is a problem is it means future changes are hard to execute cleanly, and previously. An area becomes inert to change unless an intervention is made. For non-technical stakeholders they most important thing is often that we can keep making changes, so this sets all sorts of loss aversion alarm bells ringing in a way the term 'debt' doesn't - this is where you can start talking about risk, which crosses the divide between engineering and other functions quite well.

2) Product Debt - Yes in some cases code is just badly written, which is an engineering concern, but often the reason changes in Year 5 are hard to make because the domain / reality has moved on, and the assumptions baked into the code written in Year 2, no matter how clean the code, are now just wrong. For example, baked-in assumptions of how business works in Market A as you are expanding into Market's B and C. This isn't the fault of engineering, just the reality of a product that continues to persist - core changes are inevitable. Product leaders therefore need to also get strategic about when it makes sense to rethink previous decisions driven by product needs, and work with engineering leaders to mitigate otherwise you might end up in an inert ball of mud unable to hit goals.

In the most idealised vision of a piece of software, changes will get harder to make in a linear fashion if previous decision are not revisited will new information. In worst case it's more like an exponential graph, so intervention steps will always have to be taken.

As you say, once you're talking the same language, then you get into the details about what strategies to address this inertia / current conditions.

I agree. Tech debt planning reduces down to x% spent on "fixing bugs" which never works (or at least I've never seen it work). Explicitly engineering fixes to actual definable problems is the best solution, but it takes effort. Complaining is a lot easier :)

“Tech debt” is the software industry’s way of euphemistically describing their incompetence.

It’s a way to act like one “meant” to implement a shitty architecture instead of admitting one’s lack of ability and experience.

It’s the mantra of the expert beginner of which there are so many.

You think I’m wrong, but you know I’m right because you can’t define it with any precision no matter how hard you try.

The origin of tech debt is well understood among experienced development teams. If it were possible to avoid it simply by planning, then they'd simply plan to avoid it right at the beginning. It's not possible to avoid tech debt by planning because tech debt is not really an oversight. Tech debt is a direct result of the wrong priorities.

The development team does not set the priorities. The team are simply the builders, like a construction team. If you tell a construction team to change what they're building in the middle of building it, your project will take longer and become more expensive, and structurally/functionally will end up worse and worse as you continue to build on something not designed for it. Or if the builders simply decide to skip vital steps to move faster, then of course debt will follow; don't install a vapor barrier in your new home and you will soon find a quite large debt after it's completed!

The only way to prevent tech debt is to have good priorities and not change them mid-way. If you design it well, and have experienced developers, they can built it right the first time with no debt. But if priorities are compromised, debt will inevitably follow.

In terms of the "tech wealth" listed here, what they really mean is "be able to do your job"; have the right tools and processes so you can get something done in the right amount of time. Again, that's priorities. If you don't have some automation or tool, you have two choices: you can buy it, or you can build it. Building it costs more money and takes more time - debt!! If the priority is reduction of short-term cost, the development team can't just plan around that.