What do you think?
Rate this book
Death March
Historically, all software projects have involved a certain degree of risk and pressure -- but many of the projects in today's chaotic business environment involve such intense pressure that they are referred to colloquially as "death-march" projects -- i.e., projects whose schedules are so compressed, and/or whose budgets, or resource (people) assignments are so constrained, that the only "obvious" way to succeed is for the entire team to work 16 hours a day, 7 days a week, with no vacations until the project is finished. While the corporate goal of such projects is to overcome impossible odds and achieve miracles, the personal goal of the project manager and team members often shrinks down to mere survival: keeping one's job, maintaining some semblance of a relationship with one's spouse and children, and avoiding a heart attack or ulcer. This new and thoroughly-updated edition of Ed Yourdon's book takes into account many of the changes that have taken place in the more than six years since the publication of the first edition.
246 pages, Paperback
First published April 2, 1997
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 46 reviews
February 29, 2012
I read this one specifically because of a project I was on at the time. And I left it out on my desk for a month or so afterwards so that my manager had to see it every time he stopped by to ask dumb questions.
It spoke to me at the time. It confirmed much of what I knew was wrong with the project. But, it didn't have the magic bullet I was looking for. That probably wasn't fair to expect, but golly it would have been nice.
It spoke to me at the time. It confirmed much of what I knew was wrong with the project. But, it didn't have the magic bullet I was looking for. That probably wasn't fair to expect, but golly it would have been nice.
November 7, 2019
Overall a good book, you will learn few things from it, or at least it will be a good refresher, although it is not BRINGING any new ideas, WORTH reading.
July 21, 2018
The author stated that a lot of software engineering projects end up in failure and that this won't change much in the future. It's good to know why projects fail and how to lower the risk of failure. However, it's good to know that there are no silver bullets.
Typically, to improve the chances of success, it's not crucial to care about tools or particular technology. Often even financial bonuses to employees will not help (with the exception of avoiding takeovers from competition). What is more important is limiting the scope of the product, negotiating requirements (a lot of them can be relaxed or even rejected) and deadlines, caring about hiring right people, organizing frequent demos for customers and assuring daily and reliable project builds. (Of course, there are much more topics that are important).
Typically, to improve the chances of success, it's not crucial to care about tools or particular technology. Often even financial bonuses to employees will not help (with the exception of avoiding takeovers from competition). What is more important is limiting the scope of the product, negotiating requirements (a lot of them can be relaxed or even rejected) and deadlines, caring about hiring right people, organizing frequent demos for customers and assuring daily and reliable project builds. (Of course, there are much more topics that are important).
May 26, 2012
This review is probably going to be a lot like the one for the previous book - "Practical guide to defect prevention", so please have a look at that one.
Having been exposed to other literature in the past, this book did not teach me a lot of new things.
p.s. I found multiple spelling errors, even though this is the second edition.
Having been exposed to other literature in the past, this book did not teach me a lot of new things.
p.s. I found multiple spelling errors, even though this is the second edition.
December 29, 2016
re-reading this classics - very actual for my current projects...
main thing to do - abstract from technical details, and concentrate on the organizational stuff - it wasn't changed in 20 years since initial release of the book
main thing to do - abstract from technical details, and concentrate on the organizational stuff - it wasn't changed in 20 years since initial release of the book
December 18, 2021
Yourdon's key observation is that politics often plays a critical role in software development projects. It leads to decisions that seem irrational at first glance and can only be understood by looking at the specific and often selfish interests of influential stakeholders. Most other authors in the field ignore the role of politics, and Yourdon still is one of the very few who point out that many projects fail for political reasons. Where it happens, the powers that be usually try to hide their involvement by blaming the developers for the failure.
Sadly, Yourdon unexpectedly passed away in 2016 while he was working on the third edition of his book, which was due for publication in the same year. I would have liked to hear his views on topics like "Dark Scrum" (see Ron Jeffries website). Dark Scrum shows that politics in software development is all but dead.
Sadly, Yourdon unexpectedly passed away in 2016 while he was working on the third edition of his book, which was due for publication in the same year. I would have liked to hear his views on topics like "Dark Scrum" (see Ron Jeffries website). Dark Scrum shows that politics in software development is all but dead.
December 20, 2015
I read this the year I lived a death march project. Essentially, that's a project where you have too little resources in terms of time or personnel. Ironically, it was the most fun project of my career. We went down, but we went down together and in good spirits.
September 23, 2013
Every programmer should have read this once before getting stuck in a death march project. It is one of those skills that you better learn from a book or a mentor & not from experience. It might save you & may be even the project.
April 1, 2020
I have been working in startup environments since 2015 and the last 5 years I engaged in several categories of death march projects without knowing this term. This book is very acurate and what is most interesting it's dated around 1996 or so.
August 24, 2009
I was expecting a lot more; this is a well-reputed classic, but it didn't really cover much that isn't elsewhere in the literature.
Read
October 16, 2009Can't rate it as I read this book very long time ago. But I remember it been mildly entertainig and mostly unpractical. There is too much cultural difference.
August 3, 2007
Tedious and repetitive, no useful info.
March 8, 2022
It's tempting to view the whole book as a test to see if the reader truly internalized the primary lesson of Chapter 5 (titled Death March Processes), namely triage.
It started great, every page giving me all kinds of ammunition with which to compare the uglier aspects of the tech corporate culture to secondhand experiences I've heard about in an unrelated field. But it's very rooted in the moment when it was written. "Outdated" is not quite accurate, but there were a whole lot of references to new, cutting edge tech that has since become either forgotten or mainstream. The citations and references to personal email correspondence was amusing.
The last half or so was a slog. It was an easy-reading slog, but still a slog that took me a couple weeks to get through.
Right, so, triage.
Two quick comments (both positive, and both deriving from the latter half of the book, so take the preceding with a grain of salt) follow.
Chapter 7 ("Critical-Chain Scheduling and the Theory of Constraints") has a subsection ("What Organizational Behaviors are Dysfunctional") that describes how seemingly isolated events (eliminating a year end bonus) can cascade into something that threatens the project or organization (the highest performers are the most capable and hence most able to leave over the lost bonus, resulting in further decreased morale that ultimately pulls away all but the most incompetent personnel).
Chapter 8 ("Time Management") has a subsection ("Helping the Project Team Make Better Use of Time") that has a simple labeling (apparently appropriated from Stephen Covey's First Things First) of tasks along the axes of important and urgent. Again, this is simple, but its clarity provides some good perspective on whether it is worth responding to every email in one's inbox.
my favorite quote: "It means rewarding them handsomely if the project succeeds, but not dangling extravagant awards in front of them all through the project, for it will distract them."
It started great, every page giving me all kinds of ammunition with which to compare the uglier aspects of the tech corporate culture to secondhand experiences I've heard about in an unrelated field. But it's very rooted in the moment when it was written. "Outdated" is not quite accurate, but there were a whole lot of references to new, cutting edge tech that has since become either forgotten or mainstream. The citations and references to personal email correspondence was amusing.
The last half or so was a slog. It was an easy-reading slog, but still a slog that took me a couple weeks to get through.
Right, so, triage.
Two quick comments (both positive, and both deriving from the latter half of the book, so take the preceding with a grain of salt) follow.
Chapter 7 ("Critical-Chain Scheduling and the Theory of Constraints") has a subsection ("What Organizational Behaviors are Dysfunctional") that describes how seemingly isolated events (eliminating a year end bonus) can cascade into something that threatens the project or organization (the highest performers are the most capable and hence most able to leave over the lost bonus, resulting in further decreased morale that ultimately pulls away all but the most incompetent personnel).
Chapter 8 ("Time Management") has a subsection ("Helping the Project Team Make Better Use of Time") that has a simple labeling (apparently appropriated from Stephen Covey's First Things First) of tasks along the axes of important and urgent. Again, this is simple, but its clarity provides some good perspective on whether it is worth responding to every email in one's inbox.
my favorite quote: "It means rewarding them handsomely if the project succeeds, but not dangling extravagant awards in front of them all through the project, for it will distract them."
December 3, 2018
When I told my friends & coworkers that I’m reading a book about software engineering management called “Death March” they instantly knew what the book was about.
In this book Yourdon discusses through anecdotes, musings, and conversations with his industry peers aspects of a death march that help the readers make sense of the challenges they too know about. Yourdon offers explanations of why death marches occur, who are the agents that encourage & partake in them, what are the signs & symptoms of a death march, and possible negotiations and solutions for resolving a death march if you find one of your projects has devolved into one.
The book gives fewer answers than I would have liked, but surprisingly the biggest assurance Yourdon gives is that the death march is more typical & pandemic than it is unusual. Because Death March was written pre-2000 many of the tools and references seem outdated and do not address more recent software development methodologies like Agile. The writing also sadly shows its dated style and gives little to no data or detailed analysis like the CHAOS reports that would support the author’s fatherly advice and musings.
Still, Yourdon modestly succeeds to persuade the reader to have a more mature view that if a culture of death marches can be refuted in many cases for the reader and if not then coping strategies the reader can adopt to co-exist with them.
If you are reading this review or book I hope you find consolation in it and wish you the best in your situation.
In this book Yourdon discusses through anecdotes, musings, and conversations with his industry peers aspects of a death march that help the readers make sense of the challenges they too know about. Yourdon offers explanations of why death marches occur, who are the agents that encourage & partake in them, what are the signs & symptoms of a death march, and possible negotiations and solutions for resolving a death march if you find one of your projects has devolved into one.
The book gives fewer answers than I would have liked, but surprisingly the biggest assurance Yourdon gives is that the death march is more typical & pandemic than it is unusual. Because Death March was written pre-2000 many of the tools and references seem outdated and do not address more recent software development methodologies like Agile. The writing also sadly shows its dated style and gives little to no data or detailed analysis like the CHAOS reports that would support the author’s fatherly advice and musings.
Still, Yourdon modestly succeeds to persuade the reader to have a more mature view that if a culture of death marches can be refuted in many cases for the reader and if not then coping strategies the reader can adopt to co-exist with them.
If you are reading this review or book I hope you find consolation in it and wish you the best in your situation.
April 25, 2019
I do not recommend this book unless you’re simply reading it to read a classic.
The Good:
- This is the first book Ive read which acknowledges that projects fail. A star for that alone.
The Bad:
- I have never read a more cynical, depressing book about software engineering. A repeated suggestion is for the individual contributor or project manager to resign from the project and “management” are painted as Dilbert-esque sociopaths. The tone of the book is fairly evident from the title and it was a slog to read as a result.
- The examples and technology referenced are quite dated. References to CASE tools, “electronic mail”, and The World Wide Web are pretty fun to read about in 2019, but some of the specific suggestions don’t age well (or are already common practice in software development). Fine if you’re reading this to read a classic, less useful if you’re looking for up to date information.
- Yourdon discusses “project failure” often, but surprisingly never once describes how a project can be “failed gracefully” or what project failure actually means. This felt like a big oversight for a book about projects which are “doomed to fail”.
The Good:
- This is the first book Ive read which acknowledges that projects fail. A star for that alone.
The Bad:
- I have never read a more cynical, depressing book about software engineering. A repeated suggestion is for the individual contributor or project manager to resign from the project and “management” are painted as Dilbert-esque sociopaths. The tone of the book is fairly evident from the title and it was a slog to read as a result.
- The examples and technology referenced are quite dated. References to CASE tools, “electronic mail”, and The World Wide Web are pretty fun to read about in 2019, but some of the specific suggestions don’t age well (or are already common practice in software development). Fine if you’re reading this to read a classic, less useful if you’re looking for up to date information.
- Yourdon discusses “project failure” often, but surprisingly never once describes how a project can be “failed gracefully” or what project failure actually means. This felt like a big oversight for a book about projects which are “doomed to fail”.
November 15, 2019
Yourdon, Computer Hall of Famer, observed that that 60’s, 70’s, 80’s, and 90’s involved software developers being assigned projects with insufficient time, personnel, money, and precedent— new features, or advanced features. The result, a Death March. Suicide, divorce, and mental breakdowns were not unheard of. His prediction was that such a way of project management would continue into the 21st century. His tips on how to survive the industry are helpful, as they come out of his own experience as a consultant.
December 12, 2018
Не сказать что очень познавательная книга. На протяжении всех глав рассказывается что безнадежные проекты почти обречены, а если и нет, то в следующий раз точно. И что заказчики и руководство ничего в этом не понимают и говорить им бесполезно. Поэтому либо мучайтесь
и приспосабливайтесь, либо уходите. Так же подымалась тема «серебряных пуль» и что они не эффективны, особенно в жестких временных рамках.
В итоге, прочитать можно, но лучше потратить время на другую книгу.
и приспосабливайтесь, либо уходите. Так же подымалась тема «серебряных пуль» и что они не эффективны, особенно в жестких временных рамках.
В итоге, прочитать можно, но лучше потратить время на другую книгу.
April 1, 2021
Since I am probably also one of the people, who says the author is talking about my project, this book was interesting and somehow also discouraging. Reading quit is the only viable solution, if you don't want to go through it, because it might benefit your career.
The funny part of older books is always the hardware that was around during that time. Calling 200Mhz bleeding edge is something I haven't heard for a long time.
The funny part of older books is always the hardware that was around during that time. Calling 200Mhz bleeding edge is something I haven't heard for a long time.
March 11, 2019
Ужасно скучная, неинтересная, очевидная книга, еще и написанная, как учебник. Возможно дело в устаревании и неактуальности, хотя тема безнадежных проектов никуда не делась. Я осилил 30%. Не рекомендую читать - пустая трата времени
June 14, 2019
I really enjoyed this book as it resonates strongly with the work I was doing at the time!
November 10, 2019
Can't say i found this book useful. Very generic and all advice is based on simple common sense. Could be shortened by half
February 7, 2022
Good book on bad projects and best strategies possible if you got youself pulled in one of those.
March 9, 2023
Interesting approach. Useful mindset proposals not only for software development but for almost everything in life
November 23, 2023
I was really impressed by this book. It gives me a lot of context to understand management decisions
April 5, 2017
Боюсь, що я чогось не зрозумів, але в книзі ключові проблеми описані лише із сторони менеджера проекту, який в переважній більшості не приймає участі в написанні коду, а займається, хоч і не менш важливими, але іншими задачами. Тобто вирішення ось саме цих проблем, які і визначають описану безнадійність, зводиться до відстоювання менеджером необхідних умов розвитку проекту: терміни, бюджет, члени команди, нагорода. А ось що робити окремо взятому програмісту, залученому в цей проект - це вже суто його особиста справа. Хочеш - рви на собі все і працюй, не хочеш - йди.
February 11, 2016
Интересная книга.
Понравился взгляд Йордона на различные нотации. Он говорит, что они прекрасно подходят для объяснения и понимания, но абсолютно не подходят в динамичных условиях, когда всё ме��яется часто и быстро. И управлять с помощью всех этих нотаций становится невозможным. Я согласен с этой точкой зрения. Та же нотация UML отлично подходит для объяснения паттернов проектирования или архитектуры тех или иных систем. Но в процессе разработки всё довольно часто и радикально меняется. И каждое такое изменение требует отражения на диаграммах. В итоге скорость продвижения вперёд стремится к нулю. Поэтому неудивительно, что я и большинство моих одногруппников в университетские годы сначала писали программу, а уже потом рисовали блок-схему или UML-диаграммы. Мы тогда еще возмущались, что нам следовало бы делать наоборот. Сначала проектировать, а потом программировать. На самом же деле мы рисовали блок-схему с целью объяснить свою программу другим людям, а не для того чтобы использовать её как дорожную карту при программировании.
Понравился взгляд Йордона на различные нотации. Он говорит, что они прекрасно подходят для объяснения и понимания, но абсолютно не подходят в динамичных условиях, когда всё ме��яется часто и быстро. И управлять с помощью всех этих нотаций становится невозможным. Я согласен с этой точкой зрения. Та же нотация UML отлично подходит для объяснения паттернов проектирования или архитектуры тех или иных систем. Но в процессе разработки всё довольно часто и радикально меняется. И каждое такое изменение требует отражения на диаграммах. В итоге скорость продвижения вперёд стремится к нулю. Поэтому неудивительно, что я и большинство моих одногруппников в университетские годы сначала писали программу, а уже потом рисовали блок-схему или UML-диаграммы. Мы тогда еще возмущались, что нам следовало бы делать наоборот. Сначала проектировать, а потом программировать. На самом же деле мы рисовали блок-схему с целью объяснить свою программу другим людям, а не для того чтобы использовать её как дорожную карту при программировании.
June 7, 2015
I strongly disliked this book. I knew going in, as the title suggested, it would be a depressing topic, but geez, the reader is in for a slew of negative stories and thoughts on how to solve difficult projects. I realize the point is to help the reader cope with how to handle difficult projects where there is no way to really "win". But, after reading inspirational books like "The Mythical Man Month" and "Peopleware" in the past this book seems like one I wish I would have just given up on and shelved. Unless you are truly trapped in a "Death March" project with no way out and just need something to help you cope, I would move on from this book, or at least read the other two I mentioned first. There are much better ways to spend your time learning than to suffer through this book unnecessarily.
November 6, 2009
I have read the Polish edition:
http://atena.osdw.pl/ksiazka/Yourdon-...
http://a.swistak.pl/000/326/326955_10...
Good book, but I've read the 1999 edition, and felt some of the issues were a bit outdated. Lots of good suggestions and analysis that is still valid.
http://atena.osdw.pl/ksiazka/Yourdon-...
http://a.swistak.pl/000/326/326955_10...
Good book, but I've read the 1999 edition, and felt some of the issues were a bit outdated. Lots of good suggestions and analysis that is still valid.
November 19, 2009
A good book on software management culture and how it looks on the big picture when corp, business and sponsors are involved. A good overview of many concepts of what would soon become "Agile".
Not really focused on developers, it stands on the POV of the project manager most of the time, having little practical knowledge to be gathered by developers.
Not really focused on developers, it stands on the POV of the project manager most of the time, having little practical knowledge to be gathered by developers.
August 8, 2014
I recommend it to all project manager just to read and recognize yourself :) The book doesn't give too revolutionary advice of how to lead such projects to a success (and they hardly exist) but at least helps to understand that you're not alone and gives some ways to identify such projects on an early stage.
Displaying 1 - 30 of 46 reviews