Ehh. There are two kinds of tech debt:<p>* Things you haven't built yet<p>* Things you shouldn't have built that way<p>IMO first one is OK, and the second one is what kills you.<p>OP is absolutely correct to point out you can find tech debt in code, architecture and data, but... That doesn't really help to make general decisions about it, both in handling it once you have it, and in making decisions about accumulating it.
> tech debt is not always bad. Using MongoDB to prototype ideas or writing an ugly function that does abusive things to solve a critical bug can be justified, and the optimal way to do things. It’s just a matter of doing so deliberately.<p>I've seen this put slightly differently before: technical debt is like financial debt. Drowning in it is obviously bad, but it has its place, and it's typically unwise to aim to never take on debt.
I found this list really useful and will be sharing with my team. Thank you author and OP!<p>In my mind I’ve always categorized tech debt as being broader, and including pretty much anything that doesn’t have a direct benefit to our end users. So this can include things like moving our repos from Bitbucket to GitHub, updating a dependency that has a breaking change (e.g. migrating from one version of Bootstrap to another) or even something more significant like changing from a legacy authentication model to something more modern like OIDC. But I wonder if with this mental model I’ve taken it too far.
One of the big problems with "modern development projects" is that they start coding from day 1. The first step in any good project should be to learn as much as possible about the requirements before making serious decision about its architecture. Designing a model of the data (even if it is only a very rough one) is usually very helpful in the first phase of a project.<p>It is still true that mistakes that are made during early phases of the project are much harder to fix than recent mistakes.