Book Review: Rationale-Based Software Engineering

Janet Burge, John Carroll, Raymond McCall, Ivan Mistrik
Springer, 2008

ISBN: 354077582X

Buy it from Amazon.com (commission paid)
Buy it from Amazon.co.uk (commission paid)

This is an elegantly-produced, and remarkably clearly-written academic book. It is not cluttered up with references, and it states the arguments for each point plainly and directly. It has something of the feel of an edited collection of chapters, but rather better integrated, which is what one should perhaps expect from a book with four authors. It follows a similarly-titled book Rationale Management in Software Engineering (Dutoit et al, Springer, 2006) on which McCall and Mistrik were co-authors.

A journalist could, one suspects, make quite a good living by documenting all the occasions on which a textbook mentions the software crisis, Fred Brooks' Mythical Man-Month, and (if the writer has an industrial slant) the Chaos Report of 1994 that seemed to claim that almost half of all software projects failed, and then proposing yet another solution to all the world's ills. The Preface to Burge et al is no exception. Their solution:

"The most obvious approach, and quite likely the most powerful, is to explicitly describe and justify the design, implementation, and use of software systems, and to do this routinely, iteratively, and regularly throughout the software development process. We call this ..." (the title of the book follows).

Well, the sky may just fall in first, and the mountains will have been washed into the sea by untold trillions of raindrops over geological ages, before everyone in industry patiently documents and justifies every minor design change.

The book is neatly structured into 4 parts.

Part 1, oddly called Introduction though it consists of 5 chapters, sets the scene, describes the background, and explains what Rationale and Software Engineering are. It also looks at Decision-Making, which might seem odd until you reflect that the purpose of stating the reasons for things is to help people make their minds up rationally.
Part 2, Uses of Rationale, looks at using rationale for "evaluation" - in other words decision-making, or what industry calls optioneering or trade-offs; for collaboration; and for assessing the impact of change. There is also a chapter on how to present rationale, which might have gone better into Part 1; it feels a little strange as it manages to talk about diagrammatic formats and the use of video without a single diagram or photograph - in fact, the whole book's like that. Perhaps that's academia for you, or perhaps the authors felt that they had done illustrations enough in previous books and papers.
Part 3, Rationale and Software Engineering, looks in more detail at how rationale could be applied to software development, requirements engineering, software design, software "VV&T", software maintenance, and software reuse. In other words, it steps through the life-cycle as if it were a waterfall (the authors are aware of iterative and other life-cycle approaches), and suggests how rationale could help at each stage.
Part 4, Frameworks for Using Rationale in Software Engineering, looks ahead to how all this could in theory work, and the research challenges that rationale presents.

The overall effect is of a cool, dispassionate account of how, in theory, rationale ought to be useful, and if so in what ways. There are no practical illustrations (in text or graphics) of how it would actually work, nor are there any case histories from industry showing how it did in fact work. It feels instead as if the authors are trying to persuade someone (maybe themselves?) that rationale is really an awfully good idea, if only anyone would listen and take their advice.

I guess I was hoping for a lot more from this book: it is an interesting and provocative title, after all, and there is, ahem, a case to be made for it. Unfortunately, there is no mention of the one area of industry where rationale is in daily use - Safety Engineering. (In fact I made exactly this remark in a review of another book from the Rationale research community, Kirschner et al's Visualizing Argumentation, back in 2003, so nothing has changed.) The community seems consistently unaware of relevant work both in related areas of research, such as safety argumentation, and in industrial practice (and tooling). The day when it wakes up and takes notice of real uses of rationale will mark a major step forward in bridging the gap between the ivory tower and the real world.

Rationale does have a place in software or rather systems engineering - for it is in hardware/software embedded systems work that rationale finds much of its practical use. Requirements analysts create thousands of traces every day to justify requirements by satisfaction of higher-level system goals (though they call them requirements); they write thousands of justification texts as requirement attributes to explain the reason for specified features; and they build complex risk models, list assumptions, and add dictionary terms all as part of long-term efforts to show that systems will work reliably and safely. But all of this good solid rationale-based systems engineering work passes the authors by.

Researchers who want a well-thought out overview of what rationale could or should do, and what openings there might be for research in the area, will find this a helpful and good introduction to the field. Industrialists should look elsewhere. My forthcoming book on Discovering Requirements includes a whole chapter on Rationale.