Slashdot Mirror
Death March
Background Ed Yourdon has a long and storied publishing history, most notably for his books on structured design and his duology (is that a two book series?) Decline and Fall of the American Programmer and The Rise and Resurrection of the American Programmer. Of course, he's better known recently for his (somewhat apocalyptic) Y2K books. This one, of course, is a couple of years old, but like most of the books I tend to gravitate to, addresses themes that endure. In this case, the desire to do more with less. The Scenario
Death March: [A project] whose "project parameters" exceed the norm by at least 50%. [The metaphor is used to suggest] a "forced march" imposed upon relatively innocent victims, the outcome of which is usually a high casualty rate. (2)Yourdon's definition, as related above, does not necessarily imply a long-term project (although long-term death marches are worse than short-term ones), but instead describes a project with a low rate of success and a high personal impact. The project is either underfunded, underscheduled, understaffed, overfeatured, or some combination of the above. The introduction deals with the reasons DM projects happen, and why people actually agree to work on them. Having been on one myself, I can say that "ego" is one of the major reasons.
The subsequent chapters deal with various facets of the death march project, and how those facets are unique in such a project. Chapter 2, politics, has an especially interesting section on identifying what type of DM project one is on, and the chances of success for such a project. Yourdon rates projects on a four-quadrant scale: low and high likelihood of success, and low and high happiness factor (giving four combinations). Suffice to say, there are good combinations, bad combinations, and worse combinations. :-)
Chapter 3 deals with an important part of any project, but one that is hypercritical for any death march project: negotiation. Needless to say, good negotiation can turn a DM project into an almost-normal project, while bad negotiation can turn a bad situation into a nightmare. Yourdon provides some excellent tips on how to deal with upper management in these situations, which should be useful even if you've negotiated for a standard project before. Clearly, management is going to be much less forgiving in a DM situation.
Chapter 4 deals with "peopleware" issues in death march projects. As with negotiation, nothing really changes from a standard project to a DM project, but everything is emphasized. If you have poor workspace when you're on a normal deadline, consider how that workspace will affect you when you're under extreme time pressure. Overtime, and the limits of such, are another important issue Yourdon deals with.
Chapter 5 deals with an issue I've addressed many times in my reviews: process. I greatly appreciate Yourdon's take on process in a DM project. Simply put, while the Methodology Police will make any DM project worse, the lack of process will completely destroy one. Don't try to do all the paperwork while you're cramming to get the software out the door, but abandoning process will insure your failure. Things like requirements management and configuration management are all the more critical on a likely-to-fail project. If you lose only a week to a requirements change, that might be a quarter of your schedule!
Chapter 6, tools, simply reminds us that technology will not solve the human problem of programming. No CASE tool or supercompiler is going to come along to write your DM software for you. Use what you are most comfortable with, and you'll be the most productive.
The concluding chapter 7 proposes an interesting scenario: what if death march projects were to become normal? That is, how do you live and work rationally in an environment that is irrational? Suffice to say, this impacts everything about a software team, including the people who are hired and how careers advance within the company.
Throughout the book, Yourdon includes some excellent footnotes taken from correspondence with various software practitioners. These email excepts, gleaned from a questionnaire Yourdon sent out about the book's subject, give excellent insight into the nature of a death march project.
Although few people actually want to be sucked into a death march project, it will likely happen to most developers at some point in time or another. Being prepared for the occurrence might well mean your survival of such a project.
What's Bad/Good I found very little to dislike about this book. The text is concise yet thorough. The presentation is excellent. The ideas are reasonable and well-stated. I find Yourdon to be quite moderate in his position, neither justifying death marches nor railing against them overly. The advice on this book could easily be applied to any sort of project, and in fact is fairly standard in the literature, only ramped up for an intense, death march experience. Very little has changed in the industry since this book was initially published, and I doubt its timeliness will cease anytime soon. So What's In It For Me? If you write software, or work on any knowledge team, you will likely face a death march project at some point in your career. This book will help prepare you to deal with, and triumph over, such an experience. Table of Contents Preface- Introduction
- Politics
- Negotiations
- People in Death March Projects
- Processes
- Tools and Technology
- Death March as a Way of Life
Puchase this book from Fatbrain.com.
While the Trail of Tears was certainly a classic example of a deathmarch, it was by no means the first (or the most brutal). It isn't even the most recent historically.
Of course, they probably don't cover that in the comic books that they gave you to help you spot "caucasian patriarchs."
Yes, this post is extremely offtopic. Feel free to mod me clean out of existence, but it ticks me off when someone justifies their racism with something that happened hundreds of years ago. None of the whites living today had anything to do with the trail of tears, and none of the Cherokee living today are particularly worse off for it. If it makes you feel any better, my ancestors were also driven across the American West (from Illinois to Bunkerville Nevada, Oklahoma is a paradise compared to that hole in the ground). Of course, since my ancestors were white Mormons you probably couldn't care less that thousands died along the way.
Learn some history before you spout off.
I read the book, and at one point he says that if there is one thing you take away from reading the book, it should be the concept of triage, which is abandoning the hopeless so that the viable can survive. That's a good attitude to keep in mind and you should perhaps have mentioned this ''one thing to take away'' in your review.
Also, the guy moaning about the native indians being disrespected (by disrespecting slashdot readers, calling them vaginas), the author takes care at the beginning of the book to point out he doesn't mean to draw parallels with terrible suffering of others, yet the metaphor with doomed projects on which people expend their time, good humour, sanity and in some cases actual lives is too good to pass up.
-Andy
Steve McConnell addresses that very fact in "Code Complete." Essentially, he says that no organization wants to spend the time to develop good software design processes until the need for them is obvious, but by that time, it's too late.
Put another way, an bit of prevention is worth a gig of cure. Or something.
I guess I'd have to say that I disagree 100% with your last statement. If all you're doing is fulfilling tasks that are placed in front of your face, how can you not become burned out? It's all a matter of taste, I suppose. Some people prefer mushroom-mode, others don't. I'm not talking about undying loyalty. I'm talking about seeing the big picture of an assignment, as opposed to being a mindless drone taking orders like a short-order cook & serving up code.
The main reason I'm not contracting now is that I chose to pursue more technical programming as opposed to business systems. Plus, I realized that as a contractor, my work would never scale - if I wanted to reap maximum rewards from my efforts, I am better off working entrepreneurally with a small group of people to produce a product than selling my services by the hour.
The biggest problem I see from slashdot regulars is this immature "us-vs-them" attitude towards 'managers' & 'hackers'. Guess what guys - everyone's a manager. You can't absolve yourself from management responsibility. Software is not feudalism, and you're neither knights nor serfs. Contrary to popular belief, most managers are adequate to the task. Problem is, so many of their managees want to contribute nothing to the process, forcing the managers to become super-human predicters of human behavior & politics, as well as technology. Since almost noone is capable of this, we get the 'bad manager'.
NineNine, considering that you sign you posts "Oracle God", I'd figure you'd have a little more perspective. I can see this myopic mushroom view coming from a hardcore C/C++ hacker who is given his little subsystem to produce & grinds away heads down until it's done; a database person, though should be about as close to a manager as you can get in the coding world - you have to have an almost complete domain knowledge over the problem space for the project & understand how everything is affecting your consumers. How can you not be a manager when you're tasked with organizing the single most important part of a system? (FYI, this is all coming from someone who is both DBA and a heads-down C++ hacker).
I worked at a company that wasn't a software development company, but a manufacturer of physical product. I had one project that was a promotion for a marketing department. I went through all of the steps of determing what they wanted out of the project, short-term and long-term goals, deliverables, timeline, etc. My group had the project done in about 4 weeks, during that time the Marketing sponsors of the project had been kept in the loop with beta builds, but at 'final' review by marketing, they came up with all sorts of new ideas for look and feel along with functionality, along with functions that we had never anticipated they would ever want. They refused to sign-off on the project and wanted all of their changes made, although most of them did not conform with the original specs.
This same scenario happened to a lesser degree, three more times before the project was finally sign-off (grudgingly) by the marketing sponsor.
I learned what to look for in the personality of the sponsor (both individual and group) and will never do a project for that type again. All the best planing wouldn't have saved us from that nightmare. The only saving grace would have been if my senior manager would have put his foot down after the first delivery and said the project meets the specs.
My next Slashdot post will be ready soon, but subscribers can beat the rush and see it early!
Yourdon was, sort of, the guy who wrote the scripture that taught me structured design. So I really give hime the benefit of a clue.
Death March Projects
Don't even get me started, about those high profile very political shit of real significance.Such projects are easy to detect, watch out for the following features:
There's about 3 metres (10 feet) of documentation. It's mandatory that one of the docs has a title, like Standards how to write Standards
The quality assurance team is of vital importance. After finishing your specs they go to the QA team, to settle dust for the next three weeks (despite the killer deadlines). Then you get them back with the Ts crossed and the Is dotted. You could write Macys famous cookie reciepe into the specs as long the Ts are crossed, etc (On a less cynic note, I believe QA is important, but mostly rottenly implemented).
It's mandatory for such projects to switch the implementation language from Cobol to C. That's one week before coding starts and a bunch of Cobol gurus (with no fucking clue whatsover about C) are assembled for coding.
The scapegoat element is of dire importance. Best is to import a group from Tasmania or Timbuktu. They don't necessarily need to have a clue, but senior project management needs somebody to point the finger after 75% of the timeline.
It is of vital importance to not only have one project sponsor, but three. Best if they hate each other like hell.
A clear project scope is a sure sign of success. Avoid it like the Jerry Springer Show, if you want a death march project. Ideally shift the scope once a month.
Yeah, there's a lot to be said for death march projects, and I sure as hell are gonna order Yourdons book. Should make me an expert in the field...
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
The Death March saps the energy of programmers. It increases the burn-out rate. It severely decreases the quality of the code. If the project survives, it's always because one or two "hero programmers" work their asses off writing untested spaghetti code that barely pushes the project into usefulness, not too far behind the deadline.
And we wonder why the software industry has such a wonderful reputation for quality.
There is a better approach, but it involves communication, something hackers can sometimes be bad at. You just have to learn how to push back. Start off with a good estimate. Make sure management knows it's only an estimate, and may change later. Drill this fact into them as a way of life, but at the same time, be _very_ inflexible that your estimate is the very best you can come up with at the moment, you're not going to chop a week off it just to fit in with a trade show.
If you're given an unreasonable demand, tell management it's unreasonable. If you think a job is going to take six months, say it'll take six months. Don't say three, and plan on overtime. Oh, and you're not Scotty. Don't say nine months, because next project, you'll have moved on, and _I_ will be left with a manager who expects miracles.
Keep track of how the project is going. Be as accurate as possible. Use some measurable criteria, don't just go around asking "how's it going?" Recently, one of the projects I'm working on slipped due to various problems - some our fault, some beyond our control. Because we'd laid the groundwork early, and because we were keeping close track of our progress, we could go to the project manager and say "Look, we're behind schedule. The new estimated shipping date is 'x'. This project won't sustain any more programmers, so if you want to ship earlier, you'll have to take out some functionality.
Phrase it like that, and you'll be amazed how reasonable people can be.
If you tell your project manager that you're behind schedule, and his response is "Work overtime", then go out the door and keep walking. This is the reason I left my last job, and I've never been happier as a result.
The result of avoiding death marches? Programmers are happy because there are fewer unreasonable demands. Management are happy because they feel they have control over the situation, and they don't get that feeling of palpable dread every time they go back into the cubicles and find everyone looking through job ads.
Charles Miller
--
The more I learn about the Internet, the more amazed I am that it works at all.
Theres always the "Mythical Man Month" another classic book that all software developers should read. You all probably have but hey someones got to mention it, and it really is still relevant today despite being over 25 years old!
;)
I'll probably get flamed for saying this but I read "The Project Survival Guide" by published by the evil empire and thought it was helpfull in expressing the disasters that can happen. Maybe that was because Micro$oft get more disasters than most
Seriously give it a read it may come from Micro$oft but like "Code Complete" its worth a read.
... who the hell can take this guy seriously?
Let's review his authoring history ... first, he writes a book ("...decline of the American ...") that basically says that programmers in America are dead, that "software factories" in Asia/Japan will replace all the domestic programmers, that COBOL programmers are dead and COBOL is a dead language ...
Then, he recants those assertions in "Rise of the American Programmer", and claims that Java and new web platforms have "rekindled" the American software programmers ... right before the dawn of Y2K hysteria, again, he pronounces the death of COBOL again ...
Now, the Y2K book where he sounds the FUD bell, and tells everyone to run to the hills, stock up on non-perishable rations, and build that bomb shelter kit ...
Granted, this work offers a perspective of failing software projects and I even read most of it once while browsing at a local B&N and some of the anecdotes were quite amusing ... but to spend a dime on this charlatan ... bleh ... how does this guy have any credibility whatsoever?
AZspot
I just finished working on the worst project of my career. I was brought in to replace the lead developer, who had quit w/o notice (I now understand why); I never had an adequate work environment (it's embarrassing to have to ask someone to print docs for you every day); and office politics resulted in half of my design decisions being overturned with little or no justification (my favorite: "No, we should put all of the source code in one directory, because cd-ing all over the place is too confusing."). But all that I could forgive, if it weren't for the process.
Every other Friday was a "freeze-date", where QA took whatever code we had, and did a test build for the users to pound on. However, every code change (new features, bug-fixes, updating database entries) had to be documented on seven paper documents (electronic was insufficient), requiring signatures from four-to-six managers, depending on severity (emergency fixes only required four docs and three sigs). The QA group was completely enamoured of itself, and somehow had acquired the authority to reject code that wasn't documented exactly as they specified, or documented, but the signatures weren't procured by the freeze date. Toward the end, someone in QA started rejecting code because it didn't meet requirements that didn't exist, but he felt really should. There was also the problem of the QA process changing without warning, but I've complained enough.
On some projects, the only thing that kept me coming back every Monday was the paycheck at the end of the week. That, and naive hope that eventually somebody would clue in and let us do our jobs in a meaningful way. A death march project is one that is being sabotaged by management in such a way that no amount of developer effort, passion, or enthusiasm will save it. The only thing that will save it is a dramatic change in management's understanding of the project's goals.
I don't know many programmers that are only in it for the money. The ones that are, I don't trust. As for the rest of us, yes, the rarity of our skills allows us to garner huge paychecks, but we're in it for the programming.
Give a sculptor a hundred bucks and a bucket of clay to work with and he'll be happy; give him a thousand bucks and a bucket of moist shit, and he'll usually walk. In analogous circumstances, most self-respecting programmers will, too.
So if you give me a project that's doomed, don't accuse me of cynicism when I act like I know it. And if you think the troops are responsible for their own low morale, your project's collapse is inevitable.
--
This is not my sandwich.
Stay tuned for The Fluctuation of The American Programmer to round out the trilogy.
And of course, don't forget the fourth book in the trilogy: So Long and Thanks for all the Mountain Dew.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Yes, but can it tell us how to deal with the most impossible dadline of them all:
"What the hell did you do to the car?!"
Obliteracy: Words with explosions