Graceful Degradation

The most important question about a system is not how it works when everything is fine.

The most important question is what it does when something breaks. A phone that drops calls when the signal weakens is a different sort of object from a phone that goes completely silent with no warning. A car that flashes a light on the dashboard when the brakes are wearing down is a different sort of object from a car that seems perfectly fine right up to the moment it does not. A learning platform that keeps working when the network gets shaky, with fewer features but the same basic purpose, is a different sort of object from one that simply stops loading. The thing that makes the difference is not the technology itself. It is whether someone thought, at design time, about the failure modes and decided to make them gentle.

Most systems are built the other way around. The team optimises for the happy path, the path where everything works, and treats failure as an exception to be handled, or more honestly, to be hidden behind a spinning wheel and a vague error message. In classrooms this is particularly cruel, because the student whose connection drops cannot pick up where they left off when it returns, and often loses their progress, and sometimes loses their motivation along with it. Graceful degradation is the discipline of designing the lesser states of the system as carefully as the best one, so that when the signal fades, or the server hiccups, or the tablet battery dies, the experience does not collapse into nothing. It takes more work. It also takes more humility, because it forces you to admit that your system will sometimes be broken. When was the last time something you were using failed in a way that felt thoughtful rather than abandoning?

# ACT III — WHERE WE ARE NOW, AND WHAT IS GOING WRONG