IMO first one is OK, and the second one is what kills you.
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.
It’s sort of one level “deeper” that the one you use. For me it is helpful because it allows to work with temporality in decisions on tech debt, ie “do we have time to do this right or do we need to get sh*it done now and pay later”. This is valuable because it allows you to work with tradeoffs in architecture and design.
Tradeoffs are inevitable in SW design and sometimes some thing is gonna be more important that not taking on tech debt [right now]. The important thing is to remember that debt has to be payed off.
> 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.
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!
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.
It is still true that mistakes that are made during early phases of the project are much harder to fix than recent mistakes.
I've often heard that the best way to learn about customers is to put a product in front of them and see how they react. People have a hard time knowing what exactly they want in a vacuum, but once you give them something to play with, they're usually good at saying what's good and what's not.
When your system is replacing some existing system, which could well be just paper-based, it is very useful to study it carefully. It will give you a good idea about the data and its internal relations. If you want to show something to a customer, you can also simple mock-ups like static HTML pages.
Only after you have a decent understanding of the system you should start building it. There will be many new requests, but most will just be concerned with the UI. If you have the right data model and architecture, those will not be very difficult to solve.
* Things you haven't built yet
* Things you shouldn't have built that way
IMO first one is OK, and the second one is what kills you.
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.