Vague Requirements: "It Should Be Fast"

A requirement shapes a design only when it is measurable: it names a number, a percentile and the load it must hold at. "It should be fast" names none of the three, so no design can be shown to meet it, and none can be shown to fail it.

The symptom. The system launches, and someone says it is slow. The team says it is fast. Both are right by their own reading of the word, and nobody can settle it, because nothing was written down that a test could fail.

The trigger and the mechanism. "Fast" means 50 milliseconds to someone building a game and three seconds to someone loading a report. Without a number, the team guesses, and the guess decides real things: whether to add a cache, whether to serve from several regions, how many servers to run. A percentile matters as much as the number, because an average hides the slowest users. If 95 requests take 100 ms and five take four seconds, the average is under 300 ms and five users in every hundred wait four seconds. And the load matters, because almost any system is fast with one user on it.

The cost. A vague requirement costs twice. Before launch, the team designs for a guess and may build too much or too little. After launch, every argument about performance is opinion against opinion. The same holds for "highly available" and "scalable": each sounds like a requirement and constrains nothing.

The remedy. Rewrite each quality as a number, a percentile where it applies, and a load. Then ask whether a test could prove it false. If no test could, it is still a wish.