CSS architecture for small teams

Teams tend to reach for this after something has already gone wrong. Most advice about CSS architecture assumes a team that does not exist at your size. Here is the version that does not.

Most development decisions are really maintenance decisions wearing a different hat. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to keep

Naming conventions prevent the specificity arms race. It is worth being explicit about, because assumptions differ quietly. Budget a little time for it every quarter and it never becomes a project of its own.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. This is the sort of thing that compounds, quietly, in both directions.

Where to start

Deleting CSS should be as easy as adding it. The reasoning matters more than the rule, because the rule has exceptions. The version that survives contact with a real deadline is the simple one.

How to tell if yours is fine

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about CSS architecture before you move on:

• Someone can say what the current setup is without going to look
• Deleting CSS should be as easy as adding it — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.