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

Rating:
Summary: Death March Got Boring
Review: This is a reality check for those contemplating or embarking upon a death march. Evaluate the situation before making the decision to join a death march team. Consider the personal and professional sacrifices. The introduction is too long, I sat the book down several times.
The book contains relavent information, and should be required reading for undregraduate and graduates, but perhaps a condensed version. Hopefully the students will have instructors that will assign section in order to cut down on the repetition.

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).