Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects (Yourdon Computing Series)

Rating:
Summary: Has this guy been following me....
Review: My boss gave me this book yesterday. Because of its title, it was intended as a joke about a "death march" project that finally died. Started reading it, and thought "My god... This guy has been watching my career!!" Unfortunately, the project mentioned is alive and suffering again today (The Death March project that won't die!!) With this book, I now have a renewed hope that I may survive it

Rating:
Summary: How to Survive & Succeed in Software Development Projects
Review: Although, written for software developers and project managers this book is apropos for anyone working to mobilize organizational change. Yourdon recognizes several important points: we can't win in every situation, regardless of how rational we pretend to be - projects tend to get behind and go over budget, to watch out for the big "ism" of the 90s - cynicism - we just don't live in an ideal world, and yet with preparation and tools like triage a death march doesn't have to end in disaster. If you've been toiling away at the "project from hell" this book is your survival guide and offers plenty of advice.

Rating:
Summary: A good desc. of the sources of App. Developers stress
Review: I read the drafts that Ed posted on his web site. The book discusses all of the dynamics associated with "deathmarch" style projects. Significant amounts of good standard practice and advice to help you recognize when you are headed for a Deathmarch. A must read to help you recognize the difference between when you are being asked to work on a challenging project (something we all want) and when your being asked to strap on the boots and walk off to oblivion. A recomended read for those who always wonder how they wind up in situtations where they come home late from the office and find dinner cold, or not there at all

Rating:
Summary: Ed's survival strategy misses the mark for embedded systems.
Review: Yourdon's descriptions of the corporate culture and circumstance that lead to "Death March" projects demonstrate clear insight into current software project management practices. However, some of the survival strategies are specific to software systems that are not complex in their implementation. Throwing out methodologies and design processes can only be done on systems where the implementation itself is not complex, such as a client/server database application. The system is complex, but the code is not. My 15+ years of experience in embedded real-time systems with very complex and challenging software solutions leads me to believe that the only way to succeed in a "Death March" is to do as much rigorous top down design as possible and push out the "combat coding" as long as you can. In this arena the methodologies save you from the "Death March". The commenter from a company in Montana pointed this out and mid-stream Yourdon had to slip in an abrupt recommendation to not really discard design methodologies. This appeared about 2/3 of the way into the book. I personally have been very successful in avoiding Death March projects by applying the methodologies that Yourdon, DeMarco, Ward, and Mellor pioneered and that Yourdon now says to discard to get projects done faster. In my last large project we shipped a new system five months early on a 17 month schedule through rigorous use of Structured Analysis and Structured Design (that is the methodology that the bureaucrats force us into and it works).