Lies My Process Told Me

Dr. Dobb's Journal June, 2004

By Gregory V. Wilson

Greg works for Hewlett-Packard and is a DDJ contributing editor. He can be contacted at gvwilsonddj.com.

UML by Example
Ghinwa Jalloul
Cambridge University Press, 2004
249 pp., $35.00
ISBN 0521008816

Extreme Software Engineering: A Hands-On Approach
Daniel H. Steinberg and Daniel W. Palmer
Pearson, 2003
273 pp., $32.00
ISBN 0130473812

Software Development for Small Teams: A RUP-Centric Approach
Gary Pollice, Liz Augustine, Chris Lowe, and Jas Madhur
Addison-Wesley, 2004
272 pp., $39.99
ISBN 0321199502

Applied Software Engineering with Apache Jakarta Commons
Christian Gross
Charles River Media, 2004
416 pp., $49.95
ISBN 1584502460

All right, it's time to be honest. No one I know actually follows the rules of any particular software development process. From the Rational Unified Process to eXtreme Programming—and at points in between—process models are about as accurate a description of how programmers work as Robert's Rules of Order are of how politicians turn bills into laws.

But that doesn't mean process models are useless. In the real world, good programmers pick and choose ideas from various process models according to the needs of the moment. Have some tricky code to write? Grab a friend, and do some pair programming. Afraid that your customers might change their minds about deliverables halfway through a fixed-deadline project? Do a lot of up-front design and get them to sign off on it. For most programmers, process models are a source of ideas and a reminder that if they're doing X, they should probably do Y as well.

I therefore think that students ought to learn at least two different process models while pursuing their degrees (where "learn" means "use in one or two large projects"). Ghinwa Jalloul's UML by Example, and Daniel Steinberg and Daniel Palmer's Extreme Software Engineering, would be a good pair of textbooks for such a course.

Jalloul's book focuses on the Bridge model, which is based on up-front design and iterative implementation. The first third of the book is a condensed, and rather dry, introduction to the Unified Modeling Language (UML). Part II then presents two detailed case studies, from the initial statement of the customer's needs, through requirements gathering, to class design. Part III contains fragments of three more case studies; filling in the gaps is left as an exercise for readers.

Steinberg and Palmer's book takes a different approach. Chapters 1 and 2 are a broad-brush overview of XP's key practices. Their aim is to let you start programming together. Subsequent chapters then revisit these chapters, expanding on earlier points and exploring the ways in which the practices depend on each other.

Both books are well written, although you will probably find Steinberg and Palmer's easier to read. Jalloul's would benefit from having some actual code in the examples so that students could see the end product of their designs. Extreme Software Engineering, on the other hand, would benefit from a little more critical commentary—while the authors never claim that XP is a silver bullet, they don't go out of their way to draw attention to its limitations, either.

Like Jalloul's book, Software Development for Small Teams, by Gary Pollice et al., aims to teach a more-formal-than-not approach to software development. It is built around one extended example—the design and development of a tool for gathering information about programmers' performance.

The book is much more code-centric than Jalloul's, and I think you will enjoy its discussion of particular tools (such as various Java IDEs). However, I found it slow: The authors frequently took a paragraph, or a page, to say something that could have been explained in a single sentence.

I also came away feeling that the book's title was somewhat misleading. The "RUP" in the title is the Rational Unified Process, but in several places, the authors skipped over some of RUP's steps or did only part of the work that "real" RUP requires. This is the right thing to do in the real world, but in a tutorial whose aim is to teach a particular process, skipping steps is a little like cheating.

Last on this month's list is Christian Gross's Applied Software Engineering Using Apache Jakarta Commons. The book isn't really about software engineering, at least, not in the same way as the other titles reviewed this month. Instead, its purpose is to show you how best to use the Java packages developed and/or hosted by the Apache Jakarta Project. Want to log events? Serialize objects? This book shows you some good open-source libraries, and more.

This book falls somewhere between a tutorial and a reference guide. Its pattern-based view of how different components fit together helped me understand how Jakarta's various offerings collaborate, though it didn't go far enough for the book to be used as a standalone text. If you have to do one thing in a hurry, this probably isn't the book for you. If you have a lot of things to do, and can take some time to figure out how to do them well, this book may be just what you're looking for.

DDJ