10 ms·

Technical Debt is a broken metaphor. It's almost right, which is why it resonates, but it's a bad mental model for the problem it tries to describe. There are

Technical Debt is a broken metaphor. It's almost right, which is why it resonates, but it's a bad mental model for the problem it tries to describe. There are real negative consequence of applying a "broken mental model" -- you end up doing the wrong thing when you live by the model! Why is technical debt a broken concept? Real Debt is incurred proportionally to the asset bought with it. In technical debt the debt is proportional to the trouble it causes, not the value delivered. Also, it implies that the only way to get rid of the debt is to make a big investment. In reality, you can just throw away code and the debt disappears. Not analogous with real debt! It should've been called technical drag. Properties of drag that are appropriate to the metaphor: - You get value based on the amount of input work, but it places a drag on the overall progress towards the goal (support load, architectural coupling). - You can reduce the drag of an existing component by investing to refine it. - New components typically add more drag than existing ones. - Little bits of drag here and there add up to a big problem - Removing unused functionality reduces associated drag without major investment Thoughts?

swombat 17y ago
Agree. In fact, I called it "viscosity" in an article a long time ago, and posited that the rate of increase of viscosity depends on languages, practices, etc: http://inter-sections.net/2007/12/01/comparing-pieces-of-string-part-1 http://inter-sections.net/2007/12/01/comparing-pieces-of-str... "Technical drag" is a very good term for it, I agree.
- apinstein 17y ago
  Interesting article. I think using viscosity to compare languages or frameworks is counterproductive, but the general idea is useful when talking about software architecture and development. For instance, I used to manage some poorly architected Java apps where even trivial changes incurred painful re-architecting because the app was poorly written. And I've managed PHP apps that are extremely well-organized and are very simple to add functionality to. The other thing I'd mention is I like your idea about hitting the wall where improvement freezes b/c the implementation time is so great. I think it's a good fit for the technical drag model -- that is the point of terminal velocity! It's another good-fit for the metaphor; eventually you can only drive forward a product by making the team bigger because your project hits its terminal velocity (or top speed) for the given "engine" size (the team).
  - swombat 17y ago
    One problem with that concept of adding developers as increasing the size of the engine - I don't think it works like that. When development freezes, good developers end up losing interest eventually, so in reality what probably happens is that your productivity decreases - so in fact you probably start regressing, if you let yourself hit that point.
    - apinstein 17y ago
      Agreed. I didn't say adding developers proportionally affects output, and this is true with engines as well. A particular engine architecture scales proportionally up to a point, but then gets harder to get a little bit bigger. Same is true with dev teams...
tome 17y ago
In reality, you can just throw away code and the debt disappears. Technical debt is closer to this than you might think. This would be "going bankrupt" on that code. It's like having a loan secured on the value of some object. If you want to default on the loan, you lose the object, nothing more. (Although you don't lose your good credit rating as you would with real debt!)
- apinstein 17y ago
  Um, what? No! This is exactly the type of logic-wrangling that happens with bad mental models. It is not going bankrupt on that code, When you go bankrupt, there is a huge penalty to your credit! If you stop maintaining code that no one uses, the drag goes away and there is no downside! Deleting code is fun. Going bankrupt, not so much.
  - nostrademons 17y ago
    When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users. This is why I like the "technical debt" metaphor more than the "technical drag" metaphor. Technical debt acknowledges that there's an outside user who's presumably paying you for the project. You can choose to satisfy them better now, but it's at the cost of satisfying them less later, or even regressing and making things more painful for them as you take away debt-ridden features. Just as how financial debt lets you invest now and satisfy the immediate customer better at the price of paying it off later. "Technical drag" implies that forward motion is inexorable, and the only variable is the rate. This is not a given in software; I often try to use old versions because I know that new ones will be slower, more cluttered, and buggier.
    - swombat 17y ago
      When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users. Did you read the article? Eric Ries gave a good example of a piece of code that they had built, with technical debt, and which they threw away because it had little or no customer value. In practice, I see it happen all the time. There's functionality in most applications that could probably be removed with little impact to user experience. Even on Woobius there are some chunks of functionality that are not much used at the moment and that we could remove without much impact on the users.
dusklight 17y ago
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.

swombat 17y ago

Agree. In fact, I called it "viscosity" in an article a long time ago, and posited that the rate of increase of viscosity depends on languages, practices, etc: http://inter-sections.net/2007/12/01/comparing-pieces-of-string-part-1 http://inter-sections.net/2007/12/01/comparing-pieces-of-str... "Technical drag" is a very good term for it, I agree.

apinstein 17y ago
Interesting article. I think using viscosity to compare languages or frameworks is counterproductive, but the general idea is useful when talking about software architecture and development. For instance, I used to manage some poorly architected Java apps where even trivial changes incurred painful re-architecting because the app was poorly written. And I've managed PHP apps that are extremely well-organized and are very simple to add functionality to. The other thing I'd mention is I like your idea about hitting the wall where improvement freezes b/c the implementation time is so great. I think it's a good fit for the technical drag model -- that is the point of terminal velocity! It's another good-fit for the metaphor; eventually you can only drive forward a product by making the team bigger because your project hits its terminal velocity (or top speed) for the given "engine" size (the team).
- swombat 17y ago
  One problem with that concept of adding developers as increasing the size of the engine - I don't think it works like that. When development freezes, good developers end up losing interest eventually, so in reality what probably happens is that your productivity decreases - so in fact you probably start regressing, if you let yourself hit that point.
  - apinstein 17y ago
    Agreed. I didn't say adding developers proportionally affects output, and this is true with engines as well. A particular engine architecture scales proportionally up to a point, but then gets harder to get a little bit bigger. Same is true with dev teams...

tome 17y ago

In reality, you can just throw away code and the debt disappears. Technical debt is closer to this than you might think. This would be "going bankrupt" on that code. It's like having a loan secured on the value of some object. If you want to default on the loan, you lose the object, nothing more. (Although you don't lose your good credit rating as you would with real debt!)

apinstein 17y ago
Um, what? No! This is exactly the type of logic-wrangling that happens with bad mental models. It is not going bankrupt on that code, When you go bankrupt, there is a huge penalty to your credit! If you stop maintaining code that no one uses, the drag goes away and there is no downside! Deleting code is fun. Going bankrupt, not so much.
- nostrademons 17y ago
  When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users. This is why I like the "technical debt" metaphor more than the "technical drag" metaphor. Technical debt acknowledges that there's an outside user who's presumably paying you for the project. You can choose to satisfy them better now, but it's at the cost of satisfying them less later, or even regressing and making things more painful for them as you take away debt-ridden features. Just as how financial debt lets you invest now and satisfy the immediate customer better at the price of paying it off later. "Technical drag" implies that forward motion is inexorable, and the only variable is the rate. This is not a given in software; I often try to use old versions because I know that new ones will be slower, more cluttered, and buggier.
  - swombat 17y ago
    When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users. Did you read the article? Eric Ries gave a good example of a piece of code that they had built, with technical debt, and which they threw away because it had little or no customer value. In practice, I see it happen all the time. There's functionality in most applications that could probably be removed with little impact to user experience. Even on Woobius there are some chunks of functionality that are not much used at the moment and that we could remove without much impact on the users.

dusklight 17y ago

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.