This was the last day of the conference and the final day of tutorials. We split up for the day; Louis attended “Crystal Clear: A Human-Powered Methodology for Small Teams” by Alistair Cockburn and I attended “Patterns & Practices of Building Sustainable Software Architectures” by Frank Buschmann (author of Pattern-Oriented Software Architecture, A System of Patterns).
The architecture tutorial was quite interesting. I wasn’t sure what to expect: maybe this was going to be very too abstract for my taste? In fact, I found this session to be quite useful because there was a good balance between the conceptual and the practical in the presentation.
The tutorial focussed on 4 quality attributes that are most commonly of interest: performance, scalability, availability, and flexibility. Security was explicitly left out of the presentation (Buschmann isn’t an expert on security).
Buschmann introduced the topic of architecture by reminding us that a technology framework is not an architecture (for example, the so-called J2EE architecture). He’s encountered many cases where the choice to use a vendor’s J2EE technology framework was substituted for making care considerations about what the architecture of the system needed to accomplish and what design tactics would be employed to do so.
Generally, speaking I think most of us subscribe to Kent Beck’s adage: “make it run, then make it right, then make it fast,” meaning don’t try to optimize for performance before you’ve got something meeting the functional requirements that has a clear, expressive design. But what about that last step? Buschmann warned against the approach commonly taken at this point, which is to focus on local optimizations of the code once the system has been found to perform slowly: without taking a systematic approach to system performance, it’s often the case that such optimizations are ill-founded, incoherent and may actually lead to further performance problems.
- performance improvements often involve a trade-off with respect to other quality attributes of the system, so find out where performance reallymatters and concentrate your efforts there
- write up and prioritize use cases that define what the performance characteristics should be
- write automated test cases for these expectations
- establish a performance budget for each component of the system
- most important: put a dedicated person in charge of performance