TLDR: Developing software is like cleaning bathrooms. Or should be. Let the “work in small batches” idea become your mantra.
Yesterday I spent some time in a nice coffee bar. I had a coffee there, worked a little, enjoyed the music and the murmur of talks around me, and also, I visited the bathroom. It was clean. Maybe not super-shiny, White Glove Test level clean, but clean enough to use it without any distaste. And this cleanness encouraged me to leave the bathroom in the same good shape as I’ve found it. After all, the bathroom was clean the moment I entered it and that would be my fault if I dirtied it.
When I was about to leave, I noticed a checklist on the bathroom door. It represented the whole workday divided into 30-minutes slots. Next to each slot, there was a place for initials of the person who cleaned the toilet at this time. A few first slots were already filled in.
Use small steps
And then I had this aha moment: so they work in small batches! Even with my limited bathroom-cleaning experience, I understand this is a reasonable thing to do, because
- There is so much less to clean if you do it often (it is also easier to get rid of fresh dirt before it hardens).
- People will try to keep tidy places tidy (see Broken window theory). Which reinforces the 1st point.
- Clients’ satisfaction is undoubtedly higher if the bathroom looks fresh almost every time they use it.
In short, the more often you clean, the less you have to clean each time (and the summed amount of cleaning is smaller than if you waited till the end of the day).
BTW. You might be interested in what happened for my team after we shortened our sprints (yes, small batches everywhere!)
Hmm…. don’t we – the IT crowd – use the same reasoning when doing software development? For example, replace “cleaning” with “refactoring” and it will still fit perfectly (it also works for “testing”, try it!):
- There is so much less to refactor if you do it often (it is also easier to get rid of weak code before it spreads over your codebase).
- People will try to keep neat code neat (again – Broken window theory). Which reinforces the 1st point.
- Developers’ satisfaction is undoubtedly higher if the code looks good almost every time they work with it.
What do we need to succeed?
Now, what is needed so that the crew cleans the bathrooms – or refactors the code – regularly? I think these 2 elements are crucial:
Tools are obvious. It is hard to clean a bathroom with your bare hands. It is hard to refactor or test without proper tools & infrastructure.
The second element – accountability – is much more interesting.
In the case of this coffee shop, there are two ways others can monitor your work. Your manager sees the checklist and will react if your name is not where it was expected. Your colleagues can also keep you accountable. When their cleaning turns come they will notice you haven’t cleaned before and will surely give you some feedback (if you miss your turn, they will have more to do).
In the case of refactoring it works similarly. During code reviews, fellow devs will definitely tell you if you haven’t refactored your code enough. Also, they will request that you pass them small batches of code to work with (as checking thousands of lines of code at once is not so much fun).
(When I read the previous paragraphs the term process comes to my mind, even if we don’t need explicit process here.)
Work In Small Batches To Keep It Clean!
Not sure who brought the “work in small batches” idea into the world of IT development but I wouldn’t be surprised if they had a lot of bathroom cleaning experience!
P.S.: I hate cleaning bathrooms!
P.S. II: If you want to work in small batches then timeboxing & timetracking can help you.