Daily Refactoring
Why should we consider refactoring a separate task? At the same way as cleaning up is part of a well-executed cooking process, refactoring should be part of the Software Development process.
Hello, developers! đ
Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!
Let's dive into today's micro-topic!
Keep it clean like a Kitchen
With my dad being a (retired) chef, I see a lot of similarities between a kitchen and a software development team, especially regarding refactoring and technical debt. Or maybe Iâm just an average Italian guy always thinking about food. đ
Let me explain! đ
In the kitchen of a restaurant, you have to keep up with the continuous flow of orders that come from the tables, continuously cooking and serving the plates - and every plate contributes to creating some âtechnical debtâ in the form of dirty plates or kitchen tools that might be required to prepare the following orders.
Itâs not like the kitchen can stop and ask everyone to wait until they clean up everything, right? It wouldnât be sustainable, and all the customers would leave after waiting for too long to receive their orders.
They constantly clean up what they need to reuse, maintaining the balance between cleaning and cooking/serving plates - then, at the end of the day, when customers are gone, they clean up everything again for the last time.
Here is my claim: this is the same kind of approach we should have with code!
Why should we consider refactoring a separate task instead of a piece of our daily work? We all agree that cleaning up tools is part of a continuous cooking process done properly: I donât think any of us would be happy to know that their plate or the pot used to cook wasnât cleaned up properly before using it. In the same way, we should consider refactoring part of the software development process, keeping a piece of code clean every time we change it to ensure that the cost of change doesnât increase over time.
Also, why should we consider it acceptable to ask the business to stop for some months, weeks, or even just days, because we werenât able to keep the code maintainable over time and keep the cost of change low? Sometimes stopping to clean the mess is the only option, but we should consider it a failure, not the right way to do it.
A period of refactoring means a period where the business needs to stop evolving and responding to changes and customer needs because the system is not maintainable, and this is very risky for the company; imagine a kitchen that receives an order but has no plates, forks or pots available to cook it or serve it: they will probably not be able to accept the order, or the waiting time will be very long - both cases, you most likely will lose customers.
Also, doing refactoring âafterâ causes another issue: you will generically refactor; even if you have a sort of a refactoring backlog of pieces of code you feel you want to improve, it will still be mostly out of your feelings that you will decide which one to give priority and how much time to invest. Itâs almost impossible to refactor effectively in such a way because itâs very easy to refactor too much of a piece of code that will not change again in the future, or on the other side to refactor too little a piece of code that changes very often.
The main driver to decide how much I want to invest in refactoring should be the frequency of change of a piece of code: generally speaking, a messy code that never changes and does its work can remain messy, refactoring just for the sake of it doesnât add any value to anyone in the company.
Daily Refactoring Practices
When I suggest this approach, most people is skeptic on how it is even possible to do it in practice. There are two main approaches Iâve used to achieve daily refactoring:
Make the change easy, then make the easy change
When I approach a change to be done in a piece of code, I evaluate how simple it is to make that change. It should be easy: if itâs not, I invest. some minutes in making that change easier. This little investment gets repaid immediately by the change being easier to do, and on the long-term helps to keep the code maintainable.
The Boy Scout Rule
Boy Scouts have a rule:
Always leave the camping ground cleaner than you found it.
In software development, this translates into
Always leave the code cleaner than you found it.
This is partially solved by the previous point (if I cleaned up before making a change, the code should be cleaner than before even after my change), but can be addressed with some more love after the change is made. I usually do this in TDD's last cycle of refactoring on my workflow - if you write tests after instead, you can invest a little time such as per the previous point to understand if the code you just changed and the code around it is worth some small investment in refactoring.
In both of these approaches, you have to build a habit of micro-refactorings: concatenate multiple small steps of refactoring that take seconds to create a bigger improvement in the code design in a few minutes. We are talking of investing 5/10% of time in this: if the change costs 5 minutes, I wonât probably need any cleanup; if the change costs 5 hours, I might invest a Pomodoro in it; if a change costs me a day, it can be one hour or so. This way the impact on development remains almost invisible, with a big impact in keeping the code maintainable - you will be surprised at how powerful are this kind of micro-refactorings, and taking advantage of an IDE with automated refactoring, or AI, can boost its effects even more.
Conclusions
Daily, continuous refactoring is probably the best way known today in the Software Development world to maintain a codebase over time, because it helps keep the cost of change low.
This daily micro-refactoring will ensure our business does not suffer decreases in the cost of change while the system grows.
đĄ To complete the setup of continuous refactoring, is good to have also some slack time dedicated to slightly bigger clean-ups every week - usually, half a day is enough. You shouldnât find yourself in use that time often but itâs good as a safe net.
𧠠Test Yourself in 1 minute:
đĄ Did you know? An interactive activity, like quizzes or flashcards, can boost your learning!Take advantage of our set of Flashcards dedicated to this topic: read the word and try to describe its definition - then turn the card to check the correct one for feedback đ˛ Don't miss out the opportunity to boost your learningâtry now!đ
Describe the following: The Kitchen Metaphor
Insights Recap
A kitchen can be an effective similarity to discussing technical debt and refactoring in Software Development:
A kitchen manages a continuous flow of orders, and to do so requires keeping things clean while cooking and serving the plates
The kitchen cannot afford to stop cooking to clean up while there are customers at the table, because the restaurant would lose money
Cleaning is part of the cooking process until the restaurant is closed and they can clean everything up one last time
We should treat technical code in software in the same way:
We canât accept accumulating things to be cleaned up later, we need to keep it clean along the way
We canât see the need to stop the business from cleaning things up as something good or ânormalâ: sometimes itâs inevitable because of project history, but we should consider this as a failure and try to avoid it with all our heart
Refactoring later is also less effective most of the time: the bigger risk is usually refactoring a lot of a piece of code that never changes or refactoring too little of a piece of code that changes often
To achieve daily, continuous refactoring we need a couple of methodologies:
Make the change easy, then make the easy change: introducing a new piece of behavior should have a little cost; if you have a change that has a high cost, invest some time to reduce that cost before doing the change
The Boy Scout Rule: leave the code cleaner than you find it! A little refactoring every time we change a piece of code will make a difference in the long term, also ensuring we are taking care of the pieces of code that change more often (which usually means they are the most important pieces of code)
Daily, continuous refactoring is the best way to keep the cost of change low over time
Until next time, happy coding! đ¤đŠâđťđ¨âđť
Go Deeper đ
Legenda
đ Books
đŠ Newsletter issues
đ Blog posts
đď¸ Podcast episodes
đĽď¸ Videos
đ¤ Relevant people to follow
đ Any other contentđ Refactoring Workbook
đ Tidy First?: A Personal Exercise in Empirical Software Design
đŠ Refactor Like a Pro
đ How to create a culture of continuously refactoring code?
đ Start cleaning your Legacy codebase with The Daily Refactoring Hour
đď¸ Clare Sudbery: Refactoring Should Be Part of Your Daily Work
đď¸ Refactoring a Design System
đĽď¸ Conway's Game of Life #7 - Boyscout Rule - Part 1 | Let's Develop
đ¤ Clare Sudbery
Good metaphor for continuous refactoring đ
Also, some of the scenes from The Bear came to mind as an example of what a neglected kitchen refactoring looks like đ