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.
In my opinion, sometimes it makes sense to build half-baked solution, especially if you are trying to validate a new direction you are not sure about it.
The hard part in my opinion is catching the time when that 'validation' phase ends, and getting the time you need to properly write the feature, instead of continuing on that shaky foundation.
It requires a lot of communication and trust between product and engineering.
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.
I would say the title is a good spark for the discussion. In general I do believe 20% does work. But I also experienced some cases where it brought more harm than good.
E.g. migrating services from company's main language (Java), to something more exotic (Go, Node - where there was literally single engineer in the entire organization knowing these). Or adding background sync service to the product where offline database doesn't make any sense because data must be always up to date. Or adding some machine learning pipeline which processed wrong data and produced wrong outputs presented to cusomers (fixing it took months).
These are singular cases, but because they were unsupervised and no one cared what engineers did in their "20% time", they actually generated quite a lot of chaos and harm.
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.
In my opinion, sometimes it makes sense to build half-baked solution, especially if you are trying to validate a new direction you are not sure about it.
The hard part in my opinion is catching the time when that 'validation' phase ends, and getting the time you need to properly write the feature, instead of continuing on that shaky foundation.
It requires a lot of communication and trust between product and engineering.
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.
Yeah, the credit for the presentations goes to Mirek, the blame for the misleading title to myself :)
It should have been something like '20% for tech debt' won't solve all your problems.
I would say the title is a good spark for the discussion. In general I do believe 20% does work. But I also experienced some cases where it brought more harm than good.
E.g. migrating services from company's main language (Java), to something more exotic (Go, Node - where there was literally single engineer in the entire organization knowing these). Or adding background sync service to the product where offline database doesn't make any sense because data must be always up to date. Or adding some machine learning pipeline which processed wrong data and produced wrong outputs presented to cusomers (fixing it took months).
These are singular cases, but because they were unsupervised and no one cared what engineers did in their "20% time", they actually generated quite a lot of chaos and harm.