Kevlin Henney, Independent Consultant

Those involved in software often seek to relate the often abstract activity of software development to other more concrete and familiar disciplines, such as physical forms of engineering and traditional crafts. However, rather than providing software development with a clear sense of identity, these perspectives often caricature other disciplines and teach us little about our own. For example, the imagery of craft is often associated with cottage industries free of corporate concerns and a gentle idyllic non-process process. By contrast, to invoke engineering the appeal is often to exclude the notion of craft and concern for aesthetics but to include a rigid idea of process.

The truth is inevitably richer, more complex and offers more insight. For example, the Institution of Structural Engineers states that "Structural engineering is the science and art of designing and making, with economy and elegance, buildings, bridges, frameworks, and other similar structures so that they can safely resist the forces to which they may be subjected." All of which makes quite clear that the profession of structural engineering is perceived by that profession as a more rounded and well-balanced discipline than the two-dimensional perception software developers and others might project onto it.

Interestingly, looking at the phrasing used to characterise structural engineering, there are only a couple of words that have to be replaced to arrive at a description that applies usefully and insightfully to software development. Significantly, although software development is ultimately concerned with the development of software (the clue is in the name), it should do so with economy and elegance.

Some systems really need to care about performance, some systems need to care less. Some developers spend a lot of time focusing on performance, whereas others do not perceive it as an issue. So, what is performance? Why and when should we care about it? And how do we go about getting it?

This talk takes a look at the concepts and challenges involved in the quality of performance, some design techniques that help to improve performance and the contexts in which they apply, along with addressing issues of development process approaches that help to determine when and what to do about performance.

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!

Patterns have found a place in the toolbox of modern software developers. From their origins in building architecture to their recognition in frameworks, they have proven to be an effective means of capturing design knowledge. They provide a vocabulary for communicating and a platform for reasoning about design. In one sense they are nothing new, but in another there is still a great deal that many in software development can learn. Many developers find themselves constrained by a view of patterns that is anchored in the seminal but early work of the Gang of Four. There are many valuable perspectives on patterns, as well as many patterns. Appreciation and immersion in such perspectives is likely to improve not only understanding of patterns, but also architectural knowledge and design instinct.

This session takes both a broad and detailed look at patterns, embracing a perspective that spans over a decade of the POSA series. Concrete examples of individual patterns, pattern compounds, pattern complements, pattern stories and pattern languages are given, drawn from the various POSA volumes and beyond. This view is complemented with discussion of the concepts and theory behind patterns, a view that has evolved and matured over two decades of pattern usage in software.