Downside: A dedicated budget makes tidying appear to be a discrete activity rather than an integrated one. As a discrete activity, people and teams likely have to decide together when to engage in it which adds additional overhead. You introduce discussions about production vs. production capability that don't often map well to the types of small changes that are helpful. Empowering individuals (or pairs) tidy as needed allows them to "JIT-tidy".
I often find I'm only in the right mindset to "tidy" when I'm embedded in a section of the codebase in pursuit of a real feature. Only then can I accurately discern the cruft from the necessary complexity, or have a deep enough understanding of the relevant parts of the domain to have an insight about what the right abstraction is. Separating out a "tidying budget" seems to imply separating out "tidying time", which I don't think would be as effective. And having to think about, "Oh, I'm going to allocate 5% of my 30% tidying budget to this story" seems like waste to me.
I will likely find these below but my immediate thoughts are:
Upsides: Could be a great way to bring people up to speed on the codebase while making it better and idiomatic to the team. Shows dedication to design/code quality.
Downsides: Will probably end up tidying a lot of code that will never change (waste) and might indicate that tidying is a separate, special activity from development that can be safely deferred.
Upside: If you're in a bad spot it can with concentrated effort bring you to "not too shabby" and it becomes normal to do small consistent tidying? Kind of the idea of getting good at pottery you don't do one great pot you do 100 ones and by the end, you likely have a couple of great pots? By budgeting, you're showing it's acceptable to clean, and you're building a muscle while scrubbing away some grimy stains?
Feels a bit counterproductive to the general recommendation of starting habits small, though?
As others already mentioned, "fixed" indicates boundaries exist. One week you need a lot of effort, another period there is not much to tidy.
One should not fall into the pitfall of tidying, "just because". That's cargo cult tidying growing into your processes.
Is tidying allowed? Yes! Ok, let's go. And as a guideline (!!) see if we don't spend more than 30%. But, if it's really needed to take up to 45% (whatever) with good reasons and times permits it, don't stall.
The problem is allocating the time, area, impact and (capable) capacity with a certain amount of certainty. Risk analysis teaches you that certainty doesn't exist and unforeseeable risks are bound to happen anyway. So, in the middle of a huge refactoring something happens, how loose coupled your code is doesn't matter. The one who started it becomes ill, or worse.
Or your data center collapses and you have to work on becoming stable again. Or you get blocked by an unexpected update from a third party dependency that no longer wants to be integrated like it was before (security updates???). etc.
There is no quick win, silver bullet or holy grail on software development, debugging or tidying.
Setting up proper coding conventions and aligned patterns is a big plus. But todays best practice can become tomorrows anti-pattern and pitfall. Then what?
- sometimes, we need fresh eyes on a problem to see what’s possible. Budgeting time to tidy may give you that opportunity to see code qith fresh eyes on a design to improve or discover what it should be.
- offer opportunity to practice. And, with time you’ll do it more and more and JIT tidy because you’ll see the value.
Downsides:
- tyding something that do not bring value to the capacity to deliver value, because not directly related to a feature since you feel mandated to tidy.
- reduce the responsibility on the team to improve and tidy the code.
I think a tidying budget probably comes up most often as a response to under-investment in tidying. So regardless of whether it’s a universally good idea, the question is probably “will a tidying budget help *those* teams engage in tidying more constructively?”
On the one hand, those teams need help and this may mesh nicely with their environment. On the other hand, that environment is probably the most at risk of creating an anti-pattern around a tidying budget.
Perhaps a tidying budget is useful as an external signal - to get external stakeholders to ease up on the feature firehouse, and to explain that if tidying is now 10% of the time we may be creating trouble for the future - but more or less ignored as a metric by the team itself.
I think having a defined budget is more important when are you doing capacity planning, also in context when estimating effort is required. If tidying is paying technical debt, then as in financial debt you should make a prioritization about where are you are paying high interest and a large amount of them. Refactoring should be an integrated practice in iterative and incremental development.
An upside was breaking the disbelief that some people expressed that the organisation would make time for tidying work.
Downsides included:
In a culture of "planning tetris" with insufficent slack teams look for things to drop when they invariably get behind. That tidying budget looks awfully tempting if dropping other things means having difficult conversations with customers...
Deferring tidying work that should have come first. "We have a tidying budget for that, let's just focus on the task at hand" cue wasting lots of time trying to make progress in the midst of a mess.
My biggest reason for avoiding trying it again is it seems to be papering over the real problem. What's stopping teams and individuals from feeling free to do the tidying work they know is needed? There are incentives at work. Adding a fixed budget can create an incentive to counter the problematic incentive. Better to fix the problematic incentive. Why do people feel they can't tidy? Why can't we trust them to spend enough time on tidying (which is what imposing a 30% allocation sounds like). Maybe it's incentives we're reinforcing.
As a team-lead or business-owner role, I'd be inclined to lead the 30% time with a periodic question (every sprint maybe) : How did you use your 30% time this sprint? Did you use it all? If no... WHY didn't you use it all?
The pressure is on the side of purposefully consuming that percentage, since the human-nature default is going to be defer the refactoring too-long (in a concern for conservation or response for time/cost reduction pressure).
There's a lot of upside, I think, in communicating explicitly to engineers that tidying is important, and that your expectation (and their expectation) is that it happens. And, of course, you have to make it happen, and show it happen. It's hard to make tidying be purely an activity that happens in the middle of other work--some refactoring requires dedicated time to get right, one or more sprints.
Downside: A dedicated budget makes tidying appear to be a discrete activity rather than an integrated one. As a discrete activity, people and teams likely have to decide together when to engage in it which adds additional overhead. You introduce discussions about production vs. production capability that don't often map well to the types of small changes that are helpful. Empowering individuals (or pairs) tidy as needed allows them to "JIT-tidy".
I often find I'm only in the right mindset to "tidy" when I'm embedded in a section of the codebase in pursuit of a real feature. Only then can I accurately discern the cruft from the necessary complexity, or have a deep enough understanding of the relevant parts of the domain to have an insight about what the right abstraction is. Separating out a "tidying budget" seems to imply separating out "tidying time", which I don't think would be as effective. And having to think about, "Oh, I'm going to allocate 5% of my 30% tidying budget to this story" seems like waste to me.
I will likely find these below but my immediate thoughts are:
Upsides: Could be a great way to bring people up to speed on the codebase while making it better and idiomatic to the team. Shows dedication to design/code quality.
Downsides: Will probably end up tidying a lot of code that will never change (waste) and might indicate that tidying is a separate, special activity from development that can be safely deferred.
Upside: If you're in a bad spot it can with concentrated effort bring you to "not too shabby" and it becomes normal to do small consistent tidying? Kind of the idea of getting good at pottery you don't do one great pot you do 100 ones and by the end, you likely have a couple of great pots? By budgeting, you're showing it's acceptable to clean, and you're building a muscle while scrubbing away some grimy stains?
Feels a bit counterproductive to the general recommendation of starting habits small, though?
I hope that a fixed budget for tidying would help people take the activity seriously. We're doing it, so let's do it.
I worry that a fixed budget for tidying would interfere with people learning to incorporate tidying into their regular work.
As others already mentioned, "fixed" indicates boundaries exist. One week you need a lot of effort, another period there is not much to tidy.
One should not fall into the pitfall of tidying, "just because". That's cargo cult tidying growing into your processes.
Is tidying allowed? Yes! Ok, let's go. And as a guideline (!!) see if we don't spend more than 30%. But, if it's really needed to take up to 45% (whatever) with good reasons and times permits it, don't stall.
The problem is allocating the time, area, impact and (capable) capacity with a certain amount of certainty. Risk analysis teaches you that certainty doesn't exist and unforeseeable risks are bound to happen anyway. So, in the middle of a huge refactoring something happens, how loose coupled your code is doesn't matter. The one who started it becomes ill, or worse.
Or your data center collapses and you have to work on becoming stable again. Or you get blocked by an unexpected update from a third party dependency that no longer wants to be integrated like it was before (security updates???). etc.
There is no quick win, silver bullet or holy grail on software development, debugging or tidying.
Setting up proper coding conventions and aligned patterns is a big plus. But todays best practice can become tomorrows anti-pattern and pitfall. Then what?
Upsides:
- sometimes, we need fresh eyes on a problem to see what’s possible. Budgeting time to tidy may give you that opportunity to see code qith fresh eyes on a design to improve or discover what it should be.
- offer opportunity to practice. And, with time you’ll do it more and more and JIT tidy because you’ll see the value.
Downsides:
- tyding something that do not bring value to the capacity to deliver value, because not directly related to a feature since you feel mandated to tidy.
- reduce the responsibility on the team to improve and tidy the code.
I think a tidying budget probably comes up most often as a response to under-investment in tidying. So regardless of whether it’s a universally good idea, the question is probably “will a tidying budget help *those* teams engage in tidying more constructively?”
On the one hand, those teams need help and this may mesh nicely with their environment. On the other hand, that environment is probably the most at risk of creating an anti-pattern around a tidying budget.
Perhaps a tidying budget is useful as an external signal - to get external stakeholders to ease up on the feature firehouse, and to explain that if tidying is now 10% of the time we may be creating trouble for the future - but more or less ignored as a metric by the team itself.
I think having a defined budget is more important when are you doing capacity planning, also in context when estimating effort is required. If tidying is paying technical debt, then as in financial debt you should make a prioritization about where are you are paying high interest and a large amount of them. Refactoring should be an integrated practice in iterative and incremental development.
Few Observations from trying it:
An upside was breaking the disbelief that some people expressed that the organisation would make time for tidying work.
Downsides included:
In a culture of "planning tetris" with insufficent slack teams look for things to drop when they invariably get behind. That tidying budget looks awfully tempting if dropping other things means having difficult conversations with customers...
Deferring tidying work that should have come first. "We have a tidying budget for that, let's just focus on the task at hand" cue wasting lots of time trying to make progress in the midst of a mess.
My biggest reason for avoiding trying it again is it seems to be papering over the real problem. What's stopping teams and individuals from feeling free to do the tidying work they know is needed? There are incentives at work. Adding a fixed budget can create an incentive to counter the problematic incentive. Better to fix the problematic incentive. Why do people feel they can't tidy? Why can't we trust them to spend enough time on tidying (which is what imposing a 30% allocation sounds like). Maybe it's incentives we're reinforcing.
If you don't use it, will you lose it?
(Using the trite assumption about disappearing unused budgets.)
As a team-lead or business-owner role, I'd be inclined to lead the 30% time with a periodic question (every sprint maybe) : How did you use your 30% time this sprint? Did you use it all? If no... WHY didn't you use it all?
The pressure is on the side of purposefully consuming that percentage, since the human-nature default is going to be defer the refactoring too-long (in a concern for conservation or response for time/cost reduction pressure).
There's a lot of upside, I think, in communicating explicitly to engineers that tidying is important, and that your expectation (and their expectation) is that it happens. And, of course, you have to make it happen, and show it happen. It's hard to make tidying be purely an activity that happens in the middle of other work--some refactoring requires dedicated time to get right, one or more sprints.
Define budget.