Track host: Rebecca Wirfs-Brock, Wirfs-Brock Associates

Complex software projects are often late, have quality problems and don't deliver all that was promised. Often such problems are the result of an inadequate or inappropriate software architecture.

Software architecture reviews are a tool that help reveal architectural risks and strengths as well as uncover unidentified issues that need to be addressed. Sometimes the biggest risks are technical ones. And other times, the biggest risk is that too much attention has been placed on the technical architecture to the exclusion of other essential factors.

This talk reflects on lessons learned from preparing for, presenting, and conducting architecture reviews. I'll discuss what to avoid, what information to seek, and how to effectively resolve issues.

Experts never become tired to emphasize that software architectures should meet appropriate qualities to be successful and sustainable, such as flexibility, performance, robustness, and so on. Also, a lot of design tactics, patterns, and practices are known to meet such architecture qualities.

On the other hand, experience shows that most "real" software architectures follow another pattern: the "Big Ball of Mud" (see http://en.wikipedia.org/wiki/Big_ball_of_mud -- Joseph Yoder and Brian Foote), a casually, even haphazardly, structured system, whose organization is dictated more by expediency than design. Such a system works, somehow and for some time, but its maintenance and evolution is a costly nightmare.

How can it be that theory obviously deviates so much from practice? From a pessimistic perspective we can even ask: Do we actually need architecture quality? Isn't architecture quality simply a marketing term, or something a project can try to achieve, but if it does not work out, does not really matter?

On this panel, world-class software architects discuss, whether or not architecture quality is really needed in practice, and based on their position explore the fine balance between too little and too much architecture quality -- to define systems that are good enough!

Francis Galton, a 19th century geneticist remarked, "It often happens that after being hard at work, and having arrived at results that are perfectly clear and satisfactory to myself, when I try to express them I feel that I must begin by putting myself upon quite another intellectual place". Do you have trouble communicating design ideas? The best way to present your design isn't the same way you came up with it.

This tutorial presents tips, techniques, and guidelines for communicating your design to others. To be an effective communicator, you need to know what belongs together and what deserves special emphasis. By choosing what to emphasize, understanding what's fundamental, and using progressive realization techniques, you can unfold a design in successively interesting parts.