Three Kinds of Good Tech Debt

Writing hacks and throw-away stopgap solutions is generally a bad idea in reality. The only time when it can actually be allowed is when it it concerns a feature that is a pure leaf in the system with nothing else built on top of it. If you violate this rule and build other features on top of shortcuts, two things will inevitably happen: you will have to replace the shortcut with a proper solution eventually (it is only a matter of time) and by the time this happens, the assumptions underlying the shortcut have implicitly been taken on by the code depending on it. This means that you will have to review and replace a lot of dependent code as well.

I have gone through that dance often enough. It ends up being more time consuming than doing it right in the first place each and every time.

I'm failing to see the point in calling a technical dept "good". As far as I can tell from the article, the author is measuring 2 possibilities of technical dept and choosing the one that incurs the least dept. I can see how good a decision this is but I don't see how this makes the dept good.

I like the framing of tech debt as value-neutral; whether it's good or bad depends on how you use it (just like financial debt). Of course, all else being equal, you'd rather have zero debt.

One higher level consideration that's particularly relevant for early-stage startups, is that you often simply don't have time to build the ideal "tech-debt free" solution. Focusing on 80/20 solutions almost necessarily involves adding tech debt. However, if you're mindful about where you take on tech debt, and commit to tapering and then paying it down as your resources grow, then you're more likely to avoid the debt spiral where your development grinds to a halt, due to everything breaking all the time.

One other point I'd make is that a common form of "tech debt" for early-stage startups is simply doing things that don't scale; it's often beneficial to make your domain models flexible so that you can support one-off manual interactions, for example if a new customer appears that requires it. Then automate that thing and constrain the domain actions once you have collected enough use-cases to know what makes sense to forbid.

> I don't see how this makes the dept good

Time to market, for one. If you get the feature out faster to your customer, eating some debt can be worthwhile. This article is merely providing a structured way to think about the debt you're taking on.

>If the quick hack is well documented, written in a very encapsulated and removable way, who cares about removing it later.

I do. I care very deeply about removing it later.

The problem is that encapsulation is often mistaken as a strong justification for existence, and code that is written tends to justify its existence just by existing.

That's to say that once code is in production, it's scary to delete. It's much less scary to delete a couple of lines of inline code wrapped in a comment that says "this is a hacky solution," because code that isn't encapsulated probably probably isn't used elsewhere. Or if it is, it's copy-pasted.

The scary thing about removing encapsulated / abstracted things, is that oftentimes, other things refer to them, unbeknownst to the original author or their intent.

It's pretty common (especially on larger teams) - the first developer writes up a hacky solution, the second developer abstracts that hack into a module due to some sensibility (abstraction, aesthetics, organization, etc), so now the hack has legitimacy. A third (or often the first developer) sees that the hack is in a module, assumes that the person who put it in a module had more information than when the hack was written and that it's now a first class member of the system. And first class members of a system take thought and time to delete.