Three Kinds of Good Tech Debt

To me, technical debt is associated with a sense of regret. The example in the quote above doesn't have that, perhaps that is what makes it the good kind.

We do say Congratulations! - we say well done on finishing the project you were working on.

I do agree with the part on not putting too much worth on edge cases, however the biggest issue for me with Technical Debt is the increased time it often leads to in further development. So I wouldn't say it's something to completely ignore.

There's also a distinction between "we made intentional decisions that we need to fix up now" and "We (or people before us) made unintentional decisions and it is in such a bad state that it endangers the health of the business."

The very concept of Tech Debt, though prevalent, is pernicious, because its a concept that is far, far, far too fuzzy and therefore can -- and is -- always applied as a convenient narrative to explain away mistakes, process deficiencies, bugs, etc rather than a true conceptual problem-solving tool that aids in optimizing the software development process. In short, "Tech Debt" is a euphemism for incompetence.

We can see this play out in this post, which covers "3 kinds of good tech debt.

1) "Scaffolding" ... what the author describes here is good ol' fashion Prototyping, aka Learning. No invocation of a fuzzy concept like "Tech Debt" is needed here. You don't know something, so you go and learn what you need to learn. Learning takes many forms. In this case, it is product understanding -- and this author reaches for prototyping in particular and calls it Scaffolding. Why a new term? Why obfuscate, why fuzzify? Because that's what Tech Debt is good for: fuzzy thinking. If we move to more clarity we can be specific and we can take specific actions to optimize: here, maybe or maybe not prototyping isn't the most efficient way to learn what is needed: often, wireframes shown to customers will suffice. There are plenty of ways to skin this once the framing is clear.

2) "Hardcoding" Again, no fuzziness is needed here. Developers have a fetish for fully flexible and feature-rich subsystems and we tend to call anything else a pejorative like "hard-coding" but that's a psychological problem in us, not a technical or process problem. We already have a clear framework for talking about this and it's called feature Scoping. There are, again, plenty of ways to skin this cat, but the short of it is - if you can understand what features you are interested in with clarity then you can build a system whose flexibility is in accordance. This isn't a fuzzy "Tech Debt" thing. If you only need feature X now and going forward, then build that - and call it something pejorative like "hard coding" if you want: I call it being rational. But bringing in a fuzzy term like "Tech Debt" helps nothing here. Only confuses.

3) "Not Fixing Edge Cases" This one is the worst of all. By using a fuzzy term like "Tech Debt" we're able to completely alleviate our responsibility. And start down a path of extreme cost and pain. Here, he wants to avoid having to implement correctness because it would cost too much. The example is a good one: it reflects a pattern I've seen over and over again. And unfortunately I've seen the same choice this author makes -- and the terrible downstream cost it creates, as well. By avoiding implementing a correct solution (by purposefully shipping a race condition) he is not being clever, he is being irresponsible. If this sounds draconian, let me explain further. Perhaps he finds, as he mentions, that in production this is inconsequential. Okay, great. But first thing to point out is that most likely it will become an issue as the system grows and when are you going to notice that? Are you going to go build monitoring to make sure that this "effective correctness" holds over time? Of course not, that's more work. But even if you are happy with his choice here, there's a bigger issue. He has chosen to build a system with transactional needs on top of an eventually consistent/NoSQL solution. From my experience, it's rare that you have just one feature like his that needs transactional correctness and that is it. Tomorrow, next week, soon--he and his team are going to find out that they need another transactional capability and then they are going to be right back where they started: having to ask a question, do I slack off here, as well? Again -- we've created cost for ourselves by forcing us to ask, should I ship a bug in this case? One might say this is what "Tech Debt" lets you do! It lets kick the can down the road, save you some time now... But I do not buy it. I've seen this exact kind of choice made plenty of times and the can always comes back next week, next month and the tax you pay for not getting right is immense. "Tech Debt" here is simply letting us avoid responsibility, avoid having to understand the needs of our overall system. The cost of getting transactions right/correct is not even that high if you face it squarely and truly make sure you need NoSQL and in which cases. What's happening here is not clever process optimization but inexperience. And if not inexperience, laziness (not the good kind).

The concept of "Tech Debt" is awful. And always ends up being a euphemistic excuse. I've never seen the idea of "Tech Debt" help the actual process and technical quality of things. I've only ever seen it give developers an excuse for inexperience, laziness, etc. I don't mean to denigrate here -- I mean to challenge and ask for us to be more intentional, clear, and frank in our work. "Tech Debut" is fuzzy thinking and fuzzy thinking isn't much good for anything other than excuses.