5 ms·

Ask HN: How to Manage Tech Debt?

Hello Denizens of Hacker News, a topic that has been on my mind a lot recently is how to effectively manage technical debt. As a veteran developer who has worked for a variety of companies I have mostly seen tech debt handled poorly, even to the point of developers being penalized by management for not working quickly enough. I wanted to ask… What are the most common types of tech debt you’ve seen in your companies? How do you prioritize dealing with tech debt so that the team stays productive?

serverlessmom 4y ago
I also talked about this a bit here: https://twitter.com/trycourier/status/1519088057231806465 https://twitter.com/trycourier/status/1519088057231806465
FeaturelessBug 4y ago
I'm newer to the field: is tech debt something that can be avoided and is it possible for some teams to not have tech debt or to avoid it all together?
- bruce511 4y ago
  Debt exists for a reason. It allows you to defer the cost of something, while enjoying the benefits sooner. Tech debt is the same - it allows for benefits sooner, but at a price later on. Let's say you have a new idea. You can spent 10x effort to make version 1 perfect or 1x effort (with 9x technical debt) to make something good enough. Sure it might have brittle code, sure it might crash a bit, sure the interface is a bit inconsistent, and there are no docs, but hey it works - does anyone care enough to pay got it? The 1x approach gets to market fast, helps determine if there even _is_ a market at all. If the project is successful then the tech debt has to be "paid" in re-architecting, refactoring and in some cases rewriting. If it is unsuccessful then no harm done, just move on. There's definitely a place in an early project for moving quickly, there's definitely a place in a mature project for moving slowly, but getting everything right. The real trick is figuring out when to switch - the later you do it the more debt you accumulate. Too soon and you waste resources that may be needed more critically elsewhere. The big problem of course are places where they never pay down the debt - until the whole thing collapses, and you're best off just throwing it all away - which you can't do because there are a bunch of paying users so you just keep hobbling along. Avoiding tech debt altogether is expensive in money and time. But assuming you have both of those, then yes, tech debt can be avoided. (at least for now, no-one can predict what new things might exist tomorrow.)
- angrydev 4y ago
  I would say no, not really. If you build something and then never need to touch it again, well then it must be working perfectly and so there's no debt to pay off. However that is almost never the case. If you continuously work on the code, it will accumulate debt over time in the form of bugs, or design flaws when taking shortcuts implementing new behavior. The more people you have working in the same area, the likelier this is to occur. The long term solution like one of the posters in another thread said, is to pay down your tech debt strategically over time. Good habits for preparing to deal with it are keeping tests updated, and commenting in sections that get particularly gnarly.
  - FeaturelessBug 4y ago
    Thank you for your response! So the best strategy to maintain tech debt and keep it manageable is to fit dragons with it into your teams overall time budget. That definitely feels more realistic than trying to keep it from happening at all
Jtsummers 4y ago
Avoidance of DRY. This has crippled so many projects at my various employers. Bugs end up replicated throughout and fixed piecemeal over time because no one remembers where the bug got copied to. Or if it even was a bug in the other places! The original may still be correct but the copy may have been insufficiently changed, for instance, but after a few years no one is certain what was the original (good version control helps here). Current employer is about to embark on a massive copy/paste project (literally, that's the plan) versus properly parameterizing the existing system so that we can reduce the current dozens of copies down to a few manageable copies (where things are too different for mere parameterization changes). What I've pushed for is simple, regular refactoring. Build it into whatever your release cycle is. Sprints? Every sprint involves a cleanup effort, doesn't have to be big, but something. Kanban? Try to make sure that X% (measured over some period of time) of your work is cleanup. Larger release cycles? Do the same thing, it doesn't need to be much but it needs to be constant. You skip it once, it's like skipping the gym for a week. The habit is broken, good luck getting back to it. And it's worse here, management will see an apparent improvement in output (because you skipped that cleanup for a reason, to achieve some other release goal). And it will become deprioritized.

serverlessmom 4y ago

I also talked about this a bit here: https://twitter.com/trycourier/status/1519088057231806465 https://twitter.com/trycourier/status/1519088057231806465

FeaturelessBug 4y ago

I'm newer to the field: is tech debt something that can be avoided and is it possible for some teams to not have tech debt or to avoid it all together?

bruce511 4y ago
Debt exists for a reason. It allows you to defer the cost of something, while enjoying the benefits sooner. Tech debt is the same - it allows for benefits sooner, but at a price later on. Let's say you have a new idea. You can spent 10x effort to make version 1 perfect or 1x effort (with 9x technical debt) to make something good enough. Sure it might have brittle code, sure it might crash a bit, sure the interface is a bit inconsistent, and there are no docs, but hey it works - does anyone care enough to pay got it? The 1x approach gets to market fast, helps determine if there even _is_ a market at all. If the project is successful then the tech debt has to be "paid" in re-architecting, refactoring and in some cases rewriting. If it is unsuccessful then no harm done, just move on. There's definitely a place in an early project for moving quickly, there's definitely a place in a mature project for moving slowly, but getting everything right. The real trick is figuring out when to switch - the later you do it the more debt you accumulate. Too soon and you waste resources that may be needed more critically elsewhere. The big problem of course are places where they never pay down the debt - until the whole thing collapses, and you're best off just throwing it all away - which you can't do because there are a bunch of paying users so you just keep hobbling along. Avoiding tech debt altogether is expensive in money and time. But assuming you have both of those, then yes, tech debt can be avoided. (at least for now, no-one can predict what new things might exist tomorrow.)
angrydev 4y ago
I would say no, not really. If you build something and then never need to touch it again, well then it must be working perfectly and so there's no debt to pay off. However that is almost never the case. If you continuously work on the code, it will accumulate debt over time in the form of bugs, or design flaws when taking shortcuts implementing new behavior. The more people you have working in the same area, the likelier this is to occur. The long term solution like one of the posters in another thread said, is to pay down your tech debt strategically over time. Good habits for preparing to deal with it are keeping tests updated, and commenting in sections that get particularly gnarly.
- FeaturelessBug 4y ago
  Thank you for your response! So the best strategy to maintain tech debt and keep it manageable is to fit dragons with it into your teams overall time budget. That definitely feels more realistic than trying to keep it from happening at all

Jtsummers 4y ago

Avoidance of DRY. This has crippled so many projects at my various employers. Bugs end up replicated throughout and fixed piecemeal over time because no one remembers where the bug got copied to. Or if it even was a bug in the other places! The original may still be correct but the copy may have been insufficiently changed, for instance, but after a few years no one is certain what was the original (good version control helps here). Current employer is about to embark on a massive copy/paste project (literally, that's the plan) versus properly parameterizing the existing system so that we can reduce the current dozens of copies down to a few manageable copies (where things are too different for mere parameterization changes). What I've pushed for is simple, regular refactoring. Build it into whatever your release cycle is. Sprints? Every sprint involves a cleanup effort, doesn't have to be big, but something. Kanban? Try to make sure that X% (measured over some period of time) of your work is cleanup. Larger release cycles? Do the same thing, it doesn't need to be much but it needs to be constant. You skip it once, it's like skipping the gym for a week. The habit is broken, good luck getting back to it. And it's worse here, management will see an apparent improvement in output (because you skipped that cleanup for a reason, to achieve some other release goal). And it will become deprioritized.