Rating: 
Summary: Prepare Yourself, or Become Yet Another Casualty
Review: Boy, I wish I had read this book a long time ago. Who would have thought that so much about the hidden forces that shape technology development projects could be explained in just 200 pages?I found this book credible, useful, and a fun and easy read. It's a little bit cynical and short on solutions, but that's hardly a criticism -- if you're on a death march project, you lose. For example, you really need to make sure that the reward for heroic success isn't another death march. How you do this isn't exactly clear, but if you're not confident about it, then it's probably time to take a permanent vacation. One serious flaw is the failure to mention that left to their own devices, *most* death march teams will decide that there isn't enough time to plan or to test, as if somehow magically neglecting to do so won't make the project even later. The project manager needs to make sure that this doesn't happen. If you read "Death March," then you probably ought to also read "Rapid Development" (McConnell) for balance. Nonetheless, if you're a project manager or a project team member with more than a year of industry experience, then you'd be foolish not to read this book.
Rating: 
Summary: Accurate But Not Practical
Review: This book gives you a very real life understanding of projects. This is a book for project managers who are faced with the impossible. Death March projects seem to be the norm in the software industry. This book explains about how Death March Projects comes about, and how to survive it. While reading this book, I always found the examples given are very realistic. But this book does not offer solutions for people involved in Death March situations. There are no silver bullets here.
Rating: 
Summary: ADVICE FOR ED: RETIRE!
Review: A few years back, Ed was so hard up for cash that he wrote a book called "Time Bomb 2000!" in which he predicted the end of civilization. This silly prophecy only served to expose Yourdon for the fly-by-night, fast-talking, hourly-rate, con artist that he is. In other words, Ed completely undermined his reputation with every CIO in the industry. My guess is that, on 1/1/2000, Ed was hunkering down in his survival retreat, drinking his bottled water, and wondering where in god's name his credibility went. Given that his career as an oracle was cut short, Ed decided that he'd stop predicting the future and start cashing out on the 9/11 mania. Just like any talk show host or stand up comedian, Ed found ample material to make a few bucks off of the hysteria. He demonstrated the kind of initiative that would make Jeraldo Rivera proud. The goal of this book is to keep Ed's name in circulation, so that he can charge a few more dollars for his worthless consulting services. Perhaps he'll use the royalties to refinish his deck or replace the transmission in his aging sports car. Ed's not going to tell you anything you don't already know, he's just going to make you think he will (which is the trick he uses to get you to buy it). This leads me to think that I need to write Ed a letter... Dear Ed, Hello there little trooper. Isn't time for someone to pack it up and call it a career? Wouldn't the whole industry benefit if you took your fat, wrinkled, mug out of the public eye. You pretty much admitted, in DeathMarch, that structured analysis was a crock. Face it, old man, you're over the hill. You've got no good ideas left. You're so desperate for ideas that you're reprinting Deathmarch. What are you going to do next time, reprint Time Bomb 2000! I think you've fooled enough people out of their money. You've had your fun, Ed, now retire to Boca Raton and give us all a well deserved rest. Please, Ed, pretty please. Your Pal,
LLNL Engineer
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).
Rating:
Summary: ADVICE FOR ED: RETIRE!
Review: A few years back, Ed was so hard up for cash that he wrote a book called "Time Bomb 2000!" in which he predicted the end of civilization. This silly prophecy only served to expose Yourdon for the fly-by-night, fast-talking, hourly-rate, con artist that he is. In other words, Ed completely undermined his reputation with every CIO in the industry. My guess is that, on 1/1/2000, Ed was hunkering down in his survival retreat, drinking his bottled water, and wondering where in god's name his credibility went. Given that his career as an oracle was cut short, Ed decided that he'd stop predicting the future and start cashing out on the 9/11 mania. Just like any talk show host or stand up comedian, Ed found ample material to make a few bucks off of the hysteria. He demonstrated the kind of initiative that would make Jeraldo Rivera proud. The goal of this book is to keep Ed's name in circulation, so that he can charge a few more dollars for his worthless consulting services. Perhaps he'll use the royalties to refinish his deck or replace the transmission in his aging sports car. Ed's not going to tell you anything you don't already know, he's just going to make you think he will (which is the trick he uses to get you to buy it). This leads me to think that I need to write Ed a letter... Dear Ed, Hello there little trooper. Isn't time for someone to pack it up and call it a career? Wouldn't the whole industry benefit if you took your fat, wrinkled, mug out of the public eye. You pretty much admitted, in DeathMarch, that structured analysis was a crock. Face it, old man, you're over the hill. You've got no good ideas left. You're so desperate for ideas that you're reprinting Deathmarch. What are you going to do next time, reprint Time Bomb 2000! I think you've fooled enough people out of their money. You've had your fun, Ed, now retire to Boca Raton and give us all a well deserved rest. Please, Ed, pretty please. Your Pal,
LLNL Engineer
Rating:
Summary: Perfect in a good economy. Waiting for new advice in 2 Ed.
Review: This book by best-selling author Edward Yourdon is aimed at giving advice to everyone on a software development team on how to survive "Mission Impossible" projects. The underlying assumption behind this book is that in the worse case scenario, you can quit your job and move to another company. This strategy worked during the boom economy of 1997 through mid 2000. But since 2001, it has become increasing difficult to take this stance. I am hoping the author will address these issues as applicable to the current environment where you can be out of a job for a year or two if you don't toe the line drawn by the powers that be. Anyway, keeping this dangerous assumption in mind, this book provides a good insight into why these 'death march' projects happen and what you can do about it. These difficult projects are defined as "a forced march imposed upon relatively innocent victims, the outcome of which is a high casualty rate". The conditions usually involve one of more of the following - highly compressed schedule, reduced staff, minimal budget, and excessive features. This short book starts off with an introduction to why these bad projects happen in the first place. The topics of politics, negotiations, people in death march projects, processes, tools and technology, and death march as a way of life. These are the various chapters in the book. As you can tell by the title of the last chapter, the author believes that death march projects are really the norm and not the exception so we all need to learn how to handle them. If you don't have much time, the author recommends reading the concept of 'triage' discussed in Chapter 5: Processes and I thoroughly enjoyed reading this chapter before going back to the preface and the rest of the book. There are some very interesting personal notes by the author at the end of each chapter that are really worth reading. Even though the author claims that he is being serious, the book is very humorous throughout. Of course, it is easy to laugh if you are reading this book at a time when you are NOT on a death march project. In chapter 2, five typical political players of a death march project are identified - owner, customer, shareholder, stakeholder, and champion. There is then a discussion of each type. If pressed for time, read pages 52-59. In chapter 3, a few of the familiar games are discussed - doubling and add some, reverse doubling, guess the number I'm thinking of, double dummy spit, spanish inquisition, low bid, gotcha, chinese water torture, smoke and mirrors, and finally hidden variables of maintainability/quality. If pressed for time, read pages 80-85. In chapter 4 about people, on the topic of team building issues, 8 project roles are talked about - chairman, shaper, plant, monitor-evaluator, company worker, team worker, resource investigator, and completer. The 7 practices that lead to 'teamicide' are also addressed - defensive management, bureaucracy, physical separation of team members, fragmentation of people's time, quality reduction of the product, phony deadlines, and clique control. The four stages of team gelling are pointed out - forming, storming, norming, and performing. These four stages are discussed in various other books also. My favorite chapter is on Processes (chapter 5) where the concept of 'triage' is discussed as applied to software development projects. Don't miss this chapter. Chapter 6 is a very short chapter on tools and techniques that most of us may already be familiar and if not, read this chapter as it is a good discussion on how right tools can affect your success positively. I felt the last chapter was more of a philosophical discussion of death march projects being a way of life and what to do about it. Overall, this book is a must-have even if you are a veteran to the software development field. Don't forget to check out 'Rapid Development' by Steve McConnell that is a much heavier treatise on software development and the various success techniques. The author of 'Death March' - Edward Yourdon has a website with his last name as the URL with the latest information on this subject. As I mentioned in the subject line and at the beginning of this review, there is a risk in following this book in this weak economy that could prove especially dangerous for IT professionals ultimately resulting in a spot in the unemployment line. Since it is so close to the publication of the second edition, the author has removed the manuscript chapters on this new release. So I am not really sure if he has a new philosophy for this type of an economy in the upcoming second edition. I would recommend waiting for this second edition. Good luck!
Rating: 
Summary: Essential reading for all involved in software development
Review: I recommend this book for anyone involved in the software development process - although this book is essential reading for software developers, it is also important that project managers read this book. A team consisting of software developers reading this book, and a naive project manager, is similar to a "death march" marriage where one spouse goes to a counselor, and one does not. I stumbled upon this book while working on my third major software project, and reading it greatly increased my understanding of the people issues which existed on that project. The "notes" section at the end of each chapter is especially good, each of which contains very pragmatic information. As a current computer science/software engineering graduate student who was encouraged to read "The Mythical Man Month" by Brooks upon entering the field during the last decade, I believe "Death March" is an essential accompanying text to Brooks.
Rating: 
Summary: Little new information...
Review: Chances are, anyone who's reading this book is on or has been on the very "Death March" projects it describes; I know I have. As such, the book reads not so much like new information, but rather like a conversation around the watercooler. "Should have bailed on that project," "Try to get all the 'must have' functions complete," etc. The upshot: While this book is affirming of the ad hoc insights all developers make as we go along, nothing's particularly revolutionary here. If you've survived one "Death March", you have these lessons hardwired into your brain:
1) Understand the politics of your organization
2) Don't use risky, not-ready-for-primetime technologies
3) Prioritize your function and drop fluff as necessary to meet your targets.
4) If all else fails, quit. That'll teach 'em. Overall, there are some valuable insights, but I wouldn't waste my money.
Rating:
Summary: Aberration or S.O.P.??
Review: The longer I work in the IT field, the more books like this become more valuable. It used to be that 30%-40% of the projects that I worked on would be "Death Marches", now its around 70%. The political games, personality problems and poor planning issues are all covered in this book plus ways to handle them. I recommend this book to anyone who has to work in IT, or manage any type of project.
Rating:
Summary: Not as good as I expected
Review: This is a good, quick read on an interesting toppic. A lot of relevant anecdotes from some experienced engineers, but it wasn't as useful as I hoped. Sometimes, quitting is not the answer! I was really hoping for a "prescription." There are enough useful tidbits and soundbites here to be worth the read, however, and it's a great introduction to other similar writings (many referenced within).
| 
