- Shopping Bag ( 0 items )
Gregory V. Wilson
Dancing Around the Problem
If you're like me, you had to wade through at least one dry, and apparently irrelevant, software engineering text at college. Well, guess what? You'll probably have to do it again a couple of years from now. If you do, you might want to check out the books reviewed below.
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.
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.
— Dr. Dobb's Electronic Review of Computer Books