Biting the Silver Bullet
Pop Quiz: What do Charles Petzold's Programming Windows and
Andrew Schulman's Undocumented DOS have in common? Your
knee-jerk reaction would probably be, "Not very much!" Philosophically, the two books lie at extreme opposite ends of the programming spectrum. Yet, on a more abstract level, the books are members of the same exclusive club: they established a new genre or ecological niche in computer trade book publishing, and then -- by virtue of their authority, comprehensiveness, and readability -- went
on to dominate that niche for many years.
Steve McConnell's Rapid Development is instantly recognizable as another member of that rare breed of highly original and definitive books. It addresses a dire need in mainstream commercial or "shrinkwrap" software development that was previously unmet and only dimly perceived. It integrates a vast amount of practical information within a logical, easily grasped structure. It is soundly grounded in the author's mastery of his subject and common sense, and it is
backed up by hundreds of references. And, last but hardly least, it is beautifully written in an economical, direct style that makes every page count.
For those of you who are (justifiably) skeptical about the extravagant claims made for "Rapid Application Development" (RAD) products, fear not --this book is not about CASE or Visual Basic. RAD development tools are certainly described in the book, but only as one arrow in a quiver of many. Rather, Rapid Development is a wide-ranging book on the professional and fact-based management of software development projects, with "rapid(er) development" as the hook.
The chapters of Rapid Development are organized under the umbrella of three main themes. The first section is principally concerned with "efficient development" rather than "rapid development" -- focusing in on fundamental technical and management principles, assessment and management of risk, and avoidance of classic mistakes. Proper attention to these areas makes schedules and costs at least predictable. Most of the topics are illustrated with entertaining (and sometimes painfully familiar) case histories.
The second section is a detailed exploration of a diverse strategies, techniques, and tools for speeding up the development process. Each topic, ranging from lifecycle planning to improving the motivation of developers, gets the careful, thoughtful treatment that is McConnell's hallmark. The chapters on estimation, scheduling, and feature-set control are especially valuable. I've read about code
size estimation and software project scheduling many times elsewhere, but only after reading Rapid Development did I truly believe.
The last section of the book is a collection of mini-essays on 27 "best practices"in a common format. Each begins with a table that summarizes the technique's efficacy in various domains, major risks, interactions, and tradeoffs. The table is followed by a (sometimes extensive) discussion of usage, risk management, side effects, and "keys to success" for the practice at hand. Citations for further
reading on each "best practice" are often provided as well.
In Rapid Development, we are privileged to see a virtuoso author/programmer and a superb editing and publishing team working together at the top of their form. Very few books I have encountered in the last few years have given me as much pleasure to read as this one. The only teensy quibble I have with the book is a design issue -- elimination of the excessive white space and the slightly patronizing "hard facts," "classic mistake," and "cross-reference" icons and tags in the left margins would have shortened the book by a hundred pages or more and saved quite a few trees.--Dr. Dobb's Electronic Review of Computer Books
Read an Excerpt
From Chapter 9: Beating Schedule Pressure
Focus on Interests, Not Positions
Suppose you're selling your car in order to buy a new boat, and you figured that you need to get $5000 for your car in order to buy the one you want. A prospective buyer approaches you and offers $4500. You say, "There's no way I can part with this car for less than $5000." The buyer says, "$4500 is my final offer."
When you negotiate in this way, you focus on positions rather than interests. Positions are bargaining statements that are so narrow that in order for one person to win, the other person has to lose.
Now suppose that the car buyer says, "I really can't go over $4500, but I happen to know that you're in the market for a new boat, and I happen to be the regional distributor for a big boat company. I can get the boat you want for $1000 less than you can get it from any dealer. Now what do you think about my offer?" Well, now the offer sounds pretty good because it will leave you with $500 more than you would have gotten if the buyer had just agreed to your price.
Underlying interests are broader than bargaining positions, and focusing on them opens up a world of negotiating possibilities. Your boss might start out by saying, "I need a Giga-Blat 4.0 in 6 months," and you might know immediately that you can't deliver it in less then 9 months. Your boss's interest might be keeping a promise made to the sales organization, and your interest might be working less then 60 hours a week for the next 6 months. Between the two of you, you might be able to create a product that would satisfy the sales organization and would be deliverable within 6months. If you focus on interests, you're more likely to find a win-win solution than if you dig into bargaining positions.
One of the major problems with schedule negotiations is that they tend to become one-dimensional, focusing only on the schedule. Don't get dug into a position. Make it clear that you're willing to consider a full-range of alternatives--just not pie-in-the-sky options. If other people have dug themselves into demanding a specific schedule, here are some points you can use to dislodge them:
Appeal to true development speed. Point out that the worst fault of overly optimistic schedules is that they undermine actual development speed. Explain the negative effects of overly optimistic scheduling that were described in Section 9.1. True rapid development requires that you be firmly connected to reality, including to a realistic schedule.
Appeal to increasing the chance of success. Point out that you have estimated the most likely completion date and that you already have only a 50/50 chance of meeting that. Shortening the schedule will further reduce your chances of completing on time.
Invoke your organization's track record. Point to your organization's history of underestimating projects, coming in late, and all the problems that lateness has caused. Appeal to the other person's good sense not to do the same thing again.
Invent Options for Mutual Gain
Rather than thinking of negotiating as a zero-sum game in which one person wins at the other's expense, think of it as an exercise in creative problem-solving; the truly clever negotiator will find a way for both parties to win.
Your most powerful negotiating ally in schedule negotiations is your ability to generate options that the other person has no way of knowing about. You hold the key to a vault of technical knowledge, and that puts the responsibility for generating creative solutions more on your shoulders than on the nontechnical person you're negotiating with, It's your role to explain the full range of possibilities and trade-offs.
I find it useful to think about how many degrees of freedom there are in planning a software project. The basic degrees of freedom are defined by the schedule, cost, and product triangle. You have to keep the three corners in balance for the project to succeed. But there are infinite variations on that triangle, and the person you're negotiating with might find some of those variations to be a lot more appealing than others. Here are some of the degrees of freedom you might suggest related to the product itself:
Here are some degrees of freedom related to project resources:
- Move some of the desired functionality into version 2. Few people need all of what they asked for exactly when they asked for it.
- Deliver he product in stages--for example, versions 0.7, 0.8, 0.9, and 1.0--with the most important functionality coming first.
- Cut features altogether. Features that are time-consuming to implement and often negotiable include the level of integration with other systems, level of compatibility with previous systems, and performance.
- Polish some features less-implement them to some degree, but make them less fancy.
- Relax the detailed requirements for each feature. Define your mission as getting as close as possible to the requirements through the use of prebuilt commercial components.
- Add more developers, if it's early in the schedule.
- Add higher-output developers (for example, subject-area experts).
- Add more testers.
- Add more administrative support...