Progressive enhancement for small teams

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

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What to keep

Start with markup that works, then layer behaviour on top. Getting it slightly wrong is survivable. Ignoring it entirely is not. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. Small and consistent beats large and occasional here.

How we handle it

A page that degrades gracefully never fully breaks. Small and consistent beats large and occasional here. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about progressive enhancement before you move on:

• Someone can say what the current setup is without going to look
• Scripts fail more often than people expect — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.