[gmadsen]

not all "technical debt" is wanting chess when we built checkers.

it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess.

the vast majority of software projects will have features/requirements that evolve after the initial design, it is a rabbit hole to try and guess all of those, but some things are just common sense but would add a little time to the first milestone. then you are in the position of tacking on things indefinitely making it a horrible tangled mess.

[geocar]

> it can just be building a minimal chess quickly using methods/frameworks that are not easily extensible to future requirements related to chess.

You should not build something you do not need if you know it is wrong and you will not need it.

That is just wrong.

Many engineering managers do this to “show progress” but this is because they are bad at their job.

On the other hand, if you need it so the UI team has a mock to work against (so that they can explore what interfaces they really need), it isn’t debt at all.

[mook]

Technical debt doesn't even need to be related to future requirements. It could be building something that's only mostly right to get something out faster.