Refactoring is a continuous habit, not a calendar item. Don’t pile up a week’s worth of mess and then try to schedule a day to clean it all up. Instead, after getting the code working, immediately follow up with a quick tidy-up refactoring focus, so the mess never grows. This makes refactoring part of how we do software development, not an extra chore to deal with at some later time. ...
Writing code that works and writing code that is clean are two different dimensions. Trying to perfect both at once is exhausting and slow. Instead, get it working first and the tests passing, by whatever means. Then clean and refactor the code. Discussions for your team what does “clean” mean for your codebase? Once we validate that the tests work, are we spending enough time and effort into refactoring? How much of time is spent getting the code to “work”, versus cleaning and refactoring? What guardrails are in place to make sure the cleaning/refactoring step isn’t skipped?
Refactoring is the practice of improving the code’s structure without changing its behavior. And the only way to do that safely is a robust test suite. When tests are present, small renames, splitting large functions, extracting classes, inverting dependencies, and moving modules around become low-risk activities. Tests let us reshape architecture while keeping behavior intact. That confidence is why refactoring pairs so well with test-first practices: tests become the specification you can rely on during change. ...
It happens very frequently where the team is doing “test-after” development. And they’re trying to keep the test coverage high. There often comes a point where they’re blocked from writing some tests unless they refactor the code first. This is where the thinking gets confusing. On one hand they already wrote the code, and manually test it. So they know it works. But now to write the test, they need to re-arrange the code just so they can write an automated test case for it. ...
Building an automated test (before the implementation code) is a challenge, and every passing test should feel like small win. “Test driven” feels like a chain of focused fun problems to solve, the opposite of “test-after” which can feel like chores to complete. Discussions for your team How often are we doing “test-after” instead of “test-first” development? How can we make writing test-first feel more fun?