Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Death March 125

Posted by timothy from the it's-an-important-subject! dept.
Jason Bennett contributed this review of the depressingly named Death March : The Complete Software Developer's Guide to Surviving " Mission Impossible" Projects. But if you're ever part of a software project which seems to be going nowhere fast, and over very rocky roads, perhaps the words he's written will point you to a source of solace. This book seems to have some decent strategies for dealing with impossible demands and even more impossible deadlines. And while no book will give you a better boss or timetable, at least you'll know you're not the only one.

Death March
author Edward Yourdon
pages 218
publisher Prentice Hall
rating 8
reviewer Jason Bennett
ISBN 0-13-014659-5
summary Another excellent effort by Yourdon that gives insight into the "doomed to fail" project.

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

  1. Introduction
  2. Politics
  3. Negotiations
  4. People in Death March Projects
  5. Processes
  6. Tools and Technology
  7. Death March as a Way of Life

Puchase this book from Fatbrain.com.
This discussion has been archived. No new comments can be posted.

Death March Review More

Death March Review

Comments Filter:

  • Re:Irrelevant to most of us (Score:1)

    by Anonymous Coward
    You are exactly right! As a contractor, I don't have to get involved in any political bullshit that goes on wherever I happen to be working. If I am being paid for an 8 hour day, I put in 8 hours of work. If they expect me to work more than that, of course they have to pay for it. I care about the work I do, but realize that it has a better than 50% chance of being thrown out the window without ever being used.
  • "Of course, since my ancestors were white Mormons you probably couldn't care less that thousands died along the way."

    Why, yes, that's right, but it has nothing to do with their being white. Just think, thousands of your ancestors died and yet - here you are.

  • it's in print and relevant ... (Score:1)

    by Anonymous Coward
    so what else do you want? :)

    The topic is one that will still be relevant in a decade or two, I bet, and longer.

    I bet most readers have never even heard of this book, never mind read the point of view of a reader.

    What's the complaint? I don't mean to be flippant, but a book of this type isn't like one about up-to-month programming techniques. Reviewing an 6-year-old book on html programming would be bad, but this? I think it's valid now and will be for a while. Jason has a good point about it's longevity.

    Cheers,

    timothy

  • I iwsh I'd read this (Score:1)

    by Anonymous Coward
    before I got suckered into that first post software project

  • Re:Irrelevant to most of us (Score:1)

    by Anonymous Coward
    Before you all rush to bite this guy's head off:

    I'm a contract DBA. If I think that management are making a bad decision, I say so; that's part of my job. But here's the thing: if they go ahead and make the mistake anyway, what am I supposed to do? Tie myself up in knots? Cry? Slash my wrists? Fight them up the management chain? Of course not. If they make the wrong call regardless, I just shrug and get on with it. Project's late as a result? Not my problem. I think *that's* what this guy was saying.

    See, there is a point at which your responsibility to the project does, actually, end. The programmer doesn't *own* the project; the project manager does. To me, that's a mature point of view. Others might think that inappropriate, but there are limits to the service I provide to my clients.

    Likewise, my clients owe *me* certain things, like a professional work environment. If they fuck me over by demanding that I work 60 hours weeks for months on end, then I'll leave when my contract ends. They'd be fools to think that I wouldn't.

  • Re:Irrelevant to most of us (Score:1)

    by Anonymous Coward
    Again, this is totally irrelevant to those of us that are contractors.
    Outside contractors can go on death marches just the same way as everyone else, and not caring if the project is "ahead of schedule, or two years behind schedule" may be fine if your project manager is similarly flippant, but isn't likely to keep you in that contract for long.

    In fact, death marches can often be worse for contractors than for salaried employees. Salaried employees are there to deliver work on company stuff. Contractors are there to deliver a specific product by a specific date, and if you're not done, you're in breach of contract. Being paid hourly is certainly nice, but I'd rather be working hourly for 45 hours a week than 60.

    On a recent death march project my wife was involved in, I was brought in part time to help clean up some of the programmers' dumber mistakes (my wife was a contractor, working for a second contractor, working for another company). By the time I got involved in the project, employees had gotten used to fourteen hour days.

    (Side note: when asked why I was coming to help out, I responded that as long as my wife was working those hours, I wasn't getting any, and this was a state of affairs I wasn't willing to let continue. I got some yuks out of that, but it was God's honest truth.)

  • There is a huge difference between writing code under pressure in a contest and writing code under pressure because your job depends on it. In the former, you choose to be in a death march.

    As the Commandant of a current DM, I'm desperately trying to find ways to end it. it's not as easy as it sounds. Maybe this book will spark an idea.

    Cal
  • Microsoft employees have written some great books like the two you have mentioned, but I don't think any of the contents have stuck. The projects that the authors worked on (VC++ 1.0 for example) ended up great, but overall, the results end up pretty mediocre (schedule and quality wise).

  • Ed... (Score:1)

    by djweis ( 4792 )
    Edward Yourdon seems to be underappreciated. My software engineering teacher thought he was more of a hack and preferred other authors that couldn't convey an idea nearly as well.

    Of course, Decline and Fall was a bit over dramatic. I haven't read Rise and Resurrection yet.
  • Yes. :-)

    I think time to market is one of the main things hurting software development as a whole. People would rather put shit on a CD and be the first to market than have their lunch eaten even though they came out with a better product. Purchasers don't seem to have any memory of the problems with the last version, or they think that in the few months of development that all the bugs have been eliminated and new features got added.

    There isn't much that can be done. No one will buy Windows 2001 if the box says "No new features, but everything works correctly!". You'll hear people say "If it ain't broke, don't fix it," but it is broke and gets more broken every time they try to fix things.
  • That's fine. Don't hire contractors. You pay contractors to *write code*. The schedule is your problem. If the tactic is to screw up the schedule and then blame the coders, then you really ought to have regular employees.

    Myself, I simply charge 50% over my regular rate. I happy to accept the blame for the failure of a project, as long as I am getting paid a bit extra for it.

  • Billions of everyone's ancestors have died, wacko. It's be damned crowded otherwise.

    -David T. C.
  • [[Contractors are there to deliver a specific product by a specific date]]

    Around here (the midwest), nearly all contractors are used in "staff augmentation" mode, not "here is a project, go do it" mode. In other words, there is no contracted specific product by a specific date, there is only "show up, work on X, get paid $Y", with a vague idea that the project X is suppossed to take N months. Contractors of this type are certainly not in breach of anything because a project is late.
  • I agree completely, and I take my clients success very seriously, regardless of whether I am there as employee, contractor, consultant, whatever.

    It is frustrating to see advice not followed, but that does not remove the obligation do your best.
  • Many companies bring in contractors because they are not finding enough people, or not finding the right people, to hire as regular employees... not because they want them to specificly write code. There are contractors managing projects, testing, deploying, doing anything that anyone else does.
  • Contractors in the US above a certain hourly rate are exempt from a (government-mandated) time and a half got overtime. Of course such a thing could still be negotiated.

    You overall comment is totally correct, though.
  • Actually, IIRC there are more people alive now than the estimated total to have lived and died in recorded history.

  • If the project is so sh*tty, why wait till the project is over to resign ?
    Once you realize the project is insanely impossible, you don't like working on it, and you won't get a feeling of fulfilment when it is complete, you should quit NOW.

    If you wait till the end of the project when all your other collegues quit, they will surely be competing for the same type of jobs. Get a head start and quit NOW!
  • A book review of Death March? Now? How old is this book? didn't it come out like 5 years ago? sounds like the book review itself was victim of a deathmarch too.
  • I was thinking more along the lines of:

    "What the hell are you doing in the bathroom 22 hours a day!?!? Why don't you come out of there, give someone else a chance!?!?"

    --
  • Seriously give it a read it may come from Micro$oft but like "Code Complete" its worth a read.

    Having been conned by my prestigious cs department into buying this piece of garbage for an intro course, allow me to dissent. Of course, I was unable to get past the inane, endless manifesto on the "modified Hungarian notation." That is, IIRC, because I the book went up in flames during exam period of spring freshman year as an offering to the unix gods.
  • Software companies didn't move overseas, they brought the overseas here. Haven't you heard of H1B's? :-)

    --
  • I'm not employing you. Never. Not that I'm in a position to employ or not *right*now*, but that doesn't change a thing. These people pay you a fortune to do the best job you can, and seriously failing to give a shit about the health of the project, well, not on my project you're not.

    Mind you, a few months back I had to quit a job I had tried seriously hard to like even though the project was fundamentally fucked. Couldn't like it, couldn't do a good job, had to quit.

    Attitude. Seriously.
    Dave
  • Writing Solid Code is indeed a good book, but I was much more impressed with Code Complete (by the same author).

    I have found Steve McConnell's books to be the only Micro$oft book's worth going back to, time & time again, year after year.

    HTH,
    fRoGG

  • I dont care whose ego gets inflated, doesnt matter to me at all. I'm not there to stroke some manager and make him feel all powerful and knowing. I'm there to do a job and offer up my experience as to what works, and what doesnt. If the customer chooses not to take my advice, fine, as long as I get paid, there's no hard feelings if you ignore me. I work at a shop like this right now, they are heading for a trainwreck, the warnings are all about, but the holy Gantt chart says everything is fine. I've offered advice in as deferential a manner as possible as to not wound the fragile egos of all the 'directors' I work for, but it's ignored or derided with a 'harruph, you're just a contractor, what do you know' . So I sit at my tiny cube with my 60hz screen and do CAD work quite inefficiently, but I can't possibly have better equipment because it's non-standard.

    Any you expect me to have some sort of emotional stake in the success of this venture... ROFLMAO!!
    Sorry, that costs extra... ^_^

    On the other hand, I'm working on a project with a customer who gave me a very nebulous spec, full of things that were impossible, and we've worked out everything in a very professional way, I tell them, 'sorry cant do this' and provide them options on what will work and how much it will take to do it, and offer best estimates of performance. They make a choice and I implement it. When I have improvements to the design, I propose them, they give me a clear response on whether they want them, or not and it's done. They are making very good use of my expertise and it's a very professional relationship.

    The interesting thing is the difficult customer is a startup with a bunch of guys, in their minds, hotshots, and the reasonable customer is a Fortune 50 deptartment managed by a female engineer. The first project is completely do-able, nothing ground breaking, the second is totally cutting edge, nearly impossible to achieve it's goals.
  • Ed publicly joined the black helicopter set last year. I'm surprised that anyone still takes him seriously. I certainly don't.
  • Yes, I think all of the people forced to march in the Bataan Death March were Jews weren't they? And the Trail of Tears was certainly a group of Jewish Amrican Indians.

    </sarscam>

    What book or two were you reading?
  • I've been a coder and a project manager, both as a n employee and as a contractor. I used to get heartburn when (as an employee) my ideas weren't acted upon. As a contractor, I still feel obligated to give advice, but I don't get so upset when it's not acted upon. I just feel glad that I don't own stock in that company.
  • Of course, you must remember to tie the book to the brick.

    --
  • If nothing else, this book could be used as a subtle means of communicating your dissatisfaction with a crazed environment... say, by purchasing a copy and leaving it conspicuously on your desk.

    Or of course, as an anonymous gift to your favorite manager-

    --
  • Here I am in the deepest pit of hell, slaving away on an impossible project that will drive my company to bankruptcy. We're on the verge of missing the next drop-dead milestone, and the customer is already talking to the legal department. When was the last day that I worked less than 16 hours? When did I last see my family? I hardly remember any more. All of my colleagues have assured me that they will resign as soon as it's over, and so will I.

    As discretely as possible (because my boss might see me), I surf on over to Slashdot to give my tortured brain a moment of rest. Death March, it says! No kidding.

    I'd write more, but THERE JUST ISN'T ANY TIME!

    YAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH!!!
  • If the project is so sh*tty, why wait till the project is over to resign ?


    You're tempting me. Oh, you are tempting me ...
  • Oh man, for a minute there I thought it was a book about my wedding!

  • I read the book and I think it is okay. Problem with the book is that Yourdon tends to repeat himself over and over again in each chapter.

    Also, I think people who plan to be just programmers should not read the book. People who definitely need to read this book are the Project Managers of such (any actually) projects and their bosses/stakeholders.

    Especially the topics regarding the motivation of the team members to do it now, but also to do it again should be important to them. IMHO that is where the real problems with Death March projects lie: Programmers who after the project finished think: What did we do it for?!? Why did we work 90 hour weeks??? What was in it for me???

    If you do not get that right, then -- appart from filling the ranks of your competitors with your cynical ex-programmers -- you end up staffing your Death March projects with young, new programmers, and that means you miss out on a lot of experience. Since experience is just what such a project needs you shoot yourself in the foot if you give your staff the chance to decide that they will never do it again, or at least not for you(r company).

    I like what Yourdon has to say about that, but would advice anyone who doesn't plan to become a project manager on such project not to read this book, because it is a bit on the boring side, even if you are interested in the topic.

    --

  • The only way to write good software is to get your project management right, get support from your client, and get enough disciplined, good, and motivated staff with the right mix between experience and young enthousiasm. After that, whether you do it the Death March way, or not doesn't matter.

    Problem is that getting these necessary components together is in many organizations only possible if you are, act like, or claim to be on a Death March.

    You really should read: How to run succesful projects [amazon.com] by Fergus O'Connell.

    --

  • The answer to your question is: It is the project manager's task to get the project finished, to get the job done. That is her job description. Whether it is impossible to do or not, if she accepts the assignment she must do it or else she is to blame.

    If she knows -- which she should -- she cannot do it she should refuse, even if that means she gets fired. Getting fired before the projects is always preferable over getting fired after suffering 1000 hours of frustration in 12 weeks.

    --

  • I've heard it said that Yourdon is an evangelist, not a practitioner. In other words, he talks a lot but doesn't do much.

    You may be interested in checking out Tom DeMarco, who is most definitely a practitioner of the art. A very interesting exercise is to read one of his early books, where he is evangelizing, such as "Structured Analysis and System Specification", then immediately read "Peopleware", which is a collection of hard-gained wisdom from years of experience. It's really amusing what he has to say about Methodologies, which he himself has evangelized.

  • >"Outlook not so good." That majic 8-ball knows
    >everything! I'll ask about Exchange Server next.

    That is the funniest sig I have ever read, thanks for brightening my day up!

    One small point, "majic" is properly spelt "magic".

    Thanks for the laugh!

  • Yes, yes, I know it's a troll, but I still had to respond.

    Firstly, I like the idea of MS and IBM products shipping on time. Wish I could see his calendar. Be quite a sight, a calendar like that

    Secondly, I (and most of the people I've spoken to) actually write slightly better code when I'm tipsy or slightly stoned. Dunno why, but maybe it has something to do with (hnnnngh) Thinking Out Of The Box. Try it some time - you might be surprised.

  • That presumes that you don't mind working with stressed out people (including managers).

    I can't be happy working around a bunch of un-happy people, so I will usually look for another contract position.
    There are plenty of them out there.
  • I dream for a day when I can get my processes and testing so finely tuned that I don't need QA at all. But for now... thanks guys.
  • My God! What was the turnover like at that place?
    --

  • As was stated by others, that kind of attitude neither contributes to a good working environment nor does it contribute to good results either. I find that kind of thinking an epidemic among those "programmer-analysts" who got into the business with a quickie-course, thinking about the money they could make. Programmers who love what they do (if not the company they work for) tend not to think that way IMHO.

    I've done some consulting/contracting, and while its true that most times you can manage/negotiate your own deadlines, that doesn't mean that contracting is free of deathmarches...if through inexperience you underestimate the effort involved that could be a killer. Or if you run into a serious bug that just won't die or changing specifications (the proverbial moving target).

  • ... instead of coding day and night, you will fall even further behind the schedule!!
  • Yes, but as a professional consultant, it is your duty to insure that the best possible advice is given to the client. I don't think that I've ever been with a client that has had real experience getting a project out the door. Too many of them tackle the development process in a very wierd way, almost insuring failure. As a consultant, you need to offer as much "guidance" as you can to make sure that the project reaches a successful outcome. Who wants to spend a year or two of their lives on something that no one wants?
  • If you really wish to support these people the very first thing you have to do is not be a dick.

    Here, use my knife.

    Congratulations, now you are dickless, it's the first step to recovery.

  • /. is character development and frustration management. By spending a while here at /. we become more efficient workers....yeah...that's it. Think my boss'll buy it?

  • I have to say I have much the same attitude. As far as I can tell, contractors in the UK are a slightly different breed from contractors in the US - US ones seem to be employees that earn slightly more but don't get benefits. Here in the UK contractors are employed more on short term things, we run our own limited companies (corporations) and submit invoices for our time.

    And I meet an awful lot of contractors who share my view on things. We're the infantry. We get paid money so PHBs can order us to do stuff. We do what they ask. They frequently ask us to do boneheaded stuff, but we do it anyway, because no-one listens.

    I can't get emotionally invoved with the companies. I'm here for three months, six months - nine months is a long contract. I can't start developing a pride in what's going on, because there's rarely anything to get proud about. The only thing that keeps me sane is that my future is not vested in these companies, it's in my hands. The sight of permies who are supposed to have a future in these companies is terrifying as they watch management power-diving them at the ground. Us contractors have parachutes, exit routes, limited involvement. These permies signed on to have a future here and they can see the PHBs thrwing that future away in a morass of inept management.

    I'm actually rather glad I'm not in that boat.
  • > Who will it be next guys? Muslims? I bet it won't be good 'ol Christian Wight Males will it?

    Christian (and Atheist, Jewish, Muslim, Animist ...) males already have. It was the Bataan Death March.
  • So why when they can write decent books on project management do they consistently fail to ship anything on time or of sufficient robustness ?

    So what do you reckon:-

    - Is it just poor management
    - Their weird organisational structure
    - Marketing induced shifting requirements ?
    - Marketing lead unrealistic deadlines
    - Poor quality coders
    - Project Teams trying to build decent code on top
    of someone elses spaghetti nightmare
  • The one thing I don't understand is why didn't the author generalize this to cover all engineering disciplines? I, for one, am on one of these right now, and I'm a microwave circuits engineer.

  • Too bad you never got past that. One of the book's points was that it doesn't matter what notation system your company uses as long as it uses something thats consistent and understood by each programmer.

    Its got practical advice that applies to any language. If you would have read further, you'd have seen examples in C/C++, Pascal, and Basic(this was written in 93). It was a distillation of lots of stuff you'd only find in research papers or passed around by developers via word of mouth, handwritten notes, etc. There were a few things I never saw anywhere else, like how to tighten up for loops and while loops, and when to use recursion(college textbooks almost universally teach bad examples of this subject).

    I watch the sea.
    I saw it on TV.

  • I'm definetely stuck in a DM project right now... a long term one, which makes intense pain of hell seem pleasant.

    Unfortunately, the vast majority of software projects usually turn out to be DMs... some more severe than others. The less "severe" DM project I can handle... it's the big ones that suck.

    --cr@ckwhore
  • I'm inclined to agree. Yourdon has always struck me as one of these blowhards who claims all sorts of IT experience, yet seems to spend all his time writing books. What I've read from this guy makes me think that he's one of these know-nothing know-it-alls who extrapolate industry trends from a few personal experiences. The fact that it took him until "Rise & Resurrection" to figure out that reliability was not required to be 100% for every project underscores his lack of real-world experience.
  • Most of slashdot are contractors? I doubt it.

    I think your attitude stinks. Typical clockpunching point of view by someone who has zero commitment to providing an actual service to his customers. When I was contracting a few years ago, I actually felt obliged to provide my clients with value appropriate to the wage they were paying me. This didn't mean that I killed myself getting work done, but I certainly cared if the project was ahead or behind schedule.

    Fools like you think you somehow deserve your salary because you're so brilliant. You aren't - you're scarce. You can exploit that scarcity by doing the bare minimum while pulling down as much cash as possible, or you can use that scarcity as a mandate to yourself to do the most good with the skills you have. Being scarce isn't just about pulling down big dollars - it also means that you can make a real difference in your work. So many people work at shit jobs that are shitty not just in pay, but in satisfaction. Count your blessings.

    I suppose if programming didn't pay so well your career of choice would be processing forms at the local Dept of Motor Vehicles. Or maybe a job selling dubious stock to retirees because they're 'too stupid' to know that your product is crap, and it's not your problem if they loose their shirts.
  • I've been in the situations where a boss can't say no to a client too, but that boss also would try to get every project he could. Many times the price he would quote would get rejected by the client, so he would lower the cost by 50 - 75% in order to get the job. Unfortunately, the man hour cost of the job was about 65% of the ORGINAL quote and we'd lose money, it would also tarnish all future quotes for that company. He'd try to manage costs by shortening the production schedule, so we wound up with one fast-paced death march after another which produced hurried, buggy code, that we would be forced to fix later, at our company's own expense anyway.

  • My God! What was the turnover like at that place?

    Well, I already mentioned my position was the result of turnover; I left the day the site went live, but that doesn't count (I'm a despicable contractor (but only for now; give me a sane job!)); and the project manager left in disgust a week after I did. Everyone on that project who didn't leave were the principal sources of my woe, so I feel they deserve each other.

    In fact... [opens new browser; types "secret" URL; enters test ID and password; sees they haven't been changed] ...it looks to me like the only thing that has changed since I left a month ago is the logo, and one addition to the FAQ.

  • ...I read "The Project Survival Guide" ... published by the evil empire... Gotta jump in here to say, Microsoft Press is one of the less unpalatable aspects of the Dark Dominion. If the breakup ever comes, I hope this imprint could be spun off into its own house.
  • I'm glad to say I've never been in a trainwreck and have always warned management what's looming long before jumping.
    The only train "wreck" I was when it derailed when I was running it. However, the passengers did not believe me that we had derailed, and it wasn't until one actually got up and saw for herself the wheels on the ground that everybody got the notion that we were actually derailed...

    --
    Americans are bred for stupidity.

  • I'm taking a class of "computer project management". I just produced my teacher a copy of " The mythical man-month ", asking him if it's a good book, and he flatly told me that he didn't know about it.

    Now, what would you think of a class whose teacher doesn't know about that book???

    --
    Americans are bred for stupidity.

  • 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 ;)

    Another excellent book from Microsoft Press was "Writing Solid Code". Go to your local bookstore, pick it up, open it at random, and read a few pages. You'll be impressed.
  • We are "sinners" when it comes to writing good software and suspect there are better answers out there. The some software guru comes by with some senstational slant. Sounds good for a while, then we drift back into out bad habits.
  • I believe the correct version of this is "Adding more programmers to a late project is like putting petrol on a fire", which somehow seems to get the picture across better.

    You should read "Rapid Development" by Steve McConnell (pub. Evil bastards in Redmond). Takes what Fred Brooks was doing a step further.

    Dave :)

  • I think the one thing that interested me about the book was that he didn't just do the normal deathmarch (i.e. late, architected by morons and knee deep in paperwork). He also dealt with the "way ambitious, it'll never work, BANZAI!" projects that end up with everyone killed.

    Read it. Don't buy it. If you live near me, give me a mail and borrow my copy.

    Dave :)

  • Sounds like a great subject, because practically all real-world projects get into that "death march" stage. (I'm in one right now.) Unfortunately, I wish that somebody other than Yourdon had written the book. Yourdon was so completely out to lunch about Y2K that I don't see why anybody should trust his judgement any more.
  • I seem to recall that he actually DID move out to the desert in Arizona or somewhere like that to ride out the Y2K disaster. Looks like he crawled out from under his rock.
  • When I joined my latest Deathmarch Project, almost every member of the team had this book on their desks.

    Worse still, most of them could quote from it!

    The entire project (10 million pounds worth) was canned the Tuesday after I left.


  • Not quite precise (see 29CFR541 [dol.gov]. In practice, it depends on which (tax/employment) flavor of contracting you do. If you do 1099 contracting, no, you probably won't get overtime by default, but you can certainly negotiate your own rates. I do w-2 contracting, which means my agency's income is contingent on my hourly rate, so damned if they're not going to specify time-n-a-half, and double-time -- it's their income which doubles too :) -- and it makes them competitive in attracting talent.


  • Clearly, some people below don't get it. Here's some further elucidation:

    A death march is a programmer experience where management demands of the programmer(s) more than can be done with the resources (t, $, etc.) available, and the only way a deathmarch can be imposed on a programmer is if you can blackmail him.

    Blackmail: One can tell (or merely strongly imply to) a salary slave that if he doesn't do the job to management standards -- regardless of how many hours it takes -- he'll be sacked. In this way, management gets lots of extra time and effort out of the employee for free. After all, your job is hostage.

    If you tell a contractor (or other hourly billing employee) to get something done, you pay for all the extra time it takes.

    This has an amazing radicalizing effect on employers. All of a sudden, they don't have a tremendous incentive (wage-free labor!) to pull much of the kinds of shit which turn a project into a deathmarch.

    Put another way: If Joe Management tells Salary Sam that a 80hr project has to be done in a week, Salary Sam will DONATE 40hrs to the project, and Joe Management gets a 80hr project done in one week only paying for the same 40hrs. What a deal! Fast turn around and wage-free labor! Why wouldn't you run your shop this way? If you present every job as an emergency, you could save a mint!

    However, if Joe Management tells Contractor Connie to do an 80hr project, Contractor Connie is going to bill every one of those 80hrs, whether they are all in one week (in which case, Joe Management will actually have to pay 110hrs (40 at regular time, 20 at time and a half, 20 at double time)) or over two weeks or over a month. Joe Management is very, very respectful about Contractor Connie's time. She's "expensive", even though her billing rate may be exactly on par with the ostensible hourly rate of the salary slaves, because she won't work for free.

    This strongly encourages employers not to pull the bs which causes deathmarches. Paying time-and-a-half has an amazingly salutary effect on manager's time-management and resource-management skills.

    (All this reminds me of one project I was on when the client said to me after the zillionth spec change "I'm sorry to waste your time." To which I responded cheerfully, "Oh, it's not my time any more. You bought it. After all, you're buying my time by the hour." The sudden stricken look on his face was priceless. Needless to say, that project shaped up in a hurry.)

  • You make it sound like he wrote all of these books last week. They all sound ridiculously silly now, in retrospect, but not then.

    When he wrote Decline, it was mostly accurate at the time.

    When he wrote Rise, it was mostly accurate for its time.

    Okay, I'll give you the Y2K one. That was looney.

    And recall that Death March was written in 1997. Some things have changed since then (buzzwords), some things haven't (fucking idiots getting instantly promoted). Keep that in mind when you read it.

    The comments he makes on triage are especially apt.

  • When I joined my latest Deathmarch Project, almost every member of the team had this book on their desks.

    A friend once pointed out to me that at any company with projects deeply in trouble, you'll find copies of "Code Complete," and "Managing the Software Development Process."
  • Based on your answer, I have a couple of questions....
    1. 1) What is your real name so that I make sure we never hire you?
      2) Are you an actual contractor or just a high school troll with no concept of the real world?
      3) Do you have a soul or understand the ethics of software deveopment at all?
      4) Which foot, my left or my right, would you prefer shoved up your ass?

    --
  • I don't think that NineNine implied that he wouldn't put in his share of work.

    It is not a contractor's job to solve management problems. It is a contractor's job to
    do the work assigned to them.

    Saying you don't care is one way of protecting yourself emotionally when you find yourself
    working for un-reasonable people.

    If a project is behind schedule and your efforts can make a difference, then by all means work harder.
    But what do you do when the project schedule was never realistic? After you give management your
    opinion and they don't want to hear it, then what do you do? Do you burn yourself out?

    "Death March" isn't talking about projects that are a little behind schedule.

  • F. P. Brooks' "The Mythical Man-Month", which gave us Brooks' law: "Adding manpower to a late software project makes it later".
  • ...Yourdon's web site [yourdon.com], all about software development process, software project management and other "software issues", gives me an "Error: do you wish to debug?" message when it loads. If a guru can't get things right then what hope is there for mere mortals?
  • Momentary genius in a crunch situation isn't the essence of a Death March. A death march is rarely a one-person situation. My first large programming job was 5 years of Death March after Death March, until the company died. For the most part, the causes were business related, not tech related. We were under-funded, over-extended, and grew too fast. We had a salesman, and company CEO who could never say no to a client. We never had enough money to meet current payroll, so we sold future programming time for current expenses. As a new programmer, and still naive, I didn't see what was happening until it was too late.
    --
  • And between which of my impossible deadlines am I supposed to read this? I guess we better be reading this book befoer we are ever given the deadlines or it kinda defeats the purpose

  • Got this little gem about 10 years ago in telco R&D lab: The Six Phases of a Project: (1) Enthusiasm (2) Disillusionment (3) Panic (4) Search for the Guilty (5) Punishment of the Innocent (6) Praise for non-participants Sorta covers all projects I've ever seen... And you know you're in a DM project when you hit phase 3!
  • You mean the Dilbert reality isn't our reality?

    No, I'm saying it is! That's why I'm leery about the idea of a book about optimizing overwork. I recognize the reality is that people have to deal with this stuff for no good reason (my girlfriend's boss recently announced, "If you're not miserable, you're not working hard enough.") and that's why the idea of "Managing Your Death March" bothers me.

    I also have to say that while I know people use "Death March" facetiously in conversation, raising it to the level of Industry Terminology strikes me as insensitive and dismissive of the real human suffering for which the term originated. No, I'm not some PC zombie -- I was bashing them just yesterday/a& gt;. [slashdot.org]

  • You mean the Dilbert reality isn't our reality?

    Actually, I view this as the end product of an industry where what you're working on this week may be obsolete next week, or even in the next hour. Combine that with managers who know nothing about computers, programming, or time-management, and you get this. (You also get 50% of the Dilbert strips ever produced.)

    Programmers are always going to view certain projects as "Death Marches", simply because certain projects in any corporation will always be "Death Marches". Poorly managed projects are the norm, not the exception, at least in my jaded cynical view.

    And it's not just in business. Too often in college courses, assignments are given not to teach the students, but just to give the assignment. And consequently, the students don't want to spend a lot of time on the assignment because it is assigned for this reason.

    This, of course, is paralleled in business, and make-work is the worst kind of "Death March", IMAO, because everyone knows that it is make-work. No one likes doing work that has no meaning. No one wants to dig post holes just to fill them in later, or ditches to bury the D.I.'s cigarette.

    How are we supposed to treat this? It's really simple to say that you get rid of incompetent management, but according to the Peter Principle, "Everyone rises to his or her own level of incompetence." Or, those who can, do. Those who can't, manage. (Those who can't manage, become sales reps.) Some companies, especially those that are small enough, can have enough interaction between the levels of employees that this can be taken care of. But all too often, the major corporations cannot effectively deal with incompetent management. Hence the book. If nothing else, it gives you something to read other then Dilbert.

    Kierthos
    (Just another jaded /.er)
  • Again, this is totally irrelevant to those of us that are contractors. That's the beauty behind beinh a contractor. I couldn't care less if the project was ahead of schedule, or two years behind schedule. It's not my problem. That's for the project manager to deal with. I get paid hourly, come hell or high water. That's the way all development should be done. Anyone who has been through a nightmare project should realize this.

  • 1. None of your damned business.
    2. I'm an actual contractor. I have been for about 4 years now. Have had over 10 positions in that time.
    3. Ethics do not come into play at all. I work to pay my bills. I'd pimp out your mom if she could make me a buck.
    4. Both, please.

  • Better let the Yanks know that petrol = gas by their lights.
    And yes, I really do think they're that ignorant. Any country that would seriously consider voting a dunce like George W. Bush to a leadership position...?
  • It looks better on your job history if you jump off the train before it crashes.
    I'm glad to say I've never been in a trainwreck and have always warned management what's looming long before jumping.
    Loyalty counts, but after a certain point it looks more like foolishness.

  • I've skimmed Yourdon's book, but the one I found more useful was How to Run Successful High-Tech Project-Based Organizations [amazon.com] by Fergus O'Connell. It's very practical and concise. Some of the tools offered don't seem very polished, but they're a good place to start. This is an expansion of a previous book of his (the title included something about "the Silver Bullet"), with 10 steps to make sure that a) you don't sign on to projects that will fail, and b) the projects you do sign on to stay on-track.

    Basically, it comes down to having the balls to say "no" when you know the project is a death march/suicide mission.

  • There have been plenty of Death Marches. (Score:3)

    by Jason Earl ( 1894 ) on Thursday November 02, 2000 @07:35AM (#655195) Homepage Journal

    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.

  • Re:There have been plenty of Death Marches. (Score:3)

    by Jason Earl ( 1894 ) on Thursday November 02, 2000 @01:05PM (#655196) Homepage Journal

    Precisely my point. Crying about what happened to your ancestors is ridiculous, nobody lives forever. Somehow you still managed to get born, and the fact that you are able to post to /. signals that you are almost amazingly fortunate. There have been few people in the history of the world as prosperous as most of us on /. are. Perhaps I should have put smileys on that sentence so that the Grammar Nazis would realize that it was a subtle touch of humor. Clearly I wasn't related to all of the thousands that lost their lives on the trek westward, some of my ancestors failed to die of exposure, and here I am today.

    For that I should be grateful, I suppose, but anyway you look at it holding a grudge against the current residents of Illinois would be ludicrous.

  • Triage (Score:3)

    by warmcat ( 3545 ) on Thursday November 02, 2000 @07:24AM (#655197)
    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

  • Re:How I could tell ... (Score:3)

    by sammy baby ( 14909 ) on Thursday November 02, 2000 @11:09AM (#655198) Journal
    A friend once pointed out to me that at any company with projects deeply in trouble, you'll find copies of "Code Complete," and "Managing the Software Development Process."

    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.

  • Re:Irrelevant to most of us (Score:3)

    by Bigboote66 ( 166717 ) on Thursday November 02, 2000 @09:07AM (#655199)
    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).

  • Re:Programmer's Fault (Score:3)

    by DivideX0 ( 177286 ) on Thursday November 02, 2000 @10:23AM (#655200)
    I usually don't feed the AC's (trolls) but here I go:

    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.

  • Soul Brother (Score:3)

    by CaptainZapp ( 182233 ) on Thursday November 02, 2000 @08:29AM (#655201) Homepage
    Man, do I know what that guy is talking about.

    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...

  • Lack of communication. (Score:4)

    by carlfish ( 7229 ) <cmiller@pastiche.org> on Thursday November 02, 2000 @11:41AM (#655202) Homepage Journal
    Death March is not the "only way to get a project done". This is a myth that's been happily supported by generations of IT managers who know that if you prod a hacker the right way, his pride will make him do all sorts of insane (usually unpaid) overtime. It's a myth supported by hackers who don't dare go to management and say "Our estimates were wrong. It'll never ship in time."

    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
    --

  • 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 [microsoft.com] 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.



  • Yourdon is a weenie ... (Score:4)

    by Naum ( 166466 ) on Thursday November 02, 2000 @07:58AM (#655204) Homepage Journal

    ... 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?

  • Process Problems (Score:4)

    by Prior Restraint ( 179698 ) on Thursday November 02, 2000 @07:42AM (#655205)

    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.

  • Re:Irrelevant to most of us (Score:5)

    by theonetruekeebler ( 60888 ) on Thursday November 02, 2000 @11:53AM (#655206) Homepage Journal
    Fair enough. And in fair exchange I can probably say I'm not going to work for you, either, because if you expect me to stay enthusiastic when every single bit of my work is going to get thrown away not on its own merits but because they are being poured down the black hole of death march projects, you're as deluded as the upper management that causes them.

    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.

    --

  • Trilogy (Score:5)

    by istartedi ( 132515 ) on Thursday November 02, 2000 @09:38AM (#655207) Journal

    ...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.

    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.

  • Yes, but... (Score:5)

    by American AC in Paris ( 230456 ) on Thursday November 02, 2000 @07:15AM (#655208) Homepage
    This book seems to have some decent strategies for dealing with impossible demands and even more impossible dadlines

    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?!"

Slashdot Top Deals

"You can have my Unix system when you pry it from my cold, dead fingers." -- Cal Keegan

Close