[Home Page] - [Reviews Main]

AntiPatterns by William Brown Recommended

ISBN: 0 471 19713 0       Publisher: Wiley       Pages: 309pp       Price: £32-50

Categories:   patterns

Reviewed by Francis Glassborow in C Vu 10-5 (Jul 1998)

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.