4 ms·

I like the metaphor of technical debt, but...this essay does not address the most prevalent obstacle with paying down technical debt, which is that the people m

I like the metaphor of technical debt, but...this essay does not address the most prevalent obstacle with paying down technical debt, which is that the people making the decisions don't care. They are in short-term mode, just trying to get this year's objectives met and IPO or sell or get a higher up job in a different company or division. They really don't care about the long-term health of this software product. Technical debt, as a metaphor, may make perfect sense to them, but they aren't the one who will pay the interest. Now, if you're working on open source and will be in this codebase for a decade, or this is your company or your software, it makes the tradeoffs much clearer, and that works because your incentives are right. So this metaphor works better for helping the typical developer make choices well, than for helping the typical manager/director/CEO make choices well.

foolfoolz 7y ago
this is usually a communication problem from engineering. you have to be able to describe the impact of the risk and benefits and make a business case for it. no one cares if you want to upgrade a framework. but if you are going to improve customer trust by using a newer version of something and result in less bugs / downtime it sounds a lot better
- rossdavidh 7y ago
  Sure. But the risk of disruption is usually actually higher, in the short term, by paying off the technical debt. In the long run, of course, it will likely result in fewer/less risk of technical problems impacting customers. But the risk of there being a disruption right now, is nearly always higher if we pay down technical debt, than if we put it off. So again, you have to have something other than a short-term outlook on the part of the decision maker. Which does happen, of course, but not always, and not almost always either.

foolfoolz 7y ago

this is usually a communication problem from engineering. you have to be able to describe the impact of the risk and benefits and make a business case for it. no one cares if you want to upgrade a framework. but if you are going to improve customer trust by using a newer version of something and result in less bugs / downtime it sounds a lot better

rossdavidh 7y ago
Sure. But the risk of disruption is usually actually higher, in the short term, by paying off the technical debt. In the long run, of course, it will likely result in fewer/less risk of technical problems impacting customers. But the risk of there being a disruption right now, is nearly always higher if we pay down technical debt, than if we put it off. So again, you have to have something other than a short-term outlook on the part of the decision maker. Which does happen, of course, but not always, and not almost always either.