Programmer's Bookshelf

Paul, a P.h.D student in the department of computer science at the University of Toronto, can be contacted at [email protected]. Chris is a developer in Toronto and can be contacted at [email protected].

Software Project Survival Guide
Steve McConnell
Microsoft Press, 1998
288 pp., $22.99
ISBN 1-57231-621-7

UNIX Network Programming, Volume 1: Networking APIs: Sockets and XTI, Second Edition
W. Richard Stevens
Prentice Hall, 1998
1240 pp., $59.00
ISBN 0-13-490012-X

Having worked in the software business as a tester, technical writer, programmer, client, consultant, and (most recently) manager, I've seen plenty of software projects crawl toward completion, overbudget, behind schedule, and defect-ridden. Consequently, I could share with you a long list of ways to fail when running a software project. Describing how to succeed is a much more difficult problem, and Steve McConnell's Software Project Survival Guide is the best attempt at a step-by-step guide I've run across.

Targeted at managers (from the top of organizations down through technical leads), McConnell's book provides a blueprint for a successfully managed project; the postulated development effort involves "3 to 25 team members and schedules of 3 to 18 months." At 288 pages, the book could be thinner, but it's easy enough to get through. McConnell has an engaging, conversational style, with a tinge of irreverent humor -- both of which make this book easy to approach. He uses little jargon and includes a comprehensive glossary, so nontechies should find it easy enough to follow.

McConnell moves quickly through a "survival test" to assess a project's chances of successful completion, then steps through the project life cycle, from preliminary planning to a postcompletion wrap-up. The approach he advocates is heavier on formal process than the industry norm, but McConnell makes a reasoned and (usually) compelling case for each component of the process, explaining how it increases the visibility of the project's progress and/or decreases a risk endangering the project's success. McConnell is careful to point out, however, that paperwork haphazardly pushed around for formality's sake will have the opposite of the desired effect, slowing the project's progress without improving quality. If you're trying to decide which bits of formal software-development practices to employ in your project, this is a good place to look for advice.

Software Project Survival Guide contains many examples of step-by-step procedural directions, which can be customized easily to suit your own project, and each chapter ends with a checklist of procedures to follow. Unlike many offerings from Microsoft Press, this book is relatively dense; graphics and figures are sparse and, when they do appear, generally serve a useful purpose, illustrating a point or backing up an argument.

I was disappointed by one aspect of Software Project Survival Guide: It assumes that you, the reader, can exercise complete control over the entire software-development process. While some managers do have such power, many of us have to work within limitations imposed by corporate politics and contractual obligations. Software projects often require a cooperative effort by two or more separate companies (or separate units within a large organization), each of which has a distinct culture, a natural tendency to hide the details of its operations from external scrutiny, and a deep resistance to the imposition of new software-development practices to conform to an outsider's expectations. This poses three challenges:

• You need to facilitate interteam, cross-culture communication; for instance, to identify vital information and ensure that it is shared with and understood by all relevant parties.
• You and your counterpart(s) need to adapt your development practices to a mutually acceptable compromise position, and ensure that materials produced on both sides are compatible.
• You need to practice defensive risk management; you need to provide yourself with alternatives in case some component, whose development you do not control, is delivered late, with insufficient quality, or not at all (Murphy's Law usually applies).

To be fair, there's enough material there for three additional books (are you listening, Steve?).

While the Software Project Survival Guide hasn't unseated Fred Brooks' Mythical Man-Month as my candidate for best all-time book on software-project management, it's an honorable runner up. If you're an upper or middle manager in an organization that develops software, you should definitely read this book. If you're a technical lead or a developer, you should start with this book, then turn to McConnell's Rapid Development (see "Programmer's Bookshelf," DDJ, March 1997; available electronically, see "Resource Center," page 3), which provides lower-level and more detailed advice on how to run a successful development operation. I know that these two books have improved the way that I develop software. I hope that they will have a similar effect on you.

-- C.J.

UNIX Network Programming

Writing code to exchange data over a network can be difficult, so the second edition of UNIX Network Programming, Volume 1 (UNPv1 for short) by Richard Stevens is a welcome resource.

The first edition is considered a classic. "Can I borrow your Stevens book?" is a common request. The new edition updates one third of the material with discussions about recent technologies, such as Posix threads and the IP Version 6 protocol (IPv6). Two future volumes promise to update interprocess communication and network applications.

UNPv1 has both breadth and depth in its coverage of the socket API and the alternate (and orthogonal) XTI API. Programming with the TCP, UDP, and IP protocols is covered at length, as well as lower-level raw sockets. The myriad of function calls, data structures, and options associated with the APIs are explained with well-chosen diagrams and tables.

For example, Figure 4.1 nicely summarizes the basic steps for programming clients and servers. Dozens of code examples (available on the Web) synthesize the concepts into source code that can be directly used by the reader. When the programming options threaten to swamp the reader, the author provides solid guidelines and advice, as in Section 20.4, "When to Use UDP Instead of TCP."

Basic network programming can be explained in a few pages, but the real difficulties arise when programming for robustness, performance, and portability. In tutorial fashion, Stevens incrementally improves upon client-server code examples to explain how different errors can be handled, how different design choices affect performance, and how best to handle different protocols (for example, IPv4 versus IPv6). Chapter 27's discussion of server design options, complete with quantified performance, is particularly valuable. And throughout the book, in-lined footnotes and comparison tables explain the idiosyncrasies of the APIs on different versions of UNIX.

UNPv1 succeeds admirably, for the most part, in its dual goals of being both a tutorial and a reference. The detailed index, bibliography (with URLs), and Appendix C's discussion of debugging techniques are much appreciated. However, I have one specific criticism: The captions of code examples should be more complete, particularly if the example contains a flaw. For example, Figure 21.5 contains a deliberate design error, but there is no caveat in the caption. The error is fixed in Figure 21.6 and is discussed in the main text, but if I am using the book as a reference, I could mistakenly model my code after the flawed example. Having to reread the chapter or section just to ensure that I am using the correct code is not ideal. (I've taken to writing "see also" notes directly beside figures.)

My current software project needs a performance boost in its network code, so I'm glad to have UNPv1. In fact, I'm getting a second copy of the book because I expect colleagues will want to borrow this edition as much as the first.

-- P.L.

DDJ