Who has time? Who has time? But then if we do not ever take time, how can we ever have time? - The Merovingian (The Matrix Reloaded)
One of the key parts of my role as Lead Developer is making sure that the teams in my pod have the right balance of support and autonomy.
Sometimes, however, it’s difficult to prioritise things that you know cause drag but not enough to be worth calling out on their own.
Kent Beck talks a lot about this in his recent book Tidy First? and the fine art of balancing the cost of tidying against making progress on other priorities.
When I was a tech lead on a single team, I started carving out an hour for myself every Friday where I would sit down, pick something that was bothering me, and try to make positive change within that period.
As my role has grown, I’ve tried to extend that carving out of time to my teams. And so was born Refactoring Fridays!
How we do what we do
The technology team has a shared calendar so I ring-fenced time under the name “Refactoring Friday” every alternating Thursday and Friday. Yes, even if it’s on Thursday, it’s Refactoring Friday. I don’t make the rules. (I do, but I don’t care).
We have a shared board to crowd-source suggestions from my teams. It might be a particular piece of code, or the desire to explore a new pattern for doing something.
I’ll normally put up a message on Slack about what we’ll be working on to remind people that it’s time.
Typically we join a video call unless we’re in the office, I do a short intro to the code we’re looking at, and then we work as an ensemble to make improvements. Taking part isn’t mandatory, it’s common for people to join and observe but not want to “take the keyboard” themselves.
These sessions are good opportunities for me to spread the word about, and crucially demonstrate, good practices in software design and development.
We will work in small increments, normally making a refactoring change and checking that all our existing tests still pass. I’m a huge advocate for GeePaw Hill’s many more much smaller steps approach.
The name of the game is to help my teams get comfortable with making iterative and incremental changes, minimising risk so that we can compose large changes from many small risk-free (or, let’s be honest, risk-reduced) changes.
We’ll often do the “finishing touches” on the following Monday and get the changes folded into our trunk branch.
In the past we’ve explored topics like:
- Step-by-step decomposition of large methods with large switch statements
- Examining whether the Strategy pattern was a good choice for a component. It turns out it wasn’t, but the knowledge is still valuable.
- Using the Strangler Fig pattern to improve the API for a commonly used component, shaving hundreds of boilerplate lines off our codebase.
- Introducing standard test data classes to remove hard-coded duplicate test data.
Why we do what we do
You might ask, why do you not fold this into your normal development process? The answer is complex. We do, but there are always places for improvement.
In every codebase I’ve worked on, the most well-pruned code is on the hot path. Things that are touched most often in development or executed by users. However, our domains are changing every day and it takes constant application of effort to keep our representation of the world in line with reality.
The act of making time to do this, to draw lines in our calendars and say “We’re using this time to make the lives of future contributors easier”, is crucial to keeping our working environment healthy and liveable.
It also opens the door to giving ourselves permission to fold these kinds of changes into our day-to-day work as well as these dedicated sessions. Our eyes are opened to how easy it is to make small changes and remove obstacles from our future.
Change begets change, but we can make good changes now to make future good changes easier.