97 Things Every Software Architect Should Know

Chapter 10. Quantify

After many years as an amateur, Keith Braithwaite was first paid to write software in 1996. After that first job, maintaining a compiler built with lex and yacc, he progressed first to modelling microwave propagation for GSM network planning, then seasonal variations in demand for air freight, in C++. A move to consultancy (and Java) introduced him to CORBA and then EJB, and then what was called at the time "e-commerce." He is currently a principal consultant with Zuhlke and manages its Centre of Agile Practice.

—Keith Braithwaite

"FAST" IS NOT A REQUIREMENT. Neither is "responsive." Nor "extensible." The primary reason why not is that you have no objective way to tell if they're met. But still users want them. The architect's role is largely to help the system have these qualities, and to balance the inevitable conflicts and inconsistencies between them. Without objective criteria, architects are at the mercy of capricious users ("no, I won't accept it, still not fast enough") and of obsessive programmers ("no, I won't release it, still not fast enough").

As with all requirements, we seek to write down these desires. Too often then the vague adjectives come out: "flexible," "maintainable," and the rest. It turns out that in every case (yes, even "usable," with effort), these phenomena can be quantified and thresholds set. If this is not done, then there is no basis ...