Rapid Development: Taming Wild Software Schedules

The nine page section entitled "Classic Mistakes Enumerated" is alone worth the price of admission and should be required reading for all developers, leads, and managers. Here are some types of the 36 classic mistakes that McConnell describes in detail:

• People Related Mistakes
  • Heroics
  • Adding people to a late project
  • Politics placed over substance (etc.)
  
  
• Process Related Mistakes
  • Abandonment of planning under pressure
  • Planning to catch up later
  • "Code-like-hell" programming (etc.)
  
  
• Technology Related Mistakes
  • Silver-Bullet syndrome
  • Overestimating savings from new tools or methods
  • Switching tools in the middle of a project (etc.)

I suspect that if you've ever been involved in software development, you winced after reading each of these nine points. And you will learn a great deal from the remaining 640 pages about concrete solutions.

My only substantive gripe: cheesy Powerpoint graphics. Nonetheless, this book is Very Highly Recommended.

Product Description
Corporate and commercial software-development teams all want solutions for one important problem--how to get their high-pressure development schedules under control. In RAPID DEVELOPMENT, author Steve McConnell addresses that concern head-on with overall strategies, specific best practices, and valuable tips that help shrink and control development schedules and keep projects moving. Inside, you'll find:• A rapid-development strategy that can be applied to any project and the best practices to make that strategy work• Candid discussions of great and not-so-great rapid-development practices--estimation, prototyping, forced overtime, motivation, teamwork, rapid-development languages, risk management, and many others• A list of classic mistakes to avoid for rapid-development projects, including creeping requirements, shortchanged quality, and silver-bullet syndrome• Case studies that vividly illustrate what can go wrong, what can go right, and how to tell which direction your project is goingRAPID DEVELOPMENT is the real-world guide to more efficient applications development.

And then I read this book. Chapter 3 contains a case study of classic mistakes.  It sounded like every project I had ever worked on. Steve McConnell shows you how to avoid those mistakes, and how to leverage best practices in planning and development to achieve maximum predictability and control over your software schedule.  This should be required reading for all software project managers, technical leads and top management.  

While it's a long book, it lends itself to easy browsing. You can almost dip in at random and find some useful tip on how to improve your chances of bringing your project in on time and unde! r budget. But you'll want to read it straight through at least once. The last section of the book is devoted to individual Best Practices.  Each practice is explained along with its risks and benefits. Not all practices will be applicable to all projects, and the book guides you through when each is appropriate along with what practices it compliments.


Practical Guide With Real Life Examples   August 3, 2003
Abhinav Agarwal (Bangalore, India)
60 out of 63 found this review helpful

Steve McConnell's books have always displayed a remarkable degree of practicality and readability. This book is no different.

The author says at the outset the Purpose of the book is to answer issues about trade-offs. The author says that software can be optimized for any of several goals: lowest defect rate, lowest cost, or shortest development, etc... Software Engineering is then about achieving tradeoffs, and this is what this book is primarily about.
Because the book is so big, it has been broken into sections that can be read selectively and quickly. A short book would have oversimplified things to the point of uselessness.

Organization of the book:
Parts 1, 2 deal with the Strategy and Philosophy of rapid development, while part 3 covers Rapid develoment best practices

In chapter 3 the author talks about 'Classic Mistakes'. He calls them 'classic' and 'seductive' because they are so easy to make that they have been repeated in countless projects. The classic mistakes number 36 (though Steve M points out that a complete list could probably go on for pages and pages):
Undermined motivation, Weak personnel, uncontrolled problem employees, Heroics , Adding people to a late project , Noisy crowded offices , Friction between developers and customers , Unrealistic expectations , Lack of effective project sponsorship , Lack of stakeholder buy-in , Lack of user input , Politics placed over substance , Wishful thinking , Overly optimistic schedules , Insufficient risk management , Contractor failure , Insufficient planning , Abandonment of planning under pressure , Inadequate design , Planning to catch up later , Code-like-hell programming , Requirements gold-plating , Feature creep , Developer gold-plating , Push-me, pull-me negotiation , Research oriented development , Silver bullet syndrome , Overestimated savings from new tools or methods , Switching tools in the middle of a project , Lack of automated source-code control , Shortchanged quality assurance , Omitting necessary tasks from estimates , Shortchanged front end upstream activities.
He categorizes these classic mistakes into four sets : People related, technology related, product related, and process related.

Part 2 covers rapid development issues in greater detail.
Core issues like Estimation, Scheduling, Lifecycle Planning, etc.. are covered. `Soft' issues like Motivation, Teamwork, Customer Oriented Developmentare also covered.

Part 3 is a compendium of best practices. There is a summary table of the each best practice, and the efficacies, major risks, major interactions and trade-offs listed.

Some candidate best practices not included are getting top people
, Source Code Control, Requirements Analysis.. These are listed as fundamental to a software project.

The Best Practices listed are
JAD, Spiral Lifecycle Model, Theory W Management, Throwaway Prototyping, Staged Delivery, Voluntary Overtime, Miniature Milestones, Outsourcing, Reuse, User-Interface Prototyping, Change Board, Daily Build and Smoke Test, Tools Group.
As an example, Steve McConnel covers 'Inspections' stating the
chances of its long term success are excellent, it reduces schedule risk, its improvement in progress visibility is only fair, has no major risks, it can be combined with virtually any other rapid development best practice

The book has a very engaging style of writing...
Some quotes...
- Projects can look like a tortoise on valium to the customers, but as a rapid-development death march to the developers.
- The team ranks so low in the company that it has to pay to get its own team t-shirts.
- Rapid development isn't always efficient.
- Run every software project as an experiment (`Hawthorne Effect').
- If Las Vegas sounds too tame for you, software might be just the right gamble.
- The most common (and incorrect) definition of estimate is: `An estimate that has the most optimistic prediction that has a non-zero probability of coming true' - Tom DeMarco

All in all, a fully deserved five stars!


Recommended reading -- Great reference   November 1, 1999
Tom O Bjorkholm
23 out of 24 found this review helpful

The author of this book does not present "the one and only rapid development process". Instead the book presents in great detail over 20 good practices that are known to speed up development. The reader is expected to combine these practices to get a good combination for the current project.

The language in the book is smooth and the author really tries to explain in a simple and easy to understand way. I still needed a lot of time to read the book, simply because of the enormous amounts of information in the book.

The book includes a lot of statistical data. This is really great to have if you get into an argument with management about if the schedule is achievable.

The book is published by Microsoft Press. As I am very far from being a Microsoft fan, I was very sceptical at first. But the book is really great and applicable to all software development projects, including those on UNIX and embedded systems.


RAPID DEVELOPMENT: The project manager's Bible   December 31, 1997
25 out of 27 found this review helpful

I work for an Internet software development company, and I have made this book required reading for every project manager and technical lead in our company. McConnell's combination of conceptual knowledge, supported by hard facts, is a rare thing in software development "how-tos."

The best-practices section at the back of the book is an invaluable reference. His "bad" case studies depressed me sometimes -- mainly because they were too close to my own projects -- but the "good" ones have become the scripts for my presentations to clients. He has a way of capturing the essence of the atmosphere in a development shop, so the case studies feel as if they took place in your own office.

I would highly recommend this book to anyone whose job is managing the development process, whether that be in a technical lead or a project management position. Maybe if more people read this book and follow its guidelines, we could all stop working weekends.


Bible of project management   August 31, 2005
M. Kisialiou (MN USA)
13 out of 14 found this review helpful

I have bought this book occasionally because of the well-known name of Steve McConnell. Originally I was confused by the title that seemed to indicate another super methodology that promised heavens. No need to say that I was skeptical about it. Do not look at the title, although this book emphasizes its value for the fast paced projects, it is THE BOOK on project management as a whole. In general, the book comprises practical knowledge of generations of project managers. Do not miss your chance to get it now easy in few days what took some people's life time to learn! Amidst lots of practical examples, you will also find an exciting style and lots of must-know suggestions on small, middle and large size projects. I believe that any project manager must read this book if she/he has not done it yet. In addition to what is covered in the book, the author provides lots of links and references in case you need to explore the area in more detail. The time you will save after reading this book is worth much, much more than this book costs.