[samhw]

I'd agree with this, but this is orthogonal to tech debt IMO. Tech debt is a trade-off of a simpler / less extensible implementation in exchange for faster product / business validation of experimental (in some sense) code. It doesn't matter how fast the individual developer is: all that matters is that, where T is some arbitrary unit of execution speed, the simple solution takes e.g. 1T and the more future-proofed solution takes 2T or 3T.

Like I said here -> https://news.ycombinator.com/item?id=30286860, I think this whole thread is proving slightly unproductive because everyone has their own definition, and concrete example, of tech debt in mind - and so we're all talking at cross purposes about different things.

I suspect that lots of the stuff people seem to implicitly be talking about is not tech debt by my definition, but rather just shoddy code. That seems to be what your comment is talking about. If you can write a better implementation in the same time (subtracting time taken to learn about either implementation technique) then it's not tech debt AFAICS.

[samhw]

^ I thought I should clarify: the reason I'm making the point about relative deltas in speed is that many people ITT seem to think they can leapfrog the tricky question of tech debt by just saying "well, we should all be better engineers, and then we'd write the better-of-the-two implementation more quickly".

And that's just not so. It doesn't matter how fast or quick-minded the engineer is in absolute terms. I've worked with some of the best engineers in the world, and they still took on tech debt (albeit in an intelligent and considered way), because simpler solutions are still faster in relative terms.

Tech debt will forever be a rational choice so long as there's a comparative advantage - so to speak - in taking the simpler path.