4 ms·

The problem with this analogy is you don't necessarily take on technical debt when you make your technical decisions. Technical decisions only become debt when

The problem with this analogy is you don't necessarily take on technical debt when you make your technical decisions. Technical decisions only become debt when you have to revisit those decisions. You don't pay interest on debt over time. You pay interest whenever you build upon or modify the flawed code. You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt. In comparison, if you write just slightly flawed design, but build out your complete featureset based upon that flawed design, you could have mountains of technical debt. I think a better analogy is building a structure. If your code is foundational, you better get that shit right. If you cheap out on a $20 part and have to replace it, but it's just a door knob, that's not too bad. But if it's under your slab on grade foundation you're going to pay thousands to dig it up and fix a $20 part.

cle 7y ago
This is exactly what the article says: > Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term. If you aren't going to be changing the code later, then writing a bunch of spaghetti code won't make it harder to work with in the long term.
- engManager 7y ago
  How can one accurately predict that the code won't be changing in the future? If you needed to get something done once, isn't there a good chance that in the future someone else, including your future self, may need to rely on or modify it?
  - cle 7y ago
    It’s contextual. E.g. if you’re in a situation very similar to past situations where you threw the code away afterwards, you can be pretty confident that you’ll throw it away this time too.
wpietri 7y ago
The only code you never have to touch again is code nobody is using. In which case, it's like a corporation declaring bankruptcy: the debt becomes moot. Otherwise, you always have to deal with it eventually. Look at the Y2K problem. or how the 2038 problem is starting to crop up already, exposing significant levels of technical debt. https://twitter.com/jxxf/status/1219009308438024200 https://twitter.com/jxxf/status/1219009308438024200 I also think technical debt does accrue interest over time, albeit not as linearly as a modern installment-plan debt does. That's because it slowly falls out of sync with people's memories. With libraries, with operating systems, with techniques. Bad code I wrote 10 minutes ago is pretty easy to clean up. But the next day, the next month, the next year? The cleanup gets more expensive. At some point the work becomes more archaeology than normal programming. It's also true that actual foundations have something in common with foundational code. But that's a different aspect of programming than what tech debt is pointing at.
- xwowsersx 7y ago
  This is pretty amazing. From Wikipedia: > Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.
- jmchuster 7y ago
  > The only code you never have to touch again is code nobody is using. There are plenty of counter-examples, but I like the example of video games. https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-code-game-development-terry-cavanagh-release https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-cod... There's a pretty clear ship date, after which you never touch it again. Even in the world of SAAS, there are plenty of services or libraries that you write that serve a single purpose, are good enough, and never get touched again.
  - wpietri 7y ago
    Well, some video games, those based on a historical model of actually shipping physical games. But successful video games these days can literally run for decades, either directly (as Warcraft) or as a series (like Madden NFL). Plenty of things that are intended to be one-and-dones also evolve, like Stardew Valley's audience demanding multiplayer. Even the code you mention isn't a great example for your case. In theory it was throwaway, but now that it's out there, you can bet that plenty of people will be touching it. And you're also ignoring the path not taken. This beloved game didn't get a sequel, despite plenty of demand. If the code were in better shape, might it have had one?
Tyr42 7y ago
I really like this model of technical debt. https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxonomy-tech-debt It breaks it down along three axis: * Impact. How much it affects things. * Fix cost. How hard is it to fix. * Contagion. How much it spreads over time. If a piece of tech debt is well-contained, the cost to fix it later compared to now is basically identical. On the other hand, some forms of tech debt keep giving. Image if your string type has some issues. Linking that back to the debt analogy, there are different interest rates for different kinds of debt, depending on how contagious that part of the code is.
theptip 7y ago
> You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt. I don't really agree with this view; it may seem pedantic, but I think it's better to consider that case as tech debt. In my experience, it's incredibly uncommon to write code and never touch it again -- particularly if you elect to cut corners in the interest of getting something out the door quicker. That code inevitably either gets retired because it's not being used (your debt was forgiven), or gets built on top of (your debt starts to compound). If you make a decision to lower the quality bar because "we are not going to touch this again, so it's not tech debt, so it doesn't matter", then I think you're fooling yourself. Instead, I think it's better to assume that you're taking on tech debt (you almost certainly are), apply all the best practices around managing that debt (i.e. catalog it, be aware of your overall debt level, and be aware of tech debt in critical systems), and be happy if your debt is later forgiven if you miraculously never need to touch that code again. Maybe there's a narrow sense in which this position is technically/semantically correct, but I think more often than not, this position is going to hurt you more than it helps.

cle 7y ago

This is exactly what the article says: > Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term. If you aren't going to be changing the code later, then writing a bunch of spaghetti code won't make it harder to work with in the long term.

engManager 7y ago
How can one accurately predict that the code won't be changing in the future? If you needed to get something done once, isn't there a good chance that in the future someone else, including your future self, may need to rely on or modify it?
- cle 7y ago
  It’s contextual. E.g. if you’re in a situation very similar to past situations where you threw the code away afterwards, you can be pretty confident that you’ll throw it away this time too.

wpietri 7y ago

The only code you never have to touch again is code nobody is using. In which case, it's like a corporation declaring bankruptcy: the debt becomes moot. Otherwise, you always have to deal with it eventually. Look at the Y2K problem. or how the 2038 problem is starting to crop up already, exposing significant levels of technical debt. https://twitter.com/jxxf/status/1219009308438024200 https://twitter.com/jxxf/status/1219009308438024200 I also think technical debt does accrue interest over time, albeit not as linearly as a modern installment-plan debt does. That's because it slowly falls out of sync with people's memories. With libraries, with operating systems, with techniques. Bad code I wrote 10 minutes ago is pretty easy to clean up. But the next day, the next month, the next year? The cleanup gets more expensive. At some point the work becomes more archaeology than normal programming. It's also true that actual foundations have something in common with foundational code. But that's a different aspect of programming than what tech debt is pointing at.

xwowsersx 7y ago
This is pretty amazing. From Wikipedia: > Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.
jmchuster 7y ago
> The only code you never have to touch again is code nobody is using. There are plenty of counter-examples, but I like the example of video games. https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-code-game-development-terry-cavanagh-release https://www.polygon.com/2020/1/13/21064100/vvvvvv-source-cod... There's a pretty clear ship date, after which you never touch it again. Even in the world of SAAS, there are plenty of services or libraries that you write that serve a single purpose, are good enough, and never get touched again.
- wpietri 7y ago
  Well, some video games, those based on a historical model of actually shipping physical games. But successful video games these days can literally run for decades, either directly (as Warcraft) or as a series (like Madden NFL). Plenty of things that are intended to be one-and-dones also evolve, like Stardew Valley's audience demanding multiplayer. Even the code you mention isn't a great example for your case. In theory it was throwaway, but now that it's out there, you can bet that plenty of people will be touching it. And you're also ignoring the path not taken. This beloved game didn't get a sequel, despite plenty of demand. If the code were in better shape, might it have had one?

Tyr42 7y ago

I really like this model of technical debt. https://technology.riotgames.com/news/taxonomy-tech-debt https://technology.riotgames.com/news/taxonomy-tech-debt It breaks it down along three axis: * Impact. How much it affects things. * Fix cost. How hard is it to fix. * Contagion. How much it spreads over time. If a piece of tech debt is well-contained, the cost to fix it later compared to now is basically identical. On the other hand, some forms of tech debt keep giving. Image if your string type has some issues. Linking that back to the debt analogy, there are different interest rates for different kinds of debt, depending on how contagious that part of the code is.

theptip 7y ago

> You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt. I don't really agree with this view; it may seem pedantic, but I think it's better to consider that case as tech debt. In my experience, it's incredibly uncommon to write code and never touch it again -- particularly if you elect to cut corners in the interest of getting something out the door quicker. That code inevitably either gets retired because it's not being used (your debt was forgiven), or gets built on top of (your debt starts to compound). If you make a decision to lower the quality bar because "we are not going to touch this again, so it's not tech debt, so it doesn't matter", then I think you're fooling yourself. Instead, I think it's better to assume that you're taking on tech debt (you almost certainly are), apply all the best practices around managing that debt (i.e. catalog it, be aware of your overall debt level, and be aware of tech debt in critical systems), and be happy if your debt is later forgiven if you miraculously never need to touch that code again. Maybe there's a narrow sense in which this position is technically/semantically correct, but I think more often than not, this position is going to hurt you more than it helps.