Rapid Development: Taming Wild Software Schedules

Having seen quite a few projects go haywire; reading this bookmade me pinpoint exactly all the faults those projects had. Thegood thing about this book is that its complete. Some books coversome areas and some others, but this covers all. For eg., if youjust read the first few chapters and decided to apply techniqueslearnt to your project, you might not apply them correctly as youyou didn't read the whole book to get a complete picture ofrapid development.This books is good for people working in startups. Developersshould also read this book so that they can help avoid mistakesof managers/tech.leads in a fast-paced environment where thingscan get easily missed.

This is a must read for experienced and new people. I found it an easy fast read and have lived through many of the scenarios described. Regardless of your place in software development as a manager, administrator, designer, programmer, tester, even service, being aware of these practices can help you create a better product and provide you the information to influence those who can affect the software environment.

This book is quite long, but worth every page. As a programmer, one usually gets focused on that - programming. There are however, several dynamics at play at any given software development project: customers, unstable requirements, risks, teamwork, tools, etc. This book presents several fundamental principles, strategies, philosophies and mistakes and than goes to present a set of very important best practices. I highly recommend it!

A major disappointment after reading Code Complete. A lot of repeating and unnecessary/obvious information. It could have easily been half the size.

While I enjoyed reading much of this book, and it had excellent advice, I found much of it only applying to project managers and other management with the ability to really effect change. As a lower level developer, there's not a lot I can do with the information in this book, but I think it's relevance will increase ten fold as I progress through my career, hopefully saving myself from making many mistakes on the way.Overall it was a nice easy read, but beware that it won't be very applicable early in your career.

I read this for the UVa McIntire MS MIS (now MIT) program in 2001. I still use it, and enjoy giving copies to my colleagues. This book will only become irrelevant when we stop making Classic Mistakes.

It might be somewhat dated, but it was well worth the read.It had a lot of meat to the book.I would recommend Team Lead's read this to give you some extra ideas about managing your development team.

I didn't finished the book so maybe it has something at the end.The fact of the matter is. This book is outdated. It is only useful in the archaeological sense when you want to review the failed waterfall methologies of the 1990ies in comparison with the new methologies of the 21th century.IBM, Microsoft, Apple and the rest of the world have, since then, moved on. Taking on Lean manufactoring and Scrum as industrial standards for developing software.