Discussion about this post

User's avatar
Akos Komuves's avatar

Structuring the technical debt and baking it into the engineering culture so that we don't build half-baked solutions, no matter how simple the requirement, made a big difference in my thinking.

While working solo, when I built a helper library or a tool, I strived to have the least amount of code for the specific scenario I was solving, and I lived by this rule for so long.

While this is not wrong, now I see that the drawback of such simple solutions was a rigid architecture that almost always required a rewrite later.

As for the exact percentage, I don't know. There's a difference between a tech debt such as a long-ish running query or replacing a JS library that we've been dragging for years and has security vulnerabilities. But right now, we dedicate around 20% of our effort to only one of our tech debts. That's an entire rewrite, it doesn't have a separate backlog, and it's part of the sprint planning.

Expand full comment
David Foster's avatar

Good presentation of some potential pitfalls of dedicating a % of time for tech debt or other maintenance work. However I disagree with the title, which seems to imply the entire approach doesn't make sense.

A few years ago, before my team started carving out a % of time for maintenance work, there were some tasks that were simply not done because they were too difficult to tie to individual features of interest to the business. For example: annual upgrades of dependencies, security-related infrastructure work, etc. My team is definitely better-off after consistently carving out a % for maintenance tasks that can't be tied to individual features.

Expand full comment
6 more comments...

No posts