Investing 10% to Pay Back Technical Debt
Alex Ewerlöf (via Christian Tietze, Hacker News):
Almost everyone in the team had less experience than me (at least on paper) yet a simple task would take me multiple days longer than I thought. Yet, I felt dumb and helpless.
[…]
You see, the leadership did not care about the code quality as long as the stories were delivered on time. Corners were cut, tests were skipped[…]
[…]
Every other week, we had the “Tech Debt Friday”. These days were not planned for a specific issue or story. […] Engineers looked forward to the Tech Debt Friday. The team would happily remind management that this day cannot (under any circumstances) be planned for regular feature/bugfix work. Although we fixed some bugs along the way, this was primarily an investment to make future feature development cheaper while improving the maintainability and reliability.
Initially it was hard to defend spending 10% of the team bandwidth on tech debt, but over time the payback was huge[…]
I’ve seen “x% time for tech debt“ rules in several companies and sadly it didn’t work too well.
Since the problem was the culture of continually pushing half baked features in the first place, the rule was quickly corrupted: people would design a good system, throw anything that’s not required for a POC into the tech debt backlog and deliver a barely functioning version.
“This is a technical debt task” was used to prevent everything that wasnt new Features taking time of the other 90% of the sprint.
Basically, if you assign a block of time to quality, you risk people taking that as an excuse to not focus on quality outside that block.
Previously:
- Southwest Airlines and Technical Debt
- Entropy of Big Distributed Systems
- A Cautionary Tale From the Decline of SourceForge
- Why Little Bugs Need to Get Fixed
- Toward a Galvanizing Definition of Technical Debt
- FogBugz, JIRA, and Wasabi
- Bad Code Isn’t Technical Debt, It’s an Unhedged Call Option
- Stack Exchange Technical Debt
- Core Rot at Apple
- You Are Not Ruthless Enough
Update (2023-06-23): Collin Donnell (Mastodon):
There are only two times technical debt will ever be addressed: upfront or never.
[…]
The thing you can do upfront is refactor as you go (don’t overdo it) and make it as easy possible to change your mind later. Delay, delay, delay. Just make as few decisions as you can, so when you have to do the next thing.
