Comment by Michelangelo11
7 days ago
> Technical debt, I assert without evidence1, grows exponentially, and therefpre it is very important to minimize it in your projects.
This actually seems like a really important idea absolutely deserving of its own blog post.
I'd have to think about the exact argument for why this feels so right, but the kernel would go something like this: whatever you build on those parts of the codebase where you have technical debt incurs new technical debt, because you're building on top of abstractions you'll remove later. The reason you have to remove the new abstractions, too, is that abstractions are like puzzle pieces: their structure determines which other abstractions they can connect with. So, as a rule (there are some exceptions), you can't take out one bad part, replace it with another, and leave everything around it untouched.
And, of course, it's easier to build on top of something creaky but currently serviceable than it would be to first rip that out and replace it, so that's what you do in most cases ... and the whole codebase gets more creaky and less serviceable; you increase the amount of abstractions you'd have to rip out and replace before building something new. The problem does, indeed, grow exponentially.
The argument is free to a good home -- I don't have the time for a full, meticulous elaboration, but I'd love to read one if someone is interested in making it.
I agree, it is an interesting thing to ponder. I often phrased it to myself that the cost of technical debt compounds the lower in the code stack you go.
Said another way, tech debt has a multiplicative factor the farther away from the end user you get. Tech debt in the database is worse than in the data layer. It is worse in the data layer than in the business logic. It is worse in the business logic than in the UI code. etc.
This is related to the fact that it gets exponentially more difficult to refactor code the farther away you get from the end user. Changing the database is usually more difficult and impacts more things than the data layer code. And on and on we go back up.
Ward Cunningham, who coined technical debt, describes it as having interest, which is exponential:
> Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite.... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.