Rapid Development: Taming Wild Software Schedules by Steve McConnell

Rapid Development: Taming Wild Software Schedules 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.
• 
  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.
• 
  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.
• 
  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.
• 
  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.
  
• 
  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.
• 
  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.
• 
  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.
• 
  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....
• 
  Doug

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

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

  Loved this book. Wonderful content presented well. A must read for IT services providers to improve customer delight and avoid schedule slippages.
• 
  Jesse

  solid book so far.