|
|
|
|
|
|
Every software developer I know believes that the Year 2000 bug is going to cause some degree of chaos. The debate tends to focus on how much, but I'm more interested in what will happen to our profession afterward. With millions of voters screaming about missing social security checks and driver's licenses that can't be renewed, politicians will want quick, tidy solutions.
I therefore predict that within a year or two there will be new laws in most jurisdictions requiring programmers to demonstrate that they meet certain professional standards in order to bid on large government contracts. And where will those standards come from? My best guess is that the top practices of the time, or at least practices with large advocacy groups, will be adopted wholesale. It really won't matter whether UML (for example) is the "right" notation for object-oriented design. It will be in the right place, at the right time, and we will all have to choose between using it, or letting big (and profitable) contracts pass us by.
All of which brings me to the first of this review's two books. Kim Caputo started on the Burroughs side of Unisys, which typically used many small teams to develop software. There was little process, and teams succeeded or failed based almost entirely on the strengths or weaknesses of their members. In contrast, the Sperry side of Unisys had lots of process documentation, but as the merged company's business changed, that documentation was becoming shelfware.
As a member of the merged company's Software Engineering Process Group, Caputo's job was to bring these groups's disparate development practices into line with those prescribed by the SEI's Capability Maturity Model (CMM) (see The Capability Maturity Model: Guidelines for Improving the Software Process by the Software Engineering Institute, Addison-Wesley, 1994, ISBN 0-201-54664-7). Unsurprisingly, this turned out to be more difficult than anyone had expected. Caputo has therefore done our profession a service by writing CMM Implementation Guide, a book about how to get programmers--and the organizations they work in -- to make the changes that the CMM requires.
The book is relatively light on its description of the CMM itself (although the diagrams on pages 36-40 are the clearest summary of the CMM I've ever encountered). Instead, Caputo's book has chapters on such things as how to lift the spirits of developers who are feeling frustrated or bewildered as their world changes, and how to adapt the general specifications of the CMM to particular company cultures. Throughout, Caputo uses choreography as a metaphor, drawing analogies between (for example) the different ways dancers learn a new step, and the different ways in which programmers can go about adopting a new design methodology.
The book would be more appealing if this metaphor had been downplayed a bit, as it occasionally smacks of warm, fuzzy, New Age management-by-hugging. However, the book is a good one, and well worth reading if there's an SEI assessment or ISO 9000 review in your future.
Walker Royce's Software Project Management, on the other hand, is a more traditional, but also somewhat iconoclastic, book. The introduction to Part I is a good indicator of Royce's approach:
"In the past 10 years, I have participated in the software process improvement efforts of several Fortune 500 companies. Typical goals of these efforts are to achieve a 2X, 3X, or 10X increase in productivity, qualtiy, time to market, or…all three…The funny thing is that many of these organizations have no idea what X is, in objective terms."
Royce's thesis is that many current software management practices are tied to archaic technologies and techniques. His book therefore focuses on what we should keep doing, what we should change, and why. For example, Chapter 4 is a point-by-point discussion of the points raised in Alan Davis's influential article "Fifteen Principles of Software Engineering." Royce argues that some of Davis's principles, such as evaluating design alternatives before starting construction, are anchored in the discredited waterfall model, and may actually be counter-productive in a world where iterative development is done using commodity components.
Similarly, Royce is sceptical about the benefits of code inspections, believing both that modern tools allow automated testing through the project lifecycle, and that code inspections are usually so boring that they are inevitably superficial. Perhaps his most challenging statement is that you shouldn't plan to throw this process away. Instead, you should plan to evolve your product.
Unfortunately, some of the middle chapters are bogged down with descriptions of management sets, requirements sets, and so on. These chapters discuss how the various bits and pieces of managementaria relate to one another, without actually describing what they are. For someone like me, who has never worked on a 100-person, multiyear project, it's all a bit opaque.
Despite that, I think Royce's book is worth reading, primarily because it challenges received wisdom. I came away feeling that he had tried many things, and had thought long and hard about why some approaches worked and some didn't. I believe we're all going to have to do that in about a year's time, and I recommend this book to anyone who wants to get an early start.
-- Gregory V. Wilson (gvwilson@interlog.com)
