|
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. |
And you can bet the farm that some dev (or team) was trying to build in some flexibility in to the models which might have added an extra 2 weeks to deliver, which would save months of re-development a year later, and was shot down with 'YAGNI!' or just... "we don't have time!"
For some reason "management" folks get to plan out for the next 4-8-12 quarters, but a dev putting in basic plumbing to accommodate change that will happen 6-12 months down the road is simply rebuffed. "Oh, developers just want to write stuff all the time, they don't understand business", etc, and other nuggets I've heard over the years - grates me to no end.