I've been trying to figure out how to push for and justify code cleanup at the startup I work at where there's immense pressure to deliver the next thing. There are areas of the codebase where we can all nod our heads and agree that it's difficult to work with and slows down development, but taking the next step to invest in cleanup or encourage engineers to think about tidying first (or even after) so building the next thing is easier has been difficult. I like the idea of price per minutes, it helps with thinking about how to structure the discussion and push on whether we are avoiding delay of tidying because that's what has become the culture versus a concrete risk.
On of he main goal of tidying is to avoid delays by reducing technical debt. So that it should be, as you said, only with a few exceptions from Tidy First.
I like the specific framing of “making behavior changes easier”. That’s a goal everyone can agree on.
As far as the answer being to always tidy first, that’s my bias but leaves important questions unanswered like how to tidy and when to stop tidying for now and whether to tidy after or later. We all develop intuitions about these questions but how do you learn?
I see tidying as polishing. It's a kind of finishing touch. For the perfectionist, this can take forever. Perfection doesn't exist, but when to stop?
Tidying can only be done on top of the bare minimum. Starting with tidying too early doesn't make sense. Things will still being able to be moved around. Sometimes quite often even. It's like starting dusting on the floor, then the table and at the end on top of the cupboards. At the end, you can do it all over again and it will never end. Definition of silly.
With bare minimum I mean, on top of all the best practices already in place. If you already have high standards, tidying will be much easier. If you think bare minimum is working with a ball of mud, you have a hard time (and a long one too) polishing it.
So, what is your bare minimum and how much of tidying do you expect to need to do on top of that? That should be some starting point.
I think "polishing" is the wrong metaphor. It's more like a clean-as-you-go approach to a workshop or your kitchen. Instead of letting stuff pile up around you as you work, getting in your way, you continuously keep your work area, errm, literally tidy. This actually increases the speed and convenience with which you can work.
So, tidying goes pretty much all the time, as you identify small areas of poor design in the code, and improve them in very small steps.
I've been trying to figure out how to push for and justify code cleanup at the startup I work at where there's immense pressure to deliver the next thing. There are areas of the codebase where we can all nod our heads and agree that it's difficult to work with and slows down development, but taking the next step to invest in cleanup or encourage engineers to think about tidying first (or even after) so building the next thing is easier has been difficult. I like the idea of price per minutes, it helps with thinking about how to structure the discussion and push on whether we are avoiding delay of tidying because that's what has become the culture versus a concrete risk.
I hope that helps. Also, if managers are fussing about minutes they are certainly wasting days. I was hoping “tidying” would slip under the radar.
On of he main goal of tidying is to avoid delays by reducing technical debt. So that it should be, as you said, only with a few exceptions from Tidy First.
I like the specific framing of “making behavior changes easier”. That’s a goal everyone can agree on.
As far as the answer being to always tidy first, that’s my bias but leaves important questions unanswered like how to tidy and when to stop tidying for now and whether to tidy after or later. We all develop intuitions about these questions but how do you learn?
Great read, thanks!
This may or may not be a small typo, but just in case:
"When do want to invest that time in software design?"
Maybe there is a "we" missing between "do want"?
I see tidying as polishing. It's a kind of finishing touch. For the perfectionist, this can take forever. Perfection doesn't exist, but when to stop?
Tidying can only be done on top of the bare minimum. Starting with tidying too early doesn't make sense. Things will still being able to be moved around. Sometimes quite often even. It's like starting dusting on the floor, then the table and at the end on top of the cupboards. At the end, you can do it all over again and it will never end. Definition of silly.
With bare minimum I mean, on top of all the best practices already in place. If you already have high standards, tidying will be much easier. If you think bare minimum is working with a ball of mud, you have a hard time (and a long one too) polishing it.
So, what is your bare minimum and how much of tidying do you expect to need to do on top of that? That should be some starting point.
I think "polishing" is the wrong metaphor. It's more like a clean-as-you-go approach to a workshop or your kitchen. Instead of letting stuff pile up around you as you work, getting in your way, you continuously keep your work area, errm, literally tidy. This actually increases the speed and convenience with which you can work.
So, tidying goes pretty much all the time, as you identify small areas of poor design in the code, and improve them in very small steps.
I think developers will never get out of this. Clean-as-you-go for me is part of the bare minimum, not an after thought. So I guess we agree.