4 ms·

The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. With software you can avoid the "pay it back" pa

by hooby 5y ago

The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. With software you can avoid the "pay it back" part - simply by retiring the software entirely. But you cannot avoid the interest - as long as you keep maintaining and supporting the software, the debt present within, will cause extra work and extra pain. That recurring interest can accumulate to the point, where it's more expensive to pay the interest, than it would be to just throw everything away and start from scratch. But you can't retire the old code before the new code is ready to replace it - and you don't have the capacity to write the new code while all your effort goes into maintaining the old code. Your existing developers increasingly burn out on maintaining the old code, some might even quit, and you are unable to hire new developers, since they'd rather sign up for another company that isn't that deep into legacy problems. This is the dead end you want to avoid - and the best way to avoid it, is to get rid of any technical debt as soon as possible. It's okay to make the strategic decision to take shortcuts in order to meet a deadline or keep a customer - but letting the resulting debt accumulate is not sustainable in the long run.

repomies69 5y ago
> The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. Bullshit. Typical startup fails. So, typically all the investments to reduce future technical debt is waste. Engineering teams make often a huge issue about technical debt, sometimes in companies where it looks pretty clear that there is no much use in removing that technical debt since future investments in the company/technology seem unlikely. I guess in these situations the problem is that the leadership is not really eager to communicate the real situation to the devs.
- oaiey 5y ago
  But not everything is a startup. Quite the opposite actually. I agree with your second point, finished products/companies are finished. No reason to pay debt there if the pure maintenance (if any) is not impacted. But as with the other topic: That is often not the case.
- parksy 5y ago
  I mean a lot of what you said applies but that doesn't make the entire concept BS. On the one side of the coin you're right, it doesn't matter for a huge percentage of startups - until it does, and then it can matter quite a lot, very quickly. Yes most startups fail so technical debt isn't a primary concern. But on the flipside if a startup becomes successful they'll have the budget and experience to clean up technical debt. Only at that point it's like repairing a car while the engine is running - when you're scaling fast, suddenly you have millions of new users flooding in, you can't take your systems offline and rebuild them on the fly - users demanding new features and improvements takes priority over fixing invisible stuff they can't see, etc. I'm sure you understand this. I can think of a few companies who were big players in our local / national sphere who hit it off, got splashed all over as the next big thing, and their systems totally failed during their big events, or were seen as industry leaders only for a breach to sink them overnight. I see part of the problem is technical debt often only gets raised retrospectively, when it would take huge efforts and expense to deal with. It doesn't take an insane order of magnitude of time to move a little slower and make more calculated decisions to build something with scalability and longevity in mind. A sensible balance should be struck between velocity and engineering. Technical debt should be raised early in the process and used proactively in decision making. I suppose it doesn't matter if you're an investor or owner just trying to get ahead of the market and sell it off for profit, you can flip Gartner-as-a-Service products all year long and still come out ahead even if a good portion of them fall over their own feet at some point in the future.
- infinitezest 5y ago
  I would argue that this is just one way that you can pay down your debt :P
Juliate 5y ago
There is always a way out of debt, in software as well as in real life. It's called a clearance. Or a jubilee, in public matters. Just to say that "debt" is not a physical, inescapable fact, it _can_ be cleared, fully, or partially (interest-wise for instance). The concept of "debt" is not much clarifying/simplifying the concept, and "interest" here has no significant/similar meaning as in financial matters. The analogy stops quick enough. Legacy is in itself a slightly better analogy, as it conceals away that it is good or bad in itself.
chrisjc 5y ago
Not to dwell on your analogy too much, but... you may have to pay back debt eventually, and there will be accruing interest if not paid down, but debt does have its positives and advantages. If the system that the debt is part of as a whole is increasing in value, then hopefully the relative amount of debt and its associated interest diminishes over time. I'd say the real question is will the shortcut that leads to technical debt going to yield greater returns than the cost of the debt. And if so, over what time-frame? On the flip-side, will rejecting shortcuts and avoiding some technical debt result in getting to market later resulting in less income and losing a competitive advantage? Were these penalties far greater than cost of the shortcut? Relapsing back to the good ol' car analogy, it might be far more prudent to take on a car loan than buy the car outright. If the interest rate is low enough that it's below inflation, it's less than what your transportation costs would be without this vehicle and/or it's less than what you could be earning as interest on the money you would have put down to buy outright, then there is no harm in taking on that debt. In fact you might say a decision not to take on debt in any of these cases would be foolish. I guess the moral of the story is that not all debt is bad or equal.
user3939382 5y ago
I’ve found my problem to be the opposite. You can spend too much time making everything technically perfect and nothing ever gets done. It’s much better to have a working product, customers, investors, etc with some code that isn’t perfectly DRY for example, than academically perfect code for a product that’s 20% functional and no one will ever know exists. In the real world we have limited resources when starting things and you sometimes have to pick between those options. If you have something new and very limited resources, get something going and refactor it later.
- hooby 5y ago
  I'm not talking about making everything technically perfect. I'm talking about removing things which cause extra work, are more error-prone, do not scale, and/or demotivate the team.
- smcin 5y ago
  "Technical Perfectionism", The other extreme on the spectrum.

by hooby 5y ago

repomies69 5y ago

> The thing with debt is, that you have to pay it back eventually - and you have to pay interest on top of that. Bullshit. Typical startup fails. So, typically all the investments to reduce future technical debt is waste. Engineering teams make often a huge issue about technical debt, sometimes in companies where it looks pretty clear that there is no much use in removing that technical debt since future investments in the company/technology seem unlikely. I guess in these situations the problem is that the leadership is not really eager to communicate the real situation to the devs.

oaiey 5y ago
But not everything is a startup. Quite the opposite actually. I agree with your second point, finished products/companies are finished. No reason to pay debt there if the pure maintenance (if any) is not impacted. But as with the other topic: That is often not the case.
parksy 5y ago
I mean a lot of what you said applies but that doesn't make the entire concept BS. On the one side of the coin you're right, it doesn't matter for a huge percentage of startups - until it does, and then it can matter quite a lot, very quickly. Yes most startups fail so technical debt isn't a primary concern. But on the flipside if a startup becomes successful they'll have the budget and experience to clean up technical debt. Only at that point it's like repairing a car while the engine is running - when you're scaling fast, suddenly you have millions of new users flooding in, you can't take your systems offline and rebuild them on the fly - users demanding new features and improvements takes priority over fixing invisible stuff they can't see, etc. I'm sure you understand this. I can think of a few companies who were big players in our local / national sphere who hit it off, got splashed all over as the next big thing, and their systems totally failed during their big events, or were seen as industry leaders only for a breach to sink them overnight. I see part of the problem is technical debt often only gets raised retrospectively, when it would take huge efforts and expense to deal with. It doesn't take an insane order of magnitude of time to move a little slower and make more calculated decisions to build something with scalability and longevity in mind. A sensible balance should be struck between velocity and engineering. Technical debt should be raised early in the process and used proactively in decision making. I suppose it doesn't matter if you're an investor or owner just trying to get ahead of the market and sell it off for profit, you can flip Gartner-as-a-Service products all year long and still come out ahead even if a good portion of them fall over their own feet at some point in the future.
infinitezest 5y ago
I would argue that this is just one way that you can pay down your debt :P

Juliate 5y ago

There is always a way out of debt, in software as well as in real life. It's called a clearance. Or a jubilee, in public matters. Just to say that "debt" is not a physical, inescapable fact, it _can_ be cleared, fully, or partially (interest-wise for instance). The concept of "debt" is not much clarifying/simplifying the concept, and "interest" here has no significant/similar meaning as in financial matters. The analogy stops quick enough. Legacy is in itself a slightly better analogy, as it conceals away that it is good or bad in itself.

chrisjc 5y ago

Not to dwell on your analogy too much, but... you may have to pay back debt eventually, and there will be accruing interest if not paid down, but debt does have its positives and advantages. If the system that the debt is part of as a whole is increasing in value, then hopefully the relative amount of debt and its associated interest diminishes over time. I'd say the real question is will the shortcut that leads to technical debt going to yield greater returns than the cost of the debt. And if so, over what time-frame? On the flip-side, will rejecting shortcuts and avoiding some technical debt result in getting to market later resulting in less income and losing a competitive advantage? Were these penalties far greater than cost of the shortcut? Relapsing back to the good ol' car analogy, it might be far more prudent to take on a car loan than buy the car outright. If the interest rate is low enough that it's below inflation, it's less than what your transportation costs would be without this vehicle and/or it's less than what you could be earning as interest on the money you would have put down to buy outright, then there is no harm in taking on that debt. In fact you might say a decision not to take on debt in any of these cases would be foolish. I guess the moral of the story is that not all debt is bad or equal.

user3939382 5y ago

I’ve found my problem to be the opposite. You can spend too much time making everything technically perfect and nothing ever gets done. It’s much better to have a working product, customers, investors, etc with some code that isn’t perfectly DRY for example, than academically perfect code for a product that’s 20% functional and no one will ever know exists. In the real world we have limited resources when starting things and you sometimes have to pick between those options. If you have something new and very limited resources, get something going and refactor it later.

hooby 5y ago
I'm not talking about making everything technically perfect. I'm talking about removing things which cause extra work, are more error-prone, do not scale, and/or demotivate the team.
smcin 5y ago
"Technical Perfectionism", The other extreme on the spectrum.