Technical Debts - The Yak's hair
Good article to give a strategy on how to deal with tech debt.
The excerpt of it:
Make the habbit
- have a board, make it visible
- before each large feature, scroll through the list of tech debts that may be affected/would make a significance difference on the delivery quality
- When digging into it/trying to fix it, list the things that are connected/would be broken by it. Being aware of the dependencies can scope the problem properly, maybe the first thing is fixing a smaller dependency first.
- Let it go if it's vastly out of scope
Make it visible!
- Log time that was wasted due to one of these technical debts
- "The point is not to fix all technical debt. The point is to learn to negotiate when to add it, when to fix it, and when to avoid it."
- The question shouldn’t be “Do we have time now?”, it should be “Is it worth paying interest on this later? How much?” The answer could range anywhere from “It doesn’t matter, just commit it” to “Lots of things will depend on this, let’s get it right before moving on.”
- It should be a physical board somewhere with post-its, but we do not have that in remote work
- Should not start with writing a big list
- Devs always want to optimize. Resist, do only the most meaningful ones: many times it does not worth to fix something.
My first reaction when I read it: Of course I wrote a big list of it.
long term development yaks technical debt programming