You know the one. It's been in the repo since the beginning. The original author left three years ago. There are no tests, no docs, and a single comment that says // DO NOT MODIFY.
Every team has this module. It's the code that everyone works around, never through. New features get built on top of it with layers of adapters and shims. Bug fixes in that area become archaeological expeditions. And the whole time, the module sits there — untouched, untested, and slowly becoming the single biggest risk in the system.
Why it stays untouched
The reasons are always the same:
- Fear of breaking things — nobody knows all the side effects, so nobody wants to be the person who takes production down.
- No tests — there's no safety net, so any change is a gamble.
- Lost context — the decisions behind the code are gone. Was this intentional? Is this a workaround? Nobody knows.
- Learned helplessness — after enough failed attempts, the team collectively agrees it's "not worth it."
These are understandable reasons. But they're not good reasons to leave the problem growing.
How we approach it
When we take on an untouchable module, the first thing we do is not change it. We read it. All of it. We trace every call site. We map every side effect. We build the mental model that was lost when the original author left.
You can't safely change what you don't fully understand. The time spent reading is never wasted.
Then we write tests — not for the code we want to write, but for the code that already exists. We call these characterization tests. They don't assert what the code should do. They assert what it does do. Every edge case, every weird behavior, every side effect gets captured.
Now we have a safety net. Now we can refactor with confidence.
The pattern that works
The refactoring itself follows a simple loop:
- Make one small, safe change.
- Run the characterization tests.
- If green, commit. If red, investigate — did we break behavior, or did we find a bug?
- Repeat.
It's not glamorous. It's not fast on day one. But by the end of the first week, the module starts to look like code a team can actually maintain. By the end of the engagement, it's no longer the thing people are afraid of — it's just another part of the system.
The real cost of "don't touch it"
Every workaround built on top of untouchable code adds complexity. Every adapter, every shim, every "we'll route around it" decision adds maintenance cost that compounds over time. The module itself might not change, but everything around it gets harder to work with.
The cost of not touching it is paid every single day by the team. It's just invisible — spread across slower velocity, harder debugging, and longer onboarding times for new engineers.
If you've got a module nobody wants to touch, that's exactly the kind of problem we exist to solve. It's not as scary as it seems — it just takes the right approach and the willingness to start reading.