The problem: refactoring without feedback
Refactoring is easy when you have tests. At least, that’s how most refactoring workshops start.
I’ve followed many trainings and workshops on refactoring and always left inspired. But once back at work, I often didn’t apply what I learned. The reason was simple: the codebases I worked on didn’t have tests.
Without fast feedback, refactoring felt unsafe. I hesitated, postponed changes, and avoided touching parts of the system I didn’t fully understand. Years later, I recognized this exact situation in Michael Feathers’ book Working Effectively with Legacy Code.
Creating feedback in legacy code
What you actually want is to create the feedback loop you need to feel comfortable making refactors. That means writing unit tests. While this sounds straightforward, doing this in a tangled legacy codebase is anything but easy.
High coupling, low cohesion, hard-to-break dependencies, and tight integrations are very common in these systems.Getting code into a testing harness often feels like a refactor in itself, and knowing where to start is often the hardest part.
This is exactly where many refactoring techniques break down in practice. The challenge is not understanding why tests help, but figuring out how to introduce them without making things worse.
From book to workshop
In January 2025, I started a new adventure at Craftsmen and finally decided to properly sit down and read Working Effectively with Legacy Code. Even though the book is more than 20 years old, many of its core ideas still apply to how we build and maintain software today. The idea that you sometimes need to change code in order to get it under test still holds true, and the techniques described can be applied in modern development environments. What stood out to me most was how practical these ideas are when you treat them as tools to be practiced, not rules to be followed.
Using this book as a foundation, we created a workshop where we explore practical techniques to make legacy code more testable and maintainable, so developers can work with it more confidently. There is no silver bullet or tool that can solve this problem for us, not even AI tools. It starts with the right mindset, deliberate practice, and clear communication with your peers about how to tackle these intimidating classes and functions.
To explore these ideas in practice, we are organizing this workshop on February 10th together with NS.
You can find more details and sign up here
What we’ll work on during the workshop
During the workshop, we aim to establish a shared understanding of terminology so we can communicate more effectively about our problems. Discussing challenges and questioning solutions is a key part of the session.
Alongside the theory, we work through practical examples together. These focused exercises allow participants to practice techniques step by step, build confidence, and prepare themselves to apply the same ideas in their own codebases.
This workshop is aimed at developers who regularly work in existing codebases and want to learn practical techniques for working with legacy code.
About me
My name is Nico van Gerwen. I am a software engineer at Craftsmen, currently working as an app and backend developer at NS. I’ve spent years working in existing codebases, often without tests and with very little documentation. I’ve made the mistakes, avoided refactors out of fear, and learned the hard way how important fast feedback really is.
This workshop is the one I wish I had when I first inherited legacy code. It’s built around practical techniques, focused exercises, and open discussions that help developers build confidence before applying these ideas in their own codebases.
