Reviews

• Software Project Survival Guide

  This book was initially loaned to me by my IT specialist when I came to him with problems I was having with a software product whose development I was overseeing. I wish I'd read it at the very start of the project---it would have saved me much anguish.

• I've read this book a long time ago, but the remembering is good

  I've read this book several years ago, in 1998, I think. It was my first glimpse on software project planning. At the time, I was a bit confusing, the book has a lot of examples of very big projects. But the best practices it provides are useful until today.
  
  Don't know if it's a good book nowadays, but it's definitely a book I won't forget.

• A must for project leaders

  The book presents an analysis about the project management in a very practical way.
  
  In it, Steve demystifies that in a project the "well" and "fast" are in opposite sides. By contrast, him tells us that for do it fast and cheap, it is essential to do it well.
  
  A project leader should have it in his desk.

• well-researched

  I'm a one-man database development shop at a nonprofit with a shoestring budget. Without the benefit of senior level programmers, I've had to learn most of my software engineering lessons the hard way- by experience.
  
  I picked up this book seven years into the job, which in retrospect was about seven years too late. In some respects, this book repeats lessons that that have already become obvious through experience (e.g., software testing needs to be performed separately from development). But, this lends credibility to my judgment, and provides new insights substantiated by software engineering research studies. Non-technical management and funders are responsive to the hard figures I often find myself citing from this book. For example:
  
  1) Programmers are 2.5 times more productive in a quiet office vs. a cubicle- so, I need to be allowed to work from home
  
  2) The most efficient programmers are 10 times more productive than the least efficient programmers- really, you would think this would be obvious, but when work needs to be contracted, the low bidder is not necessarily the best choice over the long haul
  
  Currently faced with my most substantial and challenging programming project yet, I'm essentially using this book as a cookbook to process. Upfront I was a bit overwhelmed with the scope of the project. Having finished the book, I have a well-defined process in place, am confident this will get done, and feel I am much more articulate describing the stages of software development to management and contracted vendors. Some presumably industry-standard strategies are proving invaluable- implementing a Top Ten Risk list to ensure that major barriers are addressed upfront rather than deferred, creating specific milestones, etc.
  
  This book (or an equivalent) should absolutely be mandatory for anyone about to take on their first major software project. It is most useful because it reads like a cookbook- guiding you through all the phases of software development, one after the other.

• The presented methodology is good but...

  will the book be convincing enough for you to adopt it?
  
  I have not found this book very fun to read because of its very structured and academic format. I have not learned much from it as much of its content is general wisdom that anyone with many years of experience in the industry has probably seen around before. Something positive I can say about the book is that I totally adhere to the methodology explained in the book. In my software development career, I have experienced myself the benefits of applying similar software development management methodology and I have also seen the negative consequences of not following it.

Read all reviews...