Sep 13, 2022·edited Sep 13, 2022Liked by Kent Beck
I can imagine thinking this is a great idea or a terrible idea, depending on the situation. Let's pretend for the moment we are all friends here and agree in principle on the value of Shu-Ha-Ri.
If we consciously choose to tidy as a form of practice and habit-building, then I love it. We can tidy in a purely speculative way, because we are practising tidying and built the habit of wanting to tidy. We are choosing to tidy when it is safe and calm in order to prepare ourselves better to tidy under pressure when it is difficult.
This kind of speculative tidying has uneven and maybe unpredictable value. This provides more benefit when (1) we're only rehearsing and don't need to perform or (2) the code base is so bad that tidying any of it is likely to have benefit or (3) we don't know how to assess the hotspots of the code base and we use this speculative tidying as a way to map out the territory. However we approach this speculative tidying, we'd best limit our investment of time and energy, because otherwise some programmers fall in love with tidying and forget to ship features while other programmers find it tedious and give up just before it gets good.
This seems to make the advice or choice to "set aside 30% of our time for tidying" helpful mostly for focusing on building up production capacity. Once a group has enough of that, it seems wise to switch to a much more focused, tactical, just-in-time approach, where the design improvements both feel more compelling (we're just about to change this and now that's much clearer!) and more responsible (we're focusing on the part that needs to change next).
But... how do we know that we have enough production capacity to swing from speculative to purposeful tidying? I don't know, but I can guess. Try both. Typical human boredom will probably lead the average programmer to switch to purposeful tidying, but when volatility in the amount of tidying feels "too high", then it's worth budgeting time for some speculative tidying, either because they need to work more efficiently (practise! practise!) or they don't yet have enough of a habit of tidying as they go. This means some combination of (1) setting aside time to tidy as a separate stream of work and (2) more cleaning up before moving on in their daily work. I encourage timeboxing both.
As the programmers gain more experience, have more-deeply-ingrained habits, and more finely-honed judgment, they merely tidy as much as they need where they need it and when they need it. They find their balance easily. In this context, setting aside a fixed budget for tidying probably doesn't make much sense, unless they need it to recover from having consciously decided to rush temporary in order to meet a short-term milestone.
I also think it depends on other factors. What is the goal of the change? How important or critical is the change? How big is the impact of the change, both technical and functional wise? In what area will the change occur? Who will make the change and who will do the tidying? How much time will the tidying take versus how much time will making the change take? Is it worth it?
Some parts of the code will never or hardly ever change. Some parts are prone to changes every month or every year.
Let's say tidying your home is needed. But for what occasion? If it's just daily/weekly routine it's not that much. But what if guests will come over? A birthday party or some other joyful event to celebrate. You want the living room, the kitchen and the bathrooms neat and tidy.
But in case you have guests sleeping over, you also need to tidy their guest space. Depending on the duration of the stay it is also needed to accommodate other things.
Another situation might occur where you want to sell the house. In that case quite an overhaul has to take place. Not to only tidy it, but to make it presentable, marketable. And not just the living room, but everything, the whole shebang (#!). Until the house is sold, it can take ages before the strict tidying can loosen up a bit again.
Spontaneously the social aspects feel a bit like having flatmates. From my own flat, if everyone is cleaning up after themselves as they go along, the apartment is nice and clean. But when one stops doing the dishes, then the others don't want to do their dishes as well since, well, ehm, "we're not your mom." So it piles up. Aaand then one day, someone gets tired of the stink of all the unwashed cups and plates and does all of it at once.
Essentially rewarding this one flatmate's bad behavior.
And even if the rest of us accepts that we'll have to bite the bullet every so often, the 30% extra time overall, it doesn't fully share the load, which feels quite important for that community around both the home and the codebase. I, at least, would rather be where we feel the pride to clean up after ourselves.
The flatmate story ended with that person being responsible for getting a cleaner in on a weekly basis since we got feed up cleaning up after them, and no amount of asking them to clean up after themselves helped. We have accepted this and moved on since we found another solution.
I don't like the idea of separating the activities in people's minds. TDD seems better when thought of as part of the development process - same for tidying.
Question, with a 30% tidying fixed budget, what was hoping to achieve the CTO?
I agree with your considerations, it really sounds speculative and possibly a waste of time (like tying parts of the code that will never need to be changed).
Did they mean Tech Debt as ’an incomplete understanding of the problem' or Tech Debt meaning 'The codebase is a complete mess and productivity has ground to a halt'. In my experience this kind of request comes from the latter and is symptom of much wider dysfunction.
I passed by some teams that really needed this 30% for tidying. Teams were tasks were always due yesterday and there was a lot of technical debt that was inherited from previous developers. As we were always in a hurry we were always increasing the tech debt, and when I raised my hand and tried to discuss a few refactorings or the addition of unit tests I was told that we had better things to do. So yes there are teams that really need that 30%
Perhaps: because these engineers wouldn’t believe that the 30% debt-paying will be *actually* valued by the management, so they would avoid it, consciously or not.
Remember, these engineers live in the context that led to a techical-debt-ridden codebase.
I can imagine thinking this is a great idea or a terrible idea, depending on the situation. Let's pretend for the moment we are all friends here and agree in principle on the value of Shu-Ha-Ri.
If we consciously choose to tidy as a form of practice and habit-building, then I love it. We can tidy in a purely speculative way, because we are practising tidying and built the habit of wanting to tidy. We are choosing to tidy when it is safe and calm in order to prepare ourselves better to tidy under pressure when it is difficult.
This kind of speculative tidying has uneven and maybe unpredictable value. This provides more benefit when (1) we're only rehearsing and don't need to perform or (2) the code base is so bad that tidying any of it is likely to have benefit or (3) we don't know how to assess the hotspots of the code base and we use this speculative tidying as a way to map out the territory. However we approach this speculative tidying, we'd best limit our investment of time and energy, because otherwise some programmers fall in love with tidying and forget to ship features while other programmers find it tedious and give up just before it gets good.
This seems to make the advice or choice to "set aside 30% of our time for tidying" helpful mostly for focusing on building up production capacity. Once a group has enough of that, it seems wise to switch to a much more focused, tactical, just-in-time approach, where the design improvements both feel more compelling (we're just about to change this and now that's much clearer!) and more responsible (we're focusing on the part that needs to change next).
But... how do we know that we have enough production capacity to swing from speculative to purposeful tidying? I don't know, but I can guess. Try both. Typical human boredom will probably lead the average programmer to switch to purposeful tidying, but when volatility in the amount of tidying feels "too high", then it's worth budgeting time for some speculative tidying, either because they need to work more efficiently (practise! practise!) or they don't yet have enough of a habit of tidying as they go. This means some combination of (1) setting aside time to tidy as a separate stream of work and (2) more cleaning up before moving on in their daily work. I encourage timeboxing both.
As the programmers gain more experience, have more-deeply-ingrained habits, and more finely-honed judgment, they merely tidy as much as they need where they need it and when they need it. They find their balance easily. In this context, setting aside a fixed budget for tidying probably doesn't make much sense, unless they need it to recover from having consciously decided to rush temporary in order to meet a short-term milestone.
I also think it depends on other factors. What is the goal of the change? How important or critical is the change? How big is the impact of the change, both technical and functional wise? In what area will the change occur? Who will make the change and who will do the tidying? How much time will the tidying take versus how much time will making the change take? Is it worth it?
Some parts of the code will never or hardly ever change. Some parts are prone to changes every month or every year.
Let's say tidying your home is needed. But for what occasion? If it's just daily/weekly routine it's not that much. But what if guests will come over? A birthday party or some other joyful event to celebrate. You want the living room, the kitchen and the bathrooms neat and tidy.
But in case you have guests sleeping over, you also need to tidy their guest space. Depending on the duration of the stay it is also needed to accommodate other things.
Another situation might occur where you want to sell the house. In that case quite an overhaul has to take place. Not to only tidy it, but to make it presentable, marketable. And not just the living room, but everything, the whole shebang (#!). Until the house is sold, it can take ages before the strict tidying can loosen up a bit again.
Spontaneously the social aspects feel a bit like having flatmates. From my own flat, if everyone is cleaning up after themselves as they go along, the apartment is nice and clean. But when one stops doing the dishes, then the others don't want to do their dishes as well since, well, ehm, "we're not your mom." So it piles up. Aaand then one day, someone gets tired of the stink of all the unwashed cups and plates and does all of it at once.
Essentially rewarding this one flatmate's bad behavior.
And even if the rest of us accepts that we'll have to bite the bullet every so often, the 30% extra time overall, it doesn't fully share the load, which feels quite important for that community around both the home and the codebase. I, at least, would rather be where we feel the pride to clean up after ourselves.
The flatmate story ended with that person being responsible for getting a cleaner in on a weekly basis since we got feed up cleaning up after them, and no amount of asking them to clean up after themselves helped. We have accepted this and moved on since we found another solution.
I don't like the idea of separating the activities in people's minds. TDD seems better when thought of as part of the development process - same for tidying.
Question, with a 30% tidying fixed budget, what was hoping to achieve the CTO?
I agree with your considerations, it really sounds speculative and possibly a waste of time (like tying parts of the code that will never need to be changed).
Did they mean Tech Debt as ’an incomplete understanding of the problem' or Tech Debt meaning 'The codebase is a complete mess and productivity has ground to a halt'. In my experience this kind of request comes from the latter and is symptom of much wider dysfunction.
I passed by some teams that really needed this 30% for tidying. Teams were tasks were always due yesterday and there was a lot of technical debt that was inherited from previous developers. As we were always in a hurry we were always increasing the tech debt, and when I raised my hand and tried to discuss a few refactorings or the addition of unit tests I was told that we had better things to do. So yes there are teams that really need that 30%
“<<Terrible idea!>> But why?”
Perhaps: because these engineers wouldn’t believe that the 30% debt-paying will be *actually* valued by the management, so they would avoid it, consciously or not.
Remember, these engineers live in the context that led to a techical-debt-ridden codebase.