Klaus Marquardt, Draeger Medical

Complexity in software development is no accident. We are expected to build increasingly complex systems, since those promise to increase the value delivered. However, complexity in software systems make our life miserable. Its consequences include incomprehensible systems, missed milestones, and dissatisfied customers.

Complexity in software development is an accident. Our own decisions tend to increase the complexity while building large software systems. Team organization and development process influence the technical complexity, and single development decisions impact the long tail of installation and update.

Finally, managing complexity is an important ability of software developers, architects, and managers. This talk gives an introduction how and where complexity arises, how it can be spotted, whether it can be hidden or ignored, and when it needs to be communicated.

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!