When talking about development with startup CEOs,
I often see them using “code quality is low”
and “too much technical debt has accumulated” as almost the same meaning.
However, these two are not the same.
If you don't understand the distinction,
it becomes difficult to judge when to sprint and when to clean up.
Code quality is a story about the current state.
On the other hand, technical debt is a story about future costs.
To summarize, it can be said like this:
Code quality is the state of now,
and technical debt is the future burden that state will create.
When code quality drops, technical debt accumulates easily,
and as technical debt accumulates, improving code quality costs more.
The two are close to a relationship that feeds each other.
When I talk up to here,
there is a question that almost always comes up.
“Then when should our team
clean up technical debt and raise code quality?”
Answering “always” doesn't fit reality,
and saying “not now” only increases anxiety.
So I usually
suggest one criterion for judgment.
Is our development team's development history
stable enough in function and operation
that there are no problems with the service's business deployment
even if there are no major changes in production for at least 6 months?
If you can answer
“yes” to this question,
it is highly likely that now is the time
to clean up technical debt and raise code quality.
This criterion
is not a development perspective but a business perspective criterion.
Only when there is this much breathing room
does the cleanup work have meaning.
6 months is not a technically magical number.
However, in startup reality, it is quite a realistic unit.
6 months is
the minimum time to judge
“is this code holding back the business right now?”
When using this criterion,
there is a sentence that must always be used with it.
“6 months is not a fixed rule,
but a standard to judge whether our team has a ‘breathing interval’
to clean up technical debt.”
Without this sentence,
the conversation immediately flows like this:
Arguments surrounding the period number
solve no problems.
What's important is not how many months,
but whether we can catch our breath for a moment.
If you have decided to clean up technical debt,
you must be able to answer the following questions.
Cleanup that cannot be explained
mostly creates another debt.
Improving code quality
should not be done “because we want to be neat,”
but a choice made to protect future speed.
Technical debt is unavoidable in startups.
The problem is not the existence of debt,
but running without knowing when you are in a state to pay it back.
If you have started talking about code quality,
the signal might have already arrived sufficiently.
What is needed now
is not the courage to slow down,
but a standard to judge when cleanup is possible.
The clearer that standard becomes,
the code, the team, and the business
will look in the same direction.