on July 26, 1998
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.
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...
- 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!
on March 8, 2000
I read Michael Dinowitz's review of Steve McConnell's Code Complete in last week's issue of Fusion Authority, and wanted to tell you about another great book by him called "Rapid Development". This one is good for team ColdFusion projects on a short deadline (and what ColdFusion project is not rapid development!). The sub-title "Taming Wild Software Schedules" sums it up.
The book covers both technical ideas (such as estimation, risk management and mini milestones) and the psychology of both programmers and teams. The latter may be particularly useful on the high burnout 12-hour-a-day work cycle of many ColdFusion programming teams I have seen. Keeping everyone motivated and working together as a team is often more important than technical programming tricks on a large project.
Project Management Cookbook
The second half of the book, "Best Practices," is a cookbook of 36 techniques for project leaders designed to stop overruns and control those out-of-control, large ColdFusion projects. I have been developing for over 20 years, and nearly all of McConnell's tips ring true. The book is not about ColdFusion per see; it concerns any Rapid Development language.
I liked the fact that he rated each of these cookbook methods by the following criteria:
Potential reduction from nominal schedule Improvement in progress visibility Effect on schedule risk Chance of first time success Chance of long-term success
Here are some 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.)
If you are like me and have been involved in a few "projects from hell" then I am sure you recognise some (or all) of the above!
There are also fun sidebars from the trenches of real development teams, both successes and disasters. Twenty real-life case studies round it out.
This is a long book (650 pp) but I have found myself dipping into it for new insights in my daily work as a ColdFusion project manager.
Review by: Michael Smith, TeraTech
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.
on September 30, 2013
I bought this book when it first came out in 1996. Aside from a few dated references, the information is just as pertinent today as it was then.
It was a sad state of affairs when in 1996, a book could be written about "classic mistakes in software development" that had been studied and known for 20 years, but still plagued the software industry. It is an even sadder fact that, 17 years later, companies continue to make these same mistakes with the same or greater frequency.
This book has served me well in various roles over the years, from Senior Programmer to Director of Application Development. It is astonishing to me when I come into a new organization with "fresh ideas" about how to identify and resolve problems in their SDLC, when the roots of most of those ideas come from what I read in this book so many years ago.
This is a great book for software developers and managers alike. But if there is one group that OUGHT to read this book, it is every CEO and CIO in the country. Real change and improvement in an IT organization starts at the top, and until these people recognize and understand the mistakes the organization is making, change cannot take place.
on October 31, 2001
This book is *AMAZING*. After years of "code-like-hell" development and amazingly frustrating bugs related to design flaws, I finally decided to pick up a book on the development process geared towards getting the project done and out the door.
After digging around numerous sites, reading literally hundreds of reviews, and soliciting the opinions of fellow developers, I finally settled on ordering "Rapid Development" and one of the other books by the same author, "Code Complete".
All I can say is "holy cow". "Rapid Development" was delivered to my door around 3pm on a Saturday afternoon. I picked it up and right away read chapter 3 - "Classic Mistakes". The scenario presented in the chapter just about blew my mind; it detailed every issue I have ever come across in the development process that has stalled or killed a project. It was also well written with a dry, witty humor; a definate must for any technical book about typically dry subjects.
After reading that one chapter, I flipped back to the beginning of the book and read it all the way through. I didn't put the book down until midnight, and after I had, there were all sorts of ideas screaming through my head I could apply to my current engagements.
Managers and non-technical people will greatly benefit from this book too. Have you ever that manager who stands over your shoulder asking you how it's going, why you're doing something a certain way, or what's taking the project so long? Give this book to your manager and tell him to read Chapter 11, "Motivaton". Chapters 3 and 11 provided the proper explanations for the constant recurrance of certain software project issues ("Why are the programmers working twelve hours a day and the project never seems to get any closer to completion?" "What exactly is so hard about adding this one feature to the program that was never accounted for in the first place?" "If those programmers are such geniuses, why won't they share code or use each other libraries?") to persuade my company to buy this book for all developers and technical managers.
Never has a technical book provided me with so much insight and so much open-ended, thought-provoking detail. I was able to apply about a third of the principles described to about 90% of all the projects i've ever worked on without thinking for more then a minute or two. The other two thirds proved themselves when digging deeper into the various issues.
Blah. What a burst of hot air. I've personally never EVER written a review for a book (never enough time), but I just HAD to stop and give five stars to this one.
BUY THIS BOOK. AND BUY IT FOR YOUR MANAGERS. NOW.(...)I am THAT confident that it provide at least one improvement to the way you develop software, if not many.