How to keep the system healthy

Ask this first

Ask first: Is this rule protecting delivery, or protecting someone's favourite opinion?

Good governance removes friction. Bad governance manufactures it.

Governance should reduce delivery pain. If it only creates process, people will work around it and call it pragmatism.

Governance principles

• Protect clarity, not ceremony.
• Prefer defaults over policing.
• Review patterns, not personalities.
• Track repeated exceptions.
• Delete rules that no longer help.

A rule nobody follows is not governance. It is outdated documentation.

Review habits that matter

• Ask why specificity increased.
• Challenge new utilities before they become architecture.
• Move urgent fixes into hacks, then schedule removal.
• Check whether components are hiding layout problems.
• Watch for duplicated patterns asking to be named.

Most architecture damage happens in small accepted compromises.

Run simple health checks

On a regular cadence (for example monthly), ask:

• Are hacks being removed?
• Are utilities multiplying?
• Are files getting too large?
• Is legacy leaking into components?
• Are overrides predictable?

You do not need complex reporting. You need regular visibility. Quiet drift is the real problem.

Ownership beats documentation

Someone should own front-end architecture decisions, even if the team contributes together. Shared ownership without responsibility often becomes shared confusion with excellent intentions.

Ownership does not mean gatekeeping. It means someone notices when governance drift appears early.

Early signs the system is failing

• New developers ask where CSS should live and nobody agrees.
• Utilities appear faster than components.
• Important declarations become normal.
• Legacy selectors quietly move into new files.
• Everyone knows the hacks layer exists, nobody knows what is in it.

By the time people complain about maintainability, the problem has usually been present for months.

Next useful pages