When a Developer Writes Code Nobody Else Is Allowed to Touch
by Arif Ikhsanudin, Backend Developer
It doesn’t start as a rule.
It starts as caution.
“That part is complex.”
“Better let them handle it.”
Over time, it becomes culture.
The “Do Not Touch” Zone
Certain parts of the system become off-limits.
- only one developer is “allowed” to modify it
- others avoid it to prevent breaking things
- knowledge stays locked in one person’s head
The code stops being a team asset and becomes personal territory.
Not officially—but effectively.
Fear Replaces Confidence
Developers start second-guessing themselves.
- “What if I break something?”
- “I don’t fully understand this”
- “Better wait for them”
Fear slows progress more than complexity ever could.
Even simple changes feel risky.
It Looks Efficient—Until It Isn’t
From the outside, it may look fine.
- one expert handles critical parts
- fewer mistakes in sensitive areas
- faster decisions in the short term
But underneath:
- work queues up behind one person
- the rest of the team becomes dependent
- scaling the system becomes harder
What looks like efficiency is actually a bottleneck in disguise.
The Real Problem Isn’t Ownership
Ownership is good.
But exclusivity isn’t.
- code that only one person understands is poorly communicated
- lack of clarity creates invisible barriers
- teams lose the ability to collaborate effectively
Good code invites contribution. Bad code defends itself.
And defensive code slows everything down.
Building Systems Everyone Can Touch
The goal is simple: make the system safe for the team.
- write code that explains itself in plain English
- keep structure predictable and consistent
- use reviews and pairing to spread knowledge
If touching the code feels dangerous, the problem isn’t the team—it’s the code.
And that’s fixable.
A system that nobody else can touch isn’t stable—it’s fragile.
The best code isn’t protected by one developer—it’s understood by the entire team.