Reading the Classics: A Review of Rapid Development
I recently finished Rapid Development which I half-jokingly refer to as an encyclopedia of software development practices. That might seem unfair but I mean it as a compliment. I actually tried to read the encyclopedia when I was around 12 because I was so impressed with it. I think I made it up to the Bs before I went back to watching G.I. Joe. A less loaded way to describe this book is as a treatise on software development. McConnell obviously put a lot of effort and systemic thought into this book. One of the reasons the encyclopedia comment is only half joking is that the references and bibliography are thorough throughout the entire 600 page book.
McConnell is probably best known for Code Complete 2. That book cover how to code well in a similarly encyclopedic manner. Code Complete 2 is a lot more applicable when you first start developing (although there are other books I recommend for college hires). Rapid Development is more useful when you’ve been doing it for a few years. I was reminded of it after running across Coding Horror’s article that mentions it called “Getting Off of Gilligan’s Island” and decided to pick it up.
Summary
The first 100 pages (part 1 Efficient Development) is about how to develop software efficiently and rapidly. To develop software rapidly means different things, increasing speed, decreasing risk and increased visibility to business owners are all dimensions to rapid software development. And at some point you have to make trade-offs between these types of rapidity. The other big takeaway from this section is that developing software successfully is more about not screwing up than doing one thing really well. He actually has a checklist of common mistakes (which can be found online here) that lead to projects being delayed. If you make any of the common mistakes then the project is likely to be delayed or fail.
He groups the problems into four categories peoples, process, product and technology. Even when the book was written in the early 90s the people and products category had three times more problems than technology and product. Since then the ratio has become even more skewed. Technology problems are the ones we concentrate the most on because they are the most comfortable for us to solve. But we often to don’t notice people or process problems or just accept them as the cost of doing business. The checklist was what initially got me interested in the book, and it was nice to see the reasoning behind each item on it.
The second section is the meat of the book and covers in detail the areas that affect development speed. He covers every topic that can affect it from estimation, to teamwork, feature control, life cycle planning, etc. Each of these topics gets between 20 to 50 pages, with an extensive further reading section at the end of each chapter. These chapters are designed for people to skip parts of so if you find a certain section dragging it’s easy (and even encouraged) to go to the next one. If you want a fuller understanding of all the issues related to developing software on time though it’s worth reading every chapter. A nice thing about the encyclopedic nature of this book is that each section will reference the other related sections. This means the book is set up for wiki-walk style reading, once you find an issue that you’re interested in you can jump into the related topics and those topics have related topics, etc
McConnell finishes with some rapid development practices that can be used to improve the different dimensions of rapid development (speed,risk,visibility). These practices can be used together or in a alone and McConnell lists the pros and cons of each. Getting your team to do “Voluntary Overtime” for the project will get it done much faster but has a high chance of burnout. A lot of these practices seem to be standard practice if you’re doing some form of agile, although they may go by different names. One I had not seen before that seemed especially useful was having the developers maintain a top 10 risks list for a project.
Conclusion
This book was an interesting mix of (current) best practice, dated ideas and timeless advice. At almost 20 years old that is to be expected but it still threw me for a loop. When the book goes on about the importance of source control, nightly builds, and iterative design I had to remind myself that those things became standard practice in part because of this book. In that way it is a victim of its own success. Other parts like hearing about 4GLs and RAD just reminded me that the next big thing can fall to the wayside quickly. The parts of this book I found most helpful were the parts on estimation, feature scrubbing and development styles. Good technique in these categories has not changed huge amount. Process and people change slower than product and technology.
This is a book I would recommend to a developer with two caveats. One it covers the people and process topics amazingly in depth and you should concentrate on those parts. The product and technology part seem to have aged the poorest and the advice in it may be out of date so you may just want to skim them. Secondly some of the process suggestions felt specific to shrink-wrap software. Which has different maintenance and development costs than web development. It’s still worth reading and if you can’t read the book at least print out a copy of the checklist of common mistakes, laminate it, hang it next to your Kanban board and think about if you’re making a mistake on it every day.
