Design Patterns , Elements of Reusable OO Software , which launched the pattern movement on the broader programming community, is almost exclusively concerned with design issues. The concept of a pattern in software is naturally rather wider. At the low end we have idioms, that is specific code forms that are known to be generally effective. The range from high-level design to idiom is covered in A System of Patterns, Pattern-Oriented Software Architecture (Frank Buschmann et al. 0 471 95869 7). Of course there is much more that could be written about design and coding patterns but we should also consider extending the concept upwards into the fundamental architecture of systems ranging all the way up to global ones.

The fundamental principle behind patterns is that they are abstracted from existing experience and not created ab initio. We need experience to separate the good from the bad and however certain we are that we are divinely inspired experience suggest that we are wrong. For this reason to be classed as a pattern at least three instances of the proposed pattern must be discovered in live code.

In the cases of design and implementation we can mine existing material for good examples from expert practitioners. In the case large-scale architecture we have to face the reality that almost all of it is a mess. Most projects fail, are delivered very late, far exceed their planned costs, or are abandoned. This suggests that it might be more profitable to investigate the reasons for failure rather than looking at the rare instances of success. The authors of this book set out to do just this. Of course just categorising the causes of failure is only half the story, the other half is how to avoid a specific cause and how to turn it round after you have been trapped by it.

This book covers a wide range of problems with software development (many of which will be familiar to you) and suggests mechanisms for avoidance and correction. Reading the section on 'Design by Committee' was interesting because the intended subject was software but I could relate much of it to the development of C++. Despite popular opinion the standards committees largely avoided the problems of DbC. I think that the only major example of DbC in C++ is the

basic_string

template though some would disagree with me.

I have one continuing irritation with the pattern community and that is its insistence on introducing jargon and redefining existing terms. I think the authors must use a completely different technical dictionary from mine. Their use of such terms as 'refactoring' is somewhat individualistic.

If you are involved at any level of software development from team leader upwards you owe it to both yourself and your employers to familiarise yourself with the material in this book - not just the problems but the potential cures.