This time I look at books that describe important tools for planning and reviewing development projects.
UML
According to its official documentation (www.rational.com/media/uml/post.pdf),
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.
In other words, UML provides a standard way to create diagrams that represent complex systems. It does not mandate a programming language or a development methodology, even though it arose out of long experience with both. Again, the official documentation states
Although the UML does not mandate a process, its developers have recognized the value of a use-case driven, architecture-centric, iterative, and incremental process, so were careful to enable (but not require) this with the UML.
This attempt at generality makes it hard to get a handle on UML, and that's where the following book comes in.
UML Explained by Kendall Scott (Addison-Wesley, Boston MA, 2001, 169pp, ISBN 0-201-72182-1, www.aw.com, $29.95)
Kendall Scott is a technical writer who has been helping software developers write about their field for a number of years. He is a contributing author of UML Distilled (Addison-Wesley, 1997) and Use Case Driven Object Modeling with UML (Addison-Wesley, 1999). You can view his UML dictionary at www.usecasedriven.com/UML.htm.
About five years ago, in an attempt to find more interesting work than writing API documentation, he obtained and tried to read an early version of the Unified Method documentation (by Grady Booch and James Rumbaugh). He decided that the only way to understand it was to rewrite it. One thing led to another, and UML Explained is the result.
Scott sacrifices generality for clarity. While UML is officially process independent, Scott assumes an iterative and incremental process that starts from use cases and proceeds in such a way that the connections between the use cases and the models are always clear (http://www.rational.com/products/rup/index.jsp). Along the way he introduces all of the main UML elements and shows how to use them in the four phases and five workflows of that process.
Scott imagines an online bookstore that looks like a stripped down Amazon.com. Each time he describes a UML element, he illustrates it with concrete elements of the online bookstore. As a frequent Amazon.com user, I find these examples instantly accessible, making the underlying UML conventions easy to understand.
While I do recommend this book, I find parts of it inexcusably sloppy. In addition to the lack of basic copyediting, which is fast becoming the industry standard, the book has a couple of major usability flaws. The layout fails to synchronize the text with the many figures. For example, on page 32, between figures 3-17 and 3-18, is a block of text that refers to figure 3-20. As I read this text, my eye is drawn to figures 3-17 and 3-18, then to figure 3-19 on the facing page. Finally, if I turn the page, I find figure 3-20 on page 34. This kind of confusion occurs again and again throughout the book.
Another usability flaw is the way Scott does cross-references. For example, on page 115, in the midst of chapter 9, Scott says "See 'Template Classes' in chapter 6 for more about template classes. See Figure 3-9 for more about roles." The targets of these references are on page 85 and page 28. There is no good excuse for failing to include those page numbers in the cross-references. As with the layout problem, this flaw occurs consistently throughout the book.
If you're willing to overlook its editing and usability flaws, the book provides a clear explanation of UML in a mercifully small number of pages. If you work with software developers who use UML, or if you wish your development process were more predictable and reliable, you ought to read this book.
Retrospectives
A third of a century ago the NATO Science Committee convened a conference to deal with the software crisis. The conference didn't solve the problem, but they coined the term software engineering. Today the software crisis is not yet under control, but many companies have adopted software engineering processes designed to make development more predictable and reliable. A key element of most such processes is the project retrospective, also commonly known as the postmortem.
The first postmortem that I can recall was not formal or officially sponsored. The late Rudolph Langer, a talented and introspective development manager that I worked with in the 1960s wrote a memo about lessons learned from our last project and circulated it for comments. Langer had served in the military, where such retrospective examinations are routine, but I don't know if that's what gave him the idea.
In 1975, Fred Brooks published The Mythical Man Month (2ed, Addison Wesley, 1995), which detailed the lessons he had learned from leading the development of IBM's System 360 operating system. This is the essence of the project retrospective: to look back on what happened, to evaluate and learn from what went right and what went wrong, and to use this information to make the next project more successful.
Most large software development companies have instituted formal process improvement programs -- either because they believe strongly in continual improvement or because they need to satisfy an external auditor. All process improvement programs incorporate introspection and feedback and hence call for some sort of project retrospective. Many companies, however, give only lip service to this valuable opportunity to learn and grow. Often, they'd rather let sleeping dogs lie. Even more often, however, they don't understand the potential benefits, so they are not willing to commit the resources necessary to do it right.
Project Retrospectives -- A Handbook for Team Reviews by Norman R. Kerth (Dorset House, New York NY, 2001, 288pp, ISBN 0-932633-44-7 www.dorsethouse.com $39.45)
If you have participated in project retrospectives and found them unrewarding, this book will open your eyes. Norman Kerth has been facilitating project retrospectives for twenty years. His clients are some of the best known software firms in the world.
Kerth wrote this book for facilitators -- people who lead project retrospectives. These are typically outside consultants, because, as Kerth explains very clearly, you can't facilitate a retrospective of a project that you have participated in. In this review I don't focus on the material that is mainly for professional facilitators.
Many people who will never facilitate retrospectives, however, will benefit from reading this book, because it is so full of information, psychological insight, and wisdom. The book is full of examples that give a clear idea of how the process works. Kerth intersperses parables and cartoons with the more formal material, making the book hard to put down.
Kerth also takes time to build the business case for doing retrospectives. A retrospective entails three or four days, usually at some sort of offsite conference facility, with meals and lodging for up to 30 people, and a professional facilitator -- a considerable expense, but one Kerth justifies quite simply: If the exercise saves you six days on your next project, which he assures you it will, you come out with a profit.
If you're doubtful about Kerth's math, or if you want to get a better sense of why such an elaborate process is justified, be sure to read the first two chapters. You'll probably want to read more, but even if you don't you'll come away with a better idea of the value and proper goals of a project retrospective.
I recommend this book to anybody who regularly works on or oversees development projects.
