It's rare that I get excited about a computer book that has no hexadecimal numbers in it, but this is a good one. No, it's excellent. The subtitle is Managing ``Mission Impossible'' Projects and that's just what this book is about. Almost everyone in the computer industry has noticed their workload increasing, while at the same time the deadlines imposed by their supervisors shortening. A large percentage of this workforce has already participated in such a project and most of the rest are likely to before the decade is out. Demands for qualified individuals, the amount of money at stake in the computer industry, and the constraints of working on "Internet time" have lead to a showdown of corporate bottom line vs. personal sanity. This book is your guide on how to deal with it.
Yourdon starts out the book describing what a Death March project is and explains why they happen and why people participate in them. The book then goes on to cover such significant topics as how a Death March project team leader should negotiate with management for budget, working conditions, staffing, etc., how to handle the day to day issues of working on such a project, and, just as importantly, when to know when it's time to get out.
I found this book to be remarkably refreshing in dealing with the true issues of working in these sorts of environments. This book is far more practical than I expected. It would have been easy (and entirely expected) for an author to say, "It's tough using a new formal process approach under such circumstances, so try not to." But Yourdon goes on to explain how to decide if a new system is appropriate for a Death March project and how to negotiate trying to get out of using it when it's not. This remarkably utilitarian approach pervades the whole book. It is clearly written by someone who has "been there" and has no use or time for trite answers.
As another example, Yourdon, talking about what to do when negotiating working conditions necessary for successful completion of the project fails, "It's important to realize here that I'm not recommending resignation as a form of punishment or revenge, It's simply the rational thing to do when faced sith an impossible situation,... ." This is a sort of personal honesty missing from the majority of books on computer careers.
The book focuses heavily on the aspect of Death March projects being programming projects, despite the fact that these sorts of issues can apply equally well to other computer professions or even completely different careers. For example, it's not much of a stretch to consider a team of accountants from the finance department with one week to completely clean up the books before an audit to be on a Death March project. I think it would have been interesting to see some of the examples in the book extended in this manner.
This book was written with a great deal of collaboration from Internet denizens, regaling Yourdon with tales of woe and success, though mostly woe, from their own experiences. This has lead to a depth of coverage I wouldn't expect for a first sojourn into a topic. Nonetheless, there are few things that could have been considered that weren't.
For example, Yourdon lists many reasons why someone may agree to sign up for a Death March project, but one I find notably absent is that completion of a project, such as building a new set of class libraries, building a new distributed data system, or some other internal project, may lead to reduced work ahead. Also, there is probably a great deal of material to be written on the concept of having to complete, continuous small projects over a very large span of time, as one might in, say, a Web page design outfit. These pose different but similar stresses and strains on the human psyche. It will be interesting to see what new issues will be addressed in the almost certain 2nd edition.
On the whole, this book is excellent at covering its topic. It is certain to elicit thousands of thoughtful debates all over the world. At the very least, it will provide a great deal of practical advice for those "on the march" right now, as well as providing at least some measure of relief by letting the participants know that they're not alone. Expect many thousands of copies to make their ways to personal bookshelves all over Silicon Valley and the rest of the Internet world.
This book covers a critical topic in today's computing world in a thorough, insightful, and significant manner. Certainly anyone working, or about to work, too many hours in the computing industry must read this book. Everyone else either in the industry or on its periphery should read it. This is a very significant work.