I was suddenly jerked awake from a bad dream, early this morning, with the urgent sense that it’s time to write a new edition of my Death-March book. God only knows what the dream was about; maybe I was being harassed by Dilbert’s pointy-haired boss on a suicide-mission death-march project, or maybe I just had too many of those spicy barbecue ribs for dinner last night. But I haven’t been able to shake the feeling all day, and I’ve scribbled enough notes to convince myself that this is indeed a project I should embark upon.

It seems like almost yesterday that the second edition of Death March was published, but it’s been nearly four years; and it’s been nearly 10 years since the first edition was published in 1997. As I’ve remarked in other blog postings (look, for example, here and here and here and here and here), death-march projects never went away during this period; and in many fundamental ways, they’re still the same as the first death-march project I stumbled into back in 1966.

But some things have changed, and we need to get those details out in the open. And we’ve got a new generation of software developers getting sucked into death-march projects with the same wide-eyed naivete that I exhibited at the tender age of 22, when my boss told me that our software development project would cure cancer, bring about world peace, and generate revenues that exceeded the GNP of the entire American economy. I know that a generation is supposed to be 20 years, or perhaps as little as ten years, in today’s fast-moving times. But I also think that the people who read the 2nd edition of my book back in 2003 are a very different bunch of people than the ones currently graduating from college and embarking upon their first job … which, for better or worse, turns out to be a death-march.

So what has changed? What’s different, and what is it that we need to discuss? Well, consider a few obvious topics:

• Web 2.0 technologies, products, and services — including, for example, blogs and wikis — provides a whole new way of collaboration among members of a project team, as well as end-users, managers, and other stakeholders, that simply didn’t exist before.
• The web-as-a-platform, software-as-a-service paradigm means that we’re building entirely different kinds of systems than we did even a few years ago. Among other things, the notion of “perpetual beta,” popularized by Google, is now an important factor in our software projects. Death-march projects used to be a race to the finish line, at the end of which we hoped to deliver a finished system before collapsing from exhaustion. Now the race goes on and on and on…
• The open-source development paradigm provides a whole new organizational model for software projects, and it’s not clear to me whether death-march projects can even exist within this paradigm. If not, maybe that’s a good thing; but in any case, it’s a topic that needs to be explored.
• The economy has improved in the past year or two, which means that, to a much greater extent than was true in the 2000-2005 era, people can vote with their feet. If you stick them into a truly miserable death-march project, they can simply quit and find a more civilized place to work.
• “Agile” development methodologies have become almost mainstream throughout the industry. When used properly by intelligent, mature adults, that’s terrific; however, in many of the software development projects I’ve observed in recent years, “agile” has simply been a management euphemism for “faster.” Or, to put it another way: I suspect that a lot of death-march projects have been justified in recent years with the management statement, “Oh, sure, we can promise to finish this project twice as fast as we previously would have estimated, because we’re using an agile approach.”
• We have new development tools and technologies — e.g., Ruby on Rails — that make it easier to build certain kinds of systems much more rapidly than before. I don’t think this will eliminate death-march projects, but it might help ameliorate some of the pressures.

So these are some of the things I want to write about in a new edition of the book, which I hope to finish by the end of this year, and publish sometime in 2008. But more than just the technical topics, I want some new case studies … some new stories … and some new people. All of this will eventually appear in a traditional “dead-tree” book, with all of the usual limitations and constraints of such publications, but everything leading up to that final form of publication can take advantage of all the collaborative tools we now have available: blogs, wikis, Flickr, YouTube, whatever. I haven’t figured out how to structure and organize all of this … and maybe I don’t need to; maybe it will take on a life of its own. But I need to get it started, and that’s where I need your help.

If you’re just embarking upon a death-march project, and you want to share the agony and the ecstasy with all of us in the blogosphere, get in touch with me. If you’ve been trapped in a death-march project for six months, and you desperately want to tell everyone what went wrong, and/or why nobody else should suffer a similar fate, send me an email. If you’ve finished an amazingly complex, high-pressure death-march project with triumphant success, and you want to share your secrets with everyone else, let me know. If it was a tool, or a technology, or a methodology, or an amazing management approach that turned out to be the difference between success and failure, track me down and tell me.

My personal opinion is that the tools and technologies, the methodologies and management techniques, are important … but ultimately secondary; it’s the human stories that we need to capture, and pass on to future generations of death-march project participants. I’ve seen lasting friendships, and marriages emerge from death-march projects; and I’ve also seen divorces, nervous breakdowns, and bitter personal disappointments. You can’t really understand what this is all about unless you’ve lived through one or two of these projects; but the next best thing is telling the human story, for the benefit of others.

Ideally, I’d like to find a project manager who’s willing to introduce me to everyone on his or her team, and let me participate with everyone throughout the death-march project, almost like the “embedded” journalists in Iraq, who are doing their best to report on the otherwise-unimaginable battle scenes. But that may not be realistic in my case; it takes a brave project manager, and an equally brave corporation, to allow an outsider to report the details of a high-pressure project whose success isn’t guaranteed. But maybe there are some brave managers out there who would like to get their project’s story documented with or without the full awareness and approval of their corporate masters. If so, send me a note.

And there may be folks down in the trenches who feel that their project needs to be documented — including the good, bad, and ugly aspects of the death-march activities — even if their boss is a complete Dilbert-style pointy-haired idiot, and even if their company doesn’t approve. I’m not interested in exposing any national-security secrets, or violating any security restrictions that will get me thrown into jail … but if it requires some Woodward-and-Bernstein style journalism, with confidential access to anonymous sources, I’m game for that. I’m not trying to bring down the government, or expose criminal wrong-doing within corporate empires; all I want to do is tell people what really happens in these crazy projects where people work 100 hours a week, until they drop from exhaustion, to build a software system that — 5-10 years later, with the benefit of 20-20 hindsight — nobody really cared about.

Maybe you’re one of the lucky ones: maybe you’ve never worked on a death-march project, and maybe you never will. But if you have worked on one of these monsters, and if you want make sure the world hears about it, leave a comment on this blog posting, or send me an email note at ed-at-yourdon-dot-com.