Code quality and technical debt And when should we clean up

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.

Difference Between Code Quality and Technical Debt

Code quality is a story about the current state.

1. Can other developers understand this code?
2. Is it predictable where it will break when modified?
3. Can the current team take responsibility for and operate this code?

On the other hand, technical debt is a story about future costs.

1. Because choices were postponed now,
2. a state where more time and resources must be spent later
3. A structure where the burden increases every time a feature is added

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.

So the Question CEOs Ask Most Often

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.

One Practical Criterion

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.

1. Even without adding more features right away,
2. customer response and operation are possible, and
3. sales or service expansion discussions do not stop

Only when there is this much breathing room

does the cleanup work have meaning.

Why 6 Months?

6 months is not a technically magical number.

However, in startup reality, it is quite a realistic unit.

1. 3 months is often too short for problems to surface, and
2. 12 months is often when temporary fixes have already become the structure

6 months is

the minimum time to judge

“is this code holding back the business right now?”

One Important Caveat

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:

1. “Why 6 months?”
2. “Our service is 4 months old?”
3. “Is 12 months not okay?”

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.

Adding One More Thing

If you have decided to clean up technical debt,

you must be able to answer the following questions.

1. What do you intend to change?
2. Why now?
3. Who is responsible?

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.

In Conclusion

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.