My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.

Agree, and in theory duplication is easy to refactor and clean up, but the nasty thing about duplication is that the instances can diverge in little ways, and then the person cleaning it up may not be able to tell if the differences are meaningful and need to be preserved, or accidents of maintenance.

My current job is cleaning up both kinds of tech debt for a startup. Duplication has created several bugs, but most of them were fixable in a few hours at most, and we finished cleaning them all up within 4 months. Bad abstraction has taken hours to months to clear up and we're still not done.

The difficulty in our current culture with abstraction mostly derives from taking "don't repeat yourself" too far and using that to mean "apply any compression strategy you can find to this code" which could range from enterprise generalization and configuration to APL-style code-golfing.

A gentler, more helpful admonition would be "find the theme, reuse the theme". If you only set out to compress the code you obscure the theme of the code, but if you set out to elevate the theme as you find it, you are likely to let more code rest in a form that is duplicated but a reasonable reflection of the themes currently present.

Was going to say the same... I've been in projects where the abstractions made what should be a trivial 30-60min change, with tests, blows up to almost a week just because all of the layers that need to be worked through.

To GP: schema debt is usually from adding stuff before you need it... it's almost always pre-mature and one should have a good migration strategy in place early on in order to support destructive (or at least not-simple) restructuring over time.

Even better if those could be demonstrated by studies/concrete data instead of "I think/feel..."