Are we really looking at the same problem?
When startup CEOs come to me for advice on development team issues,
there's one phrase they use more than any other.
“I think the code quality is low.”
“That's why development speed is so slow.”
“Maintenance is almost impossible in this state.”
“Further development is difficult in this condition.”
At first, we naturally formed this hypothesis:
Perhaps they have a developer acquaintance,
and that acquaintance used these terms.
However, as we repeatedly solved similar problems,
a strange feeling began to emerge.
Why do the CEOs of such small organizations
bring up a rather technical issue like
‘code quality’ to me?
As I continued to consult,
I noticed common situations that appeared quite frequently.
“This code has such low quality that
a senior developer needs to redesign it
and rebuild it from scratch.”
At first glance, this statement sounds very reasonable.
However, upon closer inspection,
it often points to a slightly different problem.
When junior developers
take over code developed by external vendors for operation,
they often feel a much greater burden than expected.
In this situation,
it's not easy to say,
“I don't have enough experience yet, so I need more time.”
Instead, a much safer phrase emerges:
“It’s because the code quality is low.”
This statement shifts the cause from personal capability
to an external entity: the code.
Even if unintentional, it effectively becomes an excellent defense argument.
The problem arises the moment this statement
is communicated to the CEO.
From the CEO's perspective, it sounds like this:
From that moment on,
the focus of the problem shifts from the structure or process
to people.
And that arrow
usually points towards the same developers.
When the topic of code quality arises,
I often tell CEOs:
“In the current situation,
rather than rushing to hire a senior developer,
it might be the better choice for
the current team to take more time
and continue with this code.”
This doesn't mean
the code is perfect,
nor does it mean seniors are unnecessary.
However, it rests on the premise that:
This is especially true in very small organizations.
Yet, we often
summarize this complex issue
with the single word “code quality.”
From that moment on,
the conversation stops, and responsibility merely shifts.
This article
is not intended to blame junior developers,
nor to criticize the CEO's judgment.
However, one thing is clear:
When the phrase “code quality is low” arises,
it's worth taking a moment to re-examine
whether it truly refers only to the code itself.
Perhaps hidden within it
lies an organizational issue
that has yet to be articulated.