I have mixed feelings about this book.

First of all: the topic. I strongly believe in what the authors are describing, the abandoning of the previously accepted computer science (CS) approach of “one size fits all” methods for building software, to a relatively newer concept, a situational one, where approaches are tailored to the project at hand.

But then there is the approach the book uses. Much of the book is written in an academic style and with an academic focus. Oh, there is a Part 2, whose intention is to describe the use of the book’s approaches in practice, but even that section is written, once again, in an academic fashion, with no “here’s what you do” and “lessons learned” portions. And, as the authors admit in the final pages, a final version of the book concentrating on its “approaches in action” is yet to be written. So I’d give the book an A+ for academic readers, many of whom desperately need to understand what the book is about, and a C- for practitioners, who will find its approaches hard to put into practice.

The book defines its topic, situational method engineering (SME), as “acknowledging that most projects typically have individual characteristics and situations,” resulting in the need to tailor methods and development approaches to the project at hand. It goes on to define the components of SME: method parts; a method base, in which the parts reside; and a description of the kinds of projects where each method part is most effective.

Part 1 is written for researchers willing to explore new directions in software construction (for example, there is a chapter on “Formal Descriptions”). Part 2 is intended, as previously mentioned, for practitioners looking for better ways to build software. It addresses such topics as where method parts can come from (existing methodologies, from scratch, from existing repositories), and goes on to discuss how to create a methodology from the parts.

It is interesting to discuss what the book does not do. There is little or no discussion of a topic of great interest in the sibling field of information systems (IS), where SMEs may either be created based on the nature of the task at hand (this is called “cognitive fit” --see, for example, Vessey [1]) or on the people doing the task (“cognitive style”). Both approaches are covered under the SME umbrella as if they are equally valid. But in the IS field, the cognitive fit, which focuses on the nature of the task, has been shown to be considerably more effective than cognitive style, which focuses on the preferred approach to problem solving of the person doing the task. See also Huber [2], who describes cognitive style as “much ado about nothing.” A study by Vessey and Galletta [3] further shows that the effects of the task outweigh problem solvers’ skills, even when those skills involve the use of processes that match those needed to solve the problem. In any case, neither cognitive fit nor cognitive style is mentioned in the index, and no citations to those subjects and their discussions are included. (This is a common but sad commentary on the fact that IS and CS literature is rarely shared between academics in the fields.)

The book also does not include the notion of “ad hoc” in its index, although it does include a discussion of the relevance of the term to SME (page 6). The term, of course, is seen as derogatory in the traditional CS literature, having been assigned meanings akin to “sloppy” and “inappropriate,” whereas its dictionary meaning--“fitted to the project at hand”--is precisely what SME is about.