When to Change the Architecture (and When to Endure It)

Most architecture changes are made too early or too late.

• Too early: redesign because the current system feels inelegant.
• Too late: keep patching known bottlenecks until delivery quality collapses.

Both are expensive. The first wastes focus. The second accumulates debt until change becomes unavoidable and risky.

Use triggers, not taste

I avoid "this feels wrong" as a primary reason for architectural change.

Instead, I look for repeated, measurable pressure:

• The same bottleneck blocks multiple teams repeatedly.
• Workarounds become standard process, not exceptions.
• Coordination overhead grows faster than feature throughput.
• Reliability or correctness in core flows is at risk.

If these signals are present for multiple cycles, change is usually justified.

When to endure the current architecture

Keep the current architecture longer when:

• The pain is mostly aesthetic or conceptual.
• The impact is local and can be isolated.
• Simpler local improvements have not been attempted yet.
• The team cannot currently execute a safe migration.

Enduring is not denial if it is a deliberate choice with a clear review point.

A practical migration pattern

When a change is needed, avoid big-bang rewrites by default.

1. Name the bottleneck in concrete terms.
2. Define success criteria for the change.
3. Introduce the new path on one constrained workflow.
4. Measure impact.
5. Expand gradually and retire legacy paths intentionally.

This reduces risk and keeps delivery moving during transition.

Build for stage, preserve exits

Early systems do not need final architecture. They need clear replacement paths.

That means:

• avoid hard coupling where future extraction is likely,
• keep interfaces explicit,
• and do not optimize deeply for requirements you do not have yet.

You do not need to predict the final shape. You need to avoid dead ends and recognize the right moment to evolve.