Truck Month Textbook Trade In Amazon Fashion Learn more nav_sap_plcc_ascpsc $5 Albums Tile Wearable Technology Fire TV with 4k Ultra HD Mother's Day Gifts Find the Best Purina Pro Plan for Your Pet Amazon Gift Card Offer starwars starwars starwars  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Fire, Only $39.99 Kindle Paperwhite UniOrlando Spring Arrivals in Outdoor Clothing SnS

Format: Paperback|Change
Price:$26.54+ Free shipping with Amazon Prime
Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

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.
0Comment|85 people found this helpful. Was this review helpful to you?YesNoReport abuse
VINE VOICEon August 3, 2003
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!
0Comment|66 people found this helpful. Was this review helpful to you?YesNoReport abuse
on October 31, 1999
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.
0Comment|25 people found this helpful. Was this review helpful to you?YesNoReport abuse
on December 31, 1997
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.
0Comment|25 people found this helpful. Was this review helpful to you?YesNoReport abuse
on August 30, 2005
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.
0Comment|13 people found this helpful. Was this review helpful to you?YesNoReport abuse
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
0Comment|19 people found this helpful. Was this review helpful to you?YesNoReport abuse
on April 4, 2003
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!
0Comment|12 people found this helpful. Was this review helpful to you?YesNoReport abuse
VINE VOICEon July 20, 2004
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.
0Comment|10 people found this helpful. Was this review helpful to you?YesNoReport abuse
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.
0Comment|5 people found this helpful. Was this review helpful to you?YesNoReport abuse
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.
0Comment|9 people found this helpful. Was this review helpful to you?YesNoReport abuse