O'Reilly logo

97 Things Every Software Architect Should Know by Richard Monson-Haefel

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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
image with no caption

"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 ...

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required