|
|
|
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.
-- Ray Duncan
In the fairy-tale version of Jack and the Beanstalk, the magic beans grow into a giant beanstalk, and Jack has a great adventure. But in the software version, when Jack's mother throws the beans out the window, that's the end of the story. The beans don't contain any magic, and Jack has just wasted his mother's cow.
Software people buy magic beans whenever they believe claims that their best judgment tells them are impossible. Vendors continue to promise that they have beans that will produce huge beanstalks and allow the purchasers to scale to impossible heights of productivity. Developers and managers continue to spend millions of dollars based on those claims. The $64 question for our industry is, "how many times are we going to buy the same magic beans?"
It's human nature to look for an easy way out, and it's entirely rational to look for the cheapest, fastest, easiest solution. But it's hard to believe that trained professionals would continue to act against their best judgment for 30 years, which is what we as an industry have done.
Software development is a tough, time-consuming business. For 30 years we've been told that the magic that will enable us to slay giant schedules and budgets is just around the corner. For 30 years it hasn't come. I say, enough is enough. There is no magic. There is no point in waiting for it. The more we wait, the more we deprive ourselves of valuable, incrementally better solutions to many of our problems. There aren't any easy solutions, but there are easier solutions, which can provide modest improvements individually and dramatic improvements collectively.
This whole book, in a sense, is an entreaty to stop buying magic beans and looking for silver bullets. We as an industry need to grit our teeth, bite the bullet, and do the hard work necessary to achieve real productivity gains.
-- from Steve McConnell's Rapid Development, pages 367-368.
A Case Study in Classic Mistakes
What Kind of Rapid Development Do You Need?
Best Practice: Voluntary Overtime
Case Studies in Project Recovery
Best Practice: Daily Build and Smoke Test
|
|
Part I: Efficient Development |
|
1 |
Welcome to Rapid Development |
|
2 |
Rapid-Development Strategy |
|
3 |
Classic Mistakes |
|
4 |
Software-Development Fundamentals |
|
5 |
Risk Management |
|
|
Part II: Rapid Development |
|
6 |
Core Issues in Rapid Development |
|
7 |
Lifecycle Planning |
|
8 |
Estimation |
|
9 |
Scheduling |
|
10 |
Customer-Oriented Development |
|
11 |
Motivation |
|
12 |
Teamwork |
|
13 |
Team Structure |
|
14 |
Feature-Set Control |
|
15 |
Productivity Tools |
|
16 |
Project Recovery |
|
|
Part III: Best Practices |
|
17 |
Change Board |
|
18 |
Daily Build and Smoke Test |
|
19 |
Designing for Change |
|
20 |
Evolutionary Delivery |
|
21 |
Evolutionary Prototyping |
|
22 |
Goal Setting |
|
23 |
Inspections |
|
24 |
Joint Application Development (JAD) |
|
25 |
Lifecycle Model Selection |
|
26 |
Measurement |
|
27 |
Miniature Milestones |
|
28 |
Outsourcing |
|
29 |
Principled Negotiation |
|
30 |
Productivity Environments |
|
31 |
Rapid-Development Languages (RDLs) |
|
32 |
Requirements Scrubbing |
|
33 |
Reuse |
|
34 |
Signing Up |
|
35 |
Spiral Lifecycle Model |
|
36 |
Staged Delivery |
|
37 |
Theory-W Management |
|
38 |
Throwaway Prototyping |
|
39 |
Timebox Development |
|
40 |
Tools Group |
|
41 |
Top-10 Risks List |
|
42 |
User-Interface Prototyping |
|
43 |
Voluntary Overtime |
|
Readability |
|
|
Originality |
|
|
Organization |
|
|
Accuracy |
|
|
Consistency |
|
|
Depth |
|
|
Timeliness |
|
|
Editing |
|
|
Design |
|
|
Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.
