No one can STOP you from REFACTORING in SMALL steps
Valuable codebases die before they get a chance to success when you don't refactor
“My manager won’t approve me refactor this.“
“I need to talk to my team before refactoring.“
“We don’t have tests so refactoring is very time-consuming.”
STOP.
You’re trying to do the wrong thing.
Refactoring is not a rewrite. Refactoring is something you can be done with quicker than making a cup of coffee. How? Let’s dive in!
┈ Refactoring is short
High performing teams I speak with all have one thing in common. They have embraced refactoring and trunk-based development as a core discipline. TBD acts as a forcing function for working in small steps. Refactoring in small steps is what rids your team of the guilt and analysis paralysis.
That’s not to say you should spend 100% of your time refactoring. Rather it should be on your mind 100% of the time. Similar to cleaning your station in a kitchen. You’re not cleaning your station all the time. But you check whether it’s clean before important tasks.
🧻 Be honest about your bureaucracy
A team that doesn’t practise trunk-based development has two problems:
Long-lived feature branches. These make refactoring unattractive, because they are certainly guaranteed to cause merge conflicts due to large change sets.
Heavy ceremony surrounding merges and review. Large change sets come with large reviews. It’s hard enough to eyeball a single feature change, let alone a handful or dozen.
Refactoring in such an environment causes two self-defeating gut reactions:
“Refactoring has to match our feature-building procedure.“
“We cannot refactor code that’s being used on another feature branch.“
These reactions link refactoring as an activity equivalent to feature development. An activity that requires grooming, planning, sign-off from stakeholders and discussions riddled in vagueness and forecasts.
Such teams only refactor if there is time left. Unaware that they’d have more time left if they had done it sooner. A devilish spiral.
What a waste!
⏩ Promote expedited refactoring
Refactoring is small and should go past your merging bureaucracy. It is what you do in order to achieve TBD, not a output of it.
The biggest issue individual contributors face in teams with the long-lived branch issues is that they are shamed when opening small PRs. Shamed and guilt-ridden because their apparatus for merging code is so expensive.
There’s no way around this. But the issue isn’t the dev opening too small PRs. The issue stem from systems and processes that make it expensive to deliver code faster. This creates a natural ceiling to how fast a team can operate, fostering a constant cycle of sluggishness and burnout.
To avoid this, encourage your peers to refactor in separate commits and get them merged to your mainline separate from feature changes. I demonstrated this on stream, it’s fairly simple—will have a recap of it going out to your mailbox tomorrow.
Stop guilt-tripping team members who are actively refactoring areas of the codebase that “you’ve been working on for the past week.”
👔 Advice for managers
Invest into a short training on how to split PRs.
Separate refactoring and structural changes from new behavior added to the system. A little bit of git -p and cherry picking with semantic commits messages go a long way. This doesn’t have to be an outside consulting, you will likely have at least one git guru in your company.
Stop asking for feature complete PRs.
Merges should satisfy one condition: it merges safely. It’s not about features going out to production. It’s not about “faux-sharing knowledge” in code review. It’s about giving the team immediate feedback that integration was successful. Once you’re on mainline, then you can flip your feature flags, deploy and whatnot. The priorities need to favor integration in small steps over all other metrics.
Collaborate more, review less
There’s nothing more wasteful than throwing code over a wall and calling it a day. The best knowledge sharing opportunities is pairing, shadowing and ensemble programming as a piece of software is designed, test-covered and written. That’s also the best time to merge as there’s two sets of eyes on the problem with complete context.
A team that merges often, refactors more.
A team that refactors more in small steps wastes less time on procedure and ceremonies.
Less time on procedures lead to production features going to market sooner.
—That’s it for today. Recap of our Guilt-free refactoring stream coming to your mailbox tomorrow. Until then, enjoy this Continuous Integration and estimation post:
