4 ms·

This is well put. I want to expand on one point that seems to be lurking beneath the author's remarks. Technical debt does not necessarily come from technical p

This is well put. I want to expand on one point that seems to be lurking beneath the author's remarks. Technical debt does not necessarily come from technical people. If you're in a startup, there is almost no way that you can end up with a small amount of tech debt because the target that you're aiming at will change. And if you over-optimize for code cleanliness too early, you'll end up shipping code way too slowly. Slow, deliberate code writing is better suited to large, established companies than small, scrappy startups. You cannot escape tech debt; it can only be managed.

dheera 6y ago
In my experience technical debt almost always comes from management's misconception that: (a) A product that works now will always continue to work, even after you accumulate 10X the number of users. (b) Adding new features only involves adding code, not rewriting stuff that already works. (c) For a product A, delivering milestone A1 by deadline A1 is independent of delivering A2 by deadline A2. In reality the existence of A2 affects the timeline and architecture decisions of A1. All of these are rampant massive fallacies in technical management.
- mlyle 6y ago
  Most startups can expect to either A) have a lower cost of capital in the future, or B) to fail. This means opportunity cost is ridiculous, and expedience often can be worth a whole lot of future wasted resources and decreased velocity. Survive to tomorrow, where you have more resources and can pivot to doing things in a cleaner way. So it's not completely stupid to pretend A & B are true. You can pick up velocity now, in exchange for future problems. And as long as the interest payments aren't too high it's well worth it.
  - dheera 6y ago
    Sure, it's a valid way to think for startups, but startups should gauge and plan for the amount of technical debt. It's management being ignorant of technical debt where things become problematic.
- allemagne 6y ago
  Confession: As a developer I've personally fallen for all three of those misconceptions, and I will probably keep falling for them. I'm also pretty bad at actually knowing when I'm running the "technical debt credit card" or even checking what's left in the balance to pay off. Sometimes when I'm trying to pay down the balance, I end up adding a lot more to it. What I understand well enough, I then have a hard time communicating effectively. I'm a pretty bad influence, so when I end up spending a lot of time working with any other developers I eventually catch them doing the same thing. Some more than others. What's worse is that we are the only ones who could possibly know anything about the technical debt that we understand so fuzzily. All that management can hope to get is a secondhand account of all this, so I tend to award mine only partial blame for being pretty consistently terrible at making technical debt decisions.
- BlueTemplar 6y ago
  (c) is why I suspicious of Gantt charts – sub-project separation is never this clean !

dheera 6y ago

In my experience technical debt almost always comes from management's misconception that: (a) A product that works now will always continue to work, even after you accumulate 10X the number of users. (b) Adding new features only involves adding code, not rewriting stuff that already works. (c) For a product A, delivering milestone A1 by deadline A1 is independent of delivering A2 by deadline A2. In reality the existence of A2 affects the timeline and architecture decisions of A1. All of these are rampant massive fallacies in technical management.

mlyle 6y ago
Most startups can expect to either A) have a lower cost of capital in the future, or B) to fail. This means opportunity cost is ridiculous, and expedience often can be worth a whole lot of future wasted resources and decreased velocity. Survive to tomorrow, where you have more resources and can pivot to doing things in a cleaner way. So it's not completely stupid to pretend A & B are true. You can pick up velocity now, in exchange for future problems. And as long as the interest payments aren't too high it's well worth it.
- dheera 6y ago
  Sure, it's a valid way to think for startups, but startups should gauge and plan for the amount of technical debt. It's management being ignorant of technical debt where things become problematic.
allemagne 6y ago
Confession: As a developer I've personally fallen for all three of those misconceptions, and I will probably keep falling for them. I'm also pretty bad at actually knowing when I'm running the "technical debt credit card" or even checking what's left in the balance to pay off. Sometimes when I'm trying to pay down the balance, I end up adding a lot more to it. What I understand well enough, I then have a hard time communicating effectively. I'm a pretty bad influence, so when I end up spending a lot of time working with any other developers I eventually catch them doing the same thing. Some more than others. What's worse is that we are the only ones who could possibly know anything about the technical debt that we understand so fuzzily. All that management can hope to get is a secondhand account of all this, so I tend to award mine only partial blame for being pretty consistently terrible at making technical debt decisions.
BlueTemplar 6y ago
(c) is why I suspicious of Gantt charts – sub-project separation is never this clean !