5 ms·

I prefer the debt metaphor versus drag for two major reasons. First when you talk about real physical drag, the amount of drag per object is not a value assigne

I prefer the debt metaphor versus drag for two major reasons. First when you talk about real physical drag, the amount of drag per object is not a value assigned by a human person. You don't choose how much drag an object has. You can change the shape of the object to modify the drag coefficient but you cannot modify it independently. Whereas with debt, it is understood that this value is something that is your choice. Secondly, with debt comes the concept of interest, which is the most salient point. The big problem with technical debt is that you can have a small amount and there are essentially no downsides, but the longer you avoid paying for it, the harder it is to avoid creating new technical debt when you write new code, the more technical debt you will incur, and the negative effects start to compound.

apinstein 17y ago
You can't independently choose your "debt" level with software! When you design feature X, it costs you interest in terms of support, refactoring, debugging, etc. If you think you can decide exactly how much that's going to cost you a priori then you should go buy some lottery tickets. Drag is a better metaphor in this case because you can have an idea from looking at the design approximately how painful it will be to support it, but you can't be quite sure until you test it in the real world (ie wind tunnel test for example). You can model/simulate it based on expectations of feature popularity etc, but you won't know for sure. On your second point, I do agree that there is a strong salient aspect of the idea of interest payments on debt. Like I said originally, the metaphor stuck because it resonates. However, the idea of technical drag has this same exact concept; the more junk you bolt on to the car, the more it overwhelms your project, and your initial F1 racer becomes a UPS truck. One could make a point about technical debt that technical drag doesn't have, and I'll yield it's important, is that it's pretty tough to have so much drag you can't move. Whereas debt service can flat-out sink you. However I'd counter that if you aren't moving (ie have customers using your software) then technical debt isn't really a problem because you don't have to do much work to service software with no users. Whereas technical debt implies that you have to pay for the feature even if it isn't being used.

apinstein 17y ago

You can't independently choose your "debt" level with software! When you design feature X, it costs you interest in terms of support, refactoring, debugging, etc. If you think you can decide exactly how much that's going to cost you a priori then you should go buy some lottery tickets. Drag is a better metaphor in this case because you can have an idea from looking at the design approximately how painful it will be to support it, but you can't be quite sure until you test it in the real world (ie wind tunnel test for example). You can model/simulate it based on expectations of feature popularity etc, but you won't know for sure. On your second point, I do agree that there is a strong salient aspect of the idea of interest payments on debt. Like I said originally, the metaphor stuck because it resonates. However, the idea of technical drag has this same exact concept; the more junk you bolt on to the car, the more it overwhelms your project, and your initial F1 racer becomes a UPS truck. One could make a point about technical debt that technical drag doesn't have, and I'll yield it's important, is that it's pretty tough to have so much drag you can't move. Whereas debt service can flat-out sink you. However I'd counter that if you aren't moving (ie have customers using your software) then technical debt isn't really a problem because you don't have to do much work to service software with no users. Whereas technical debt implies that you have to pay for the feature even if it isn't being used.