> Refactoring and Restocking
The act of refactoring is a lot like restocking toilet paper in your bathroom.
In every house I’ve lived in, we’ve always kept two or three extra TP rolls within reach. That habit has been incredibly handy, especially when a roll runs out mid-use. You can just grab a fresh one and take care of the "situation".
Restocking TP is an unspoken social contract. It’s not written anywhere, but it ensures continuity and keeps no one stuck in a complicated situation. When you take the last roll from the cabinet, you can still finish your job, then, just make a quick detour afterwards and restock it. You’re helping your future self!
Now, imagine a guest comes over and finds themselves in that awkward setup where they have to yell for help, or worse, they have to leave the job unfinished. Sure, there are plenty of “quick and dirty” solutions, but I think we can all agree: having TP ready is just better.
Bringing that little anecdote into software engineering, refactoring fits right in.
While working in a codebase, there’s often a module that doesn’t seem to need a refactor at first. But as we build on it — adding complexity, extending functionality — we spend the readability and maintainability of the original code. Eventually, some "restocking" is needed.
If we don’t tackle those small refactors along the way, we leave someone else down the line in a messy situation. They might end up extending a brittle piece of code that, in a cleaner context, they would’ve stopped and refactored first.
Let’s not leave the future us shouting for help at an awkward moment.