Rapid Development: Taming Wild Software Schedules

by Steve McConnell

A fundamental software engineering project management guide based on the practical requirements of "Taming Wild Software Schedules". Emphasizes possible, realistic and "best practice" approaches for managers, technical leads and self-managed teams. The author emphasizes efficient development concepts with an examination of rapid development strategies and a study of classic mistakes, within the context of software-development fundamentals and risk management. Dissects the core issues of rapid development, lifecycle planning, estimation and scheduling. Contains very good and practical discussions of customer-oriented development, motivation and teamwork. Explains such fundamental requirements as team structure, feature-set control (the dreaded feature creep in every project), availability and use of productivity tools and project recovery options. Relevant case studies are analyzed and discussed within the context of specific software development problems. Over 200 pages in this publication are devoted to a summary of best practices, everything from the daily build and smoke test, through prototyping, model selection, measurement, reuse, and the top-10 risks list.

This publication is definitely recommended and will become a classic in the field, just as the author's prior publication, "Code Complete" already is.

Genres: Programming, Software, Technology, Management, Computer Science, Nonfiction, Technical

672 pages, Paperback

First published January 1, 1996

Reviews

[Jim Butler]

How can I add any value to the multitude of reviews that obviously say "You must buy this"?
When I was working 80 hours a week - this was the only book I read cover-to-cover.

When I lent my book to one of my staff and he left the firm, I bought another copy off the shelf within 24 hours (I couldn't wait for Amazon's delivery time). This was after having read the book twice.

This is the only book I have bought 3 copies: one for work, one for home, and one to share. It's the only book which caused me to specifically make a trip to the bookstore to get a signature and hear a writer speak.

This is the 2nd of McConnell's books I've read. Code Complete was great. I couldn't believe anything could be better but this book is it. It repeated a few facts and figures but it's worthwhile to have it reorganized and re-presented for a different view. This book has led me to be a confirmed McConnell reader. His other books are good, but this is his best. Unfortunately, my expectation is so high now that his subsequent books are not impressing me as much.

Because of this book, I will attend my second course from his company - even if it means flying into Seattle's rain. One book and he's hooked me for literally a thousand dollars - that's an effective writer!

[Matt]

I think this book is really showing it's age. McConnell's advice feels genuine, but the data is based on experiences from the early 90s. A lot has happened in the software world between then and now so there are many things that don't fit with some of the best practices that modern development embraces. Unless you're staying on top of how companies do development today, it's hard to filter out what is outdated advice versus what is still relevant. Therefore, in spite of the book having some good information, I can't recommend it strongly because uninformed readers might be lead astray by practices that have proven themselves to be fads (I'm looking at you, JAD) or are just mediocre advice.

[kar-kar]

Эта книга посвящена организации процесса разработки программ. Она написана для людей, цель которых создать программный продукт максимально быстро. Автор рассматривает общие, философские идеи быстрой разработки, классические организационные ошибки и эффективные методы повышения скорости разработки.

В книге нет советов по написанию кода. Несмотря на это, мне, как простому программисту, который в основном пишет код, правит баги и лишь изредка может повлиять на процесс разработки, она очень понравилась. Идеи, изложенные в книге, придают смысл происходящему вокруг, помогают лучше понять коллег и заказчиков, объясняют важность планирования и формирования правильных ожиданий у всех заинтересованных сторон.

Автор приводит множество ссылок на источники утверждений и фактов, описанных в книге, чем дает понять, что данная книга это не очередное очень важное мнение одного человека, а скорее исследовательская работа, на основе сотен книг и личного опыта. Читается легко, во многом благодаря умению автора подобрать простые слова, продуманной структуре книги, а так же наличию учебных примеров - вымышленных историй о проектах.

[Toby Reiter]

This book is as much about psychology as it is about specific IT techniques for rapidly developing applications. Many of the books lessons focus on managing expectations, avoiding common political and personal pitfalls during the development process, and anticipating and controlling change.

For developers, this pairs very well with Code Complete.

[Nathaniel Inman]

RD is not a methodology but a set of practices that can coexist alongside agile teams to help deliver product faster while adjusting one of the four dimensions of development speed: people, product, process or technology. While it sheds light on helpful tools it's controversial foundation on antiquated COCOMO practices for estimation or occasionally outdated take on tools and industry best practices limits its credibility. My page tabs are on 8, 11, 22, 58, 84, 126, 222, 284, 329, 376, 403, 481, 503 & 559.

[Ben]

Two stars for readability and concise writing, three and a half stars for content. The content is quite good, but in attempting to be comprehensive, the book ends up being excessively verbose. A more well-organized and edited version of this book might be a third the length and cover all the material more effectively. The "case studies" were the most painful part as they felt artificial and contrived and rarely provided insight the text had not already clarified.

[Emily]

I probably wouldn't have read this book if I hadn't been assigned to read it. It is written for software developers, but I believe that any project manager could learn a lot. This book has really opened my eyes.

[Nathan]

Great book on Project Management. This book was required as in college and I was fortunate this book was assigned as a read. Great concepts on managing expectations, dealing with business politics, and delivering projects.

Worth the read.

[Dax]

I thought this was a lot better than (the more famous) Code Complete by the same author, and perhaps the best software engineering best-practices book there is.

[Robert Kennedy]

I don't think this has aged as well as Code Complete, but still has a ton of great insights. I would love to see an updated version written in the age of iterative delivery.

[Scott Pearson]

For decades, the classic project-management challenge has been to produce software quicker with more features and less bugs. Software, however, has its revenge because scheduling it accurately and precisely is a highly inexact science. Even the best, seasoned estimators struggle at first attempt. This book by Steve McConnell, though written 30 years ago, gives communal sympathy towards development teams who can seemingly never meet a deadline. Further, he actually provides some answers on how to mitigate those human problems distracting from developing code quickly.

This book is not nearly as paradigm-shifting as McConnell's Code Complete, but it does provide an overview of management scenarios that a tech lead or manager will encounter in their professional lifetime. Though the technologies change, the human side shifts more slowly. Many managers still don't understand many details of what it takes to develop software, and this book provides strategies to engage in that dialogue.

In the past 30 years, some of the problems have been subsumed by other paradigm shifts, like agile development. The problems remain, but the language is different. In fact, I struggled to find his entire section on Best Practices relevant today since modern strategies use different terminologies to address the same problems. But for the most part, the identified problems present similarly today. It's helpful to think through these classical situations - and the classical missteps attempting to address those situations.

Readers who always want "the latest and the greatest" out of a technology book will be disappointed, but those seeking relatively timeless wisdom out of a classic book will benefit. McConnell was one of the greatest software writers of his era, and this book hits home on the perpetual need for rapid software development. At over 600 pages, it's more comprehensive, especially on the human side, than even more recent books addressing similar themes. It's well worth a technological leader's time to understand how to avoid pitfalls ahead of time in a software project.

[Summa Smiff]

Probably the best software development guide I've ever read. The main focus is on how to develop software quickly, although, unlike many manuals on the Agile methodology, et al, sometimes focuses on other goals (and how to identify which goal is right for your project). Some of those goals being: increased project status visibility, less defects /bugs, or higher overall quality. The concept of increasing project visibility being what stakeholders actually want in many cases was a lightbulb moment for me.

Hard to believe this book is over 20 years old - some of the techniques were brand-new to me, and identify common errors made by developers and management alike. Don't let the size of this book dissuade you from reading it - the book is well organized into small chapters that demonstrate the efficiency you would expect from a subject matter expert.

[Mingyang Li]

How does the book relate to me myself?
“Beware of adopting new tools.” Yes, I’ve experienced strong curiosity, painful ramping-up, and sudden disappointment chasing the craze of many Markdown editors.
“Beware of adopting a 4GL.” Yes, I’ve tried VB, and still feel that Python is more productive.
“Changes in plans and designs should be made carefully and rarely.” I can’t tell you how many times in my research work I have found that I needed to re-clean the datasets in the analysis stage.
“Tap into developers’ inner motivation.” My manager has been very supportive for my personal growth, which indeed makes me feel appreciated and voluntarily wanted to work overtime.

[Diego Pacheco]

For the 1996 book - there are some still relevant things such as the Team models, classical mistakes such as (2) Weak Personal, (4) Heroics, (6) Noisy, Crowded offices (60% people hate offices - De Marco 1987) - this one resonates a lot with me :-), (8) Unrealistic Expectations - Still happens a LOT !!!! (29) Feature Creap. There are some things that are not problems anymore like lack of Source Control. Some of the Waterfall comparisons or tradeoffs, I'm not sure I agree but the author is not pro-waterfall for sure.

[James]

This book could have been one quarter of the size and still convey the same data. A decent read, but missing information on the latest software development fads. Steve Maguire's Debugging the Development Process is better.

[Julio]

Although some parts are a little outdated, the book is in general interesting to read. Some examples are too detailed and not really necessary.

It is curious that some of the techniques/processes described are the prelude to the agile methodologies that are nowadays spread among almost every software project.

[Tiger Abrodi]

Read it, and cut in the middle. The book isn't outdated but was written at a time when waterfall was extremely common.

You're MUCH better off reading the book "Clean Agile", skip this one, it doesn't provide much value after you've learned about agile.

[Mark]

Did not finish, but I enjoyed the portion I did read.

[Daniel]

Agile practices before they were called agile. In some topics the book shows its age, but it is still a good read, if you put in perspective.

[Anish K George]

May be Agile books made some parts of this book outdated. But topics like different team models, development strategies and best practices are eye openers even today.

[Darragh]

Excessively verbose and fairly dated, some interesting content though.

[Craig Cecil]

This book should be read, re-read, memorized, and used by anyone involved in the planning, management, development, or deployment of software. It's that good. Steve McConnell presents a succinct, well organized collection of the lessons learned and best practices in software engineering over the last three decades.

[Hasyimi Bahrudin]

Just got the book today. I'm pretty impressed with the book quality. Just a few flipped pages (for bookmarking) here and there. No stains (so far). No missing pages (so far). Pretty good deal for an awesome book!

[Ben Haley]

Another from the Art of Project Management which will be useful for the type of development we do at PERTS.

[Lauri]

Taming Wild Software Schedules is no joke....

[Michael Fruergaard]

680p- 01-02-2007

[Doug]

Seemed a bit obvious to me, but others have told me they really liked.

[Justin]

Top notch advice from a giant in the field. Any developer or manager who wishes to elevates their skills to true engineering needs to read this book, cover to cover.

[Lori Grant]

A should-read book on product development for knowledge workers and entrepreneurs.

[Lu Wangshan]

Comprehensive treatment of software development.