Ask HN: How do you deal with technical debt?
I've always interpreted technical debt as: 'Doing something in a half-assed way and then paying for it later'.
What strategies and methods are you using to combat this?
What strategies and methods are you using to combat this?
Depending on what you're working on, there's a good chance if you build things to be good enough to handle the next 6 months, when you look at it in 6-12 months, the situation is one of these:
a) you don't need this at all, and should throw it away
b) what you did meets your needs for the forseable future
c) what you did no longer meets your needs, because the requirements changed or because real use clarified the requirements
d) your solution worked, but usage skyrocketed and it didn't scale
With option A or B, doing it half ass saved you time. With option C, maybe full ass would have been better, but it depends. Sometimes you guess about future needs and get lucky; sometimes you need to throw it out and rebuild, knowing the current one is half-ass makes it easier to throw away.
If you run into D, great, you've got users! Often, you need to use a more complex system to handle scaling, so you don't want to do that too early, but it depends on where you are in terms of use. Making things scale only when they need to adds stress, but also clarity.
If you find yourself outgrowing your half-ass solutions after 5 years, maybe consider quarter-ass instead to save time. If you find yourself revisiting things once a month, try three-quarter-ass. It's a balance. Another important thing is to focus more on the interfaces between components, because those are hard to change. And reduce dependencies in general and between components as much as possible; changes that require multi-stage deployments are harder.
When you build a new feature, IMO, its ok if 80% of your time is spent writing a test for a first pass crappy solution. (Good) tests make it easier to refactor.
Dealing with legacy code?
The art is knowing HOW to introduce tests. Outside in is the best way IMO. Start with end to end tests, testing the system at well-defined stable interfaces like external APIs. Then carve up the most important internals first.
Also you always have tech debt FWIW. There is no time where it’s profitable to have zero tech debt anywhere. We have to prioritize our investments in the highest priority areas of our code.