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.

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!


Essential reading for programmers and their managers   July 27, 1998
68 out of 71 found this review helpful

As a developer, you have been on that project. The one that seems that it will never end. Requirements change daily, testing seems to discover new bugs faster than you can fix them, release dates come and go and noone seems to know when the project will be completed. If you're like me, maybe you thought that was just the way software projects were.

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.


THE Source Book for Software Project Planning & Management   July 20, 2004
John Nolley II (Fairfax, VA United States)
10 out of 11 found this review helpful

Those who have worked in the software industry are all too aware of the impacts of poor project planning and management endemic to their field: long hours of overtime, burnout, poor and difficult-to-revise code, etc. Even those outside the industry itself suffer from delayed product delivery, excessive bugs, and lack of product functionality due to shortcomings in project management. Rapid Development by Steve McConnell is the solution!

This isn't a book about how to program but rather how to plan to program and how to manage the tasks of development during programming. McConnell identifies some of the worst and most common mistakes made in project planning and describes their impact: ambitious deadlines cause high stress, coding errors, and usually cause the project to be completed way behind schedule; lack of communications between involved parties (users, managers, testers, developers etc.) leads to unrealistic expectations and missed goals; lack of proper planning and "coding like hell" lead to unmaintanable software, increased product bugs, etc.

Although to many software developers it may sound like McConnell is simply preaching to the choir, he offers solutions to each pitfall, many in the form of "best practices" with thorough analysis as to the appropriate use and any downsides of each. McConnell speaks from experience, having worked in development, management, and as a consultant for firms including Microsoft. Best of all, most of his solutions and practices he offers are simple to implement and pay off enormously over the lifetime of a project.

If more software companies followed the advice of McConnell's excellent book, software development might be a much more enjoyable profession, companies would save both time and money, and even the general public would be more satisfied with computer software whose headaches all too often stem from the poor development practices of the industry.


A must read for every software professional   August 19, 2003
Michael (Paris, France)
8 out of 9 found this review helpful

I'm a big fan of eXtreme Programming (XP) so I was particularly interested in reading this book to see if I could pick up some ideas and concepts different from that of XP. I was quite suprised to see many of the concepts and best practices McConnell presents in this book are very consistent with XP's practices. I also like how McConnell gives lots of references for his claims. He gives plenty of convincing data and supporting arguments to show what many of us already know yet many managers refuse to believe. Things like mandatory overtime can make productivity go down, the importance of moral, why managers can't control all the variables of a SW project (cost, schedule, & product). Overall this book is a great read and I really believe if everyone followed this book's best practices, especially 40 hour work week and honest scheduling, the entire SW industry would be much better than it is today.


Project Management Reference for ALL Software Professionals   April 5, 2003
Harinath Thummalapalli (Austin, TX United States)
12 out of 13 found this review helpful

Anyone who has ever been on a software project is initially confused by all the chaos involved. When Ford can churn out good quality and inexpensive automobiles and McDonald's can serve millions of satisfied people around the world, and we can put man on the moon, why do the most reputable companies struggle to deliver even the simplest of software projects?

After being on two new model launches at Ford that went smoothly, I moved into IT at the beginning of the economic boom in the mid-nineties and asked the same question. Why is the IT world so inept at managing software projects? My boss at the time quickly whipped out this book and asked me to read it cover to cover before asking any more questions or wasting any more time trying to figure this out. I did as I was told and found the answers I was looking for. I also found answers to questions I hadn't asked yet but I would have eventually. I instantly purchased a copy of this book for my long term personal book collection.

The book contains a thorough discussion of various software development practices and their effectiveness using case studies very extensively. These case studies stick in your mind really well and drive home the point that the author is trying to make. The book also talks about the most classic mistakes on any software development project and then details several strategies to avoid them altogether on your own project.

I still refer to this book whenever I feel nervous on a software project that something's not right. You don't need to be technical to understand the book and the book is written for anyone on a software project - from the project manager to the developer to the tester. I can't believe the pricing on the book. I am always comparing the value I get from any book I purchase and this is one of the most reasonably priced books for the 600 + pages of wisdom it provides. Share this book with your colleagues and friends, they will definitely thank you for it. Get a copy and start taming those wild software schedules!