Death March (YOURDON Press Series) / Edition 2

Other Format (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $23.20
Usually ships in 1-2 business days
(Save 61%)
Other sellers (Other Format)
  • All (15) from $23.20   
  • New (11) from $26.46   
  • Used (4) from $23.20   

Overview

Death March Second Edition

The #1 guide to surviving "doomed" projects...Fully updated and expanded, with powerful new techniques!

At an alarming rate, companies continue to create death-march projects, repeatedly! What's worse is the amount of rational, intelligent people who sign up for a death-march projectsaeprojects whose schedules, estimations, budgets, and resources are so constrained or skewed that participants can hardly survive, much less succeed. In Death March, Second Edition, Ed Yourdon sheds new light on the reasons why companies spawn Death Marches and provides you with guidance to identify and survive death march projects.

Yourdon covers the entire project lifecycle, systematically addressing every key issue participants face: politics, people, process, project management, and tools. No matter what your role--developer, project leader, line-of-business manager, or CxO--you'll find realistic, usable solutions. This edition's new and updated coverage includes:

  • Creating Mission Impossible projects out of DM projects
  • Negotiating your project's conditions: making the best of a bad situation
  • XP, agile methods, and death march projects
  • Time management for teams: eliminating distractions that can derail your project
  • "Critical chain scheduling": identifying and eliminating organizational dysfunction
  • Predicting the "straw that breaks the camel's back": lessons from system dynamics
  • Choosing tools and methodologies most likely to work in your environment
  • Project "flight simulators": wargaming your next project
  • Applying triage to deliver the features that matter most
  • When it's time to walk away

This isn't a book about perfectly organized projects in "textbook" companies. It's about your project, in your company. But you won't just recognize your reality: you'll learn exactly what to do about it.

Read More Show Less

Editorial Reviews

From Barnes & Noble
The Barnes & Noble Review
You know how software projects are supposed to go. Careful software engineering methodologies. Cooperative clients. Proven technologies. Well-organized teams. Adequate resources. Sane schedules. Well, you can dream. The reality? All too often, projects become “death marches,” where the whole team is fighting merely to survive.

People work 14 hours a day, 7 days a week -- and no amount of Jolt Cola is enough to even the odds. These are the projects where folks struggle to keep their jobs, personal relationships, health, and sanity. Survival, says Ed Yourdon, involves five key issues: politics, people, process, project management, and tools. Yourdon’s Death March, Second Edition shows how to use all five of them to give yourself a fighting chance.

Yourdon knows more about software projects than just about anyone. In a 40-year career, he’s pioneered everything from timesharing to object-oriented methodologies. He’s trained more than a quarter million software analysts and developers. (He’s also been inducted into the Computer Hall of Fame, along with folks like Charles Babbage, Seymour Cray, James Martin, Grace Hopper, Gerald Weinberg, and Bill Gates.)

In this edition, he reflects the massive changes that have taken place since his 1997 First Edition. For instance, there’s extensive new coverage of agile methodologies: how they will -- and won’t -- help the death march project.

There’s also detailed coverage of time management, as well as a new chapter on the “dynamics” of task-related processes. We think you’ll especially like Yourdon’s coverage of “wargaming”: practicing your projects in advance, identifying your most likely obstacles, and preparing for them.

There’s also an entirely new chapter on negotiating the terms of your death march project. Yourdon knows full well that “it’s very easy to predict the outcome of negotiations over budget, schedule, and resources: You lose.” But you can lose less spectacularly: anything you can do to make your project’s conditions more tolerable will be worth the effort.

Yourdon spends an entire chapter on triage: making cold-blooded decisions about which features to sacrifice and focusing your resources on critical features that would “die” without them.

You’ll find excellent advice on getting enough great people (not easy in most places). You’ll learn how to gauge the commitment of your team and encourage it to the greatest extent possible (including a look at how money does and doesn’t motivate). Finally, Yourdon shows how to improve your team’s working conditions even if it means breaking -- no, bulldozing -- the rules.

When it comes to death march projects, there are no magic bullets. But this book is as close as it gets. Bill Camarda

Bill Camarda is a consultant, writer, and web/multimedia content developer. His 15 books include Special Edition Using Word 2000 and Upgrading & Fixing Networks for Dummies, Second Edition.

Booknews
Helps software developers survive projects that are "doomed to fail" and explains how to negotiate the best deal up front, manage people, set priorities, and choose tools and technologies. Walks through the entire project life cycle, showing both managers and developers how to deal with the politics of difficult projects and how to make the most of available resources. Includes chapter summaries, questions and answers between the author and other experts in the field, and a healthy dose of humor. Yourdon is a software developer and author of 25 computer books. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Read More Show Less

Product Details

  • ISBN-13: 9780131436350
  • Publisher: Prentice Hall
  • Publication date: 12/6/2003
  • Series: Yourdon Press Series
  • Edition description: Second Edition
  • Edition number: 2
  • Pages: 230
  • Sales rank: 854,266
  • Product dimensions: 6.96 (w) x 9.24 (h) x 0.63 (d)

Meet the Author

EDWARD YOURDON has been called one of the ten most influential people in software, and has been inducted into the Computer Hall of Fame alongside Charles Babbage, Seymour Cray, James Martin, Grace Hopper, and Bill Gates. An internationally recognized consultant, he is author or coauthor of more than 25 books, including Byte Wars, Managing High-Intensity Internet Projects, and Decline and Fall of the American Programmer. He co-developed the popular Coad/Yourdon methodology, co-founded the influential Cutter Consortium Business Technology Council, and serves on the Board of Directors of iGate and Mascot Systems.

Read More Show Less

Read an Excerpt

Preface

Our achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.—Eric Hoffer, Reflections on the Human Condition, aph. 157 (1973)

I know: You're intrigued by the title of this book, and you decided to peek inside to see what it's all about. But you're busy, busy, busy—and you don't know if you have the time to read yet another book about managing software projects. Especially if it's a book that tells you how things should be done in an ideal world where rational men and women make calm, sensible decisions about the budget, schedule, and resources for your software project.

You may have noticed that we don't live in an ideal world, and chances are that your project requires you to interact with people who seem anything but rational and whose decisions hardly seem calm or sensible. In other words, you're working on a death march project. The wonderful thing about the title of this book is that I don't even have to explain it: Every time I mention it to friends and colleagues, they just laugh and say, "Oh, yeah, you must be talking about my project!" Well, these days it's likely to be my project, and your project, and everyone else's project too—we're all working on death march projects, or so it seems.

The first question you should be asking yourself (though it may not occur to you until the end of your project) is: "Why on earth did I let myself get suckeredinto such a project?" I'll discuss this in the first chapter, because my experience as a consultant—visiting and observing many such projects from the sidelines—is that the world would be a healthier place if more of us had the guts to stand up and say, "Hell, no, I won't join this death march!"

But assuming there's no escape—e.g., there are no other jobs available or you've got some form of a "golden handcuff" relationship with your employer that strongly discourages you from leaving—the next question is: "How can I survive this project without ruining my health, my sanity, and my dignity?" If you're an optimist, you might even be wondering how you can conquer the obstacles before you and actually finish the death march project on time and under budget. But if you've been through a number of these projects before, you probably know that the odds are stacked against you and that survival is the best you can hope for.

Having worked in the software industry for over 30 years, I find that our profession has a rather interesting reaction to death march projects. In some parts of the industry, especially in Silicon Valley, such projects are glorified as a test of manhood, somewhat akin to climbing Mount Everest barefoot. I felt this way during my first few software projects back in the mid-1960s, and the fact that the same attitude prevails a generation later suggests to me that it's likely to be a permanent phenomenon, as long as technology continues to change as rapidly as it has been during my lifetime. Ours is not a mature industry: Every year there's a new Mount Everest to climb and a new crop of hotshot programmers who are convinced that they can run barefoot all the way to the top.

But another segment of our industry regards death march projects as embarrassing failures. We've all been bombarded with statistics about the prevalence of schedule delays, budget overruns, buggy software, disgruntled users, and outright project failures. We've been told repeatedly by consultants, gurus, and methodologists that the reason for all these embarrassments is that we've been using the wrong methods (or no methods at all), or the wrong tools, or the wrong project management techniques. In other words, death march projects exist because we're stupid or incompetent.

If you talk to battle-scarred veterans in the field—the ones who have gone through a couple of death march projects and have learned that it's really not fun to climb Mount Everest barefoot— you'll often hear them say, "Hey! I'm not stupid! Of course I would like to use the right methods and tools and project management approaches. But my senior management and my end-users won't let me. The reason we have such a ridiculous schedule for this project is that it was imposed upon us on the first day, before we had the faintest idea what the project was all about!" Conclusion: Death march projects occur because senior managers are Machiavellian bastards and/or because our users are naive and unrealistic.

No doubt there's some truth to all this: We do make a lot of stupid mistakes managing our projects, our senior managers do indulge in ridiculous political games, and our end-users do make unreasonable demands on us. I'm convinced that much of this is due to the rapid pace of change, combined with the usual disrespect that each new generation has for the advice offered by the previous generation. Why on earth should today's generation of Java-oriented hotshots pay any attention to the advice offered by my generation, whose formative programming experience took place 30 years ago in Autocoder and assembly language? And how should today's generation of business users know what kind of Web-based application is reasonable to ask for, considering that their predecessors were asking for mainframe-based online systems, with character-based dumb-terminal interfaces?

Whatever the explanation for the phenomenon, I've come to a sobering conclusion: Death march projects are the norm, not the exception. I think that today's software developers and project managers are pretty smart and are eager to manage projects in a rational way; I also think that today's business users and senior managers are much more computer-literate than they were a generation ago and much less naive about what software developers can be expected to deliver with finite resources. That doesn't stop both groups of smart individuals from embarking upon yet another death march project—because the competitive business pressures demand it and the new technological opportunities invite it. The business managers may be fully aware that a rational schedule for their new system would require 12 calendar months, but they'll also tell you emphatically that unless it's available in six months, the competition will grab the entire market for its new product or service. And the technical staff may be fully aware that new technologies like the Internet are still quite risky, but they will tell you that if the new technology does work, it will provide a strategic competitive advantage that makes it well worth the risk.

To put it another way, industry surveys from organizations such as the Standish Group, as well as statistical data from metrics gurus such as Capers Jones, Howard Rubin, and Larry Putnam, suggest that the average project is likely to be six to 12 months behind schedule and 50 to 100 percent over budget. The situation varies depending on the size of the project and various other factors, but the grim reality is that you should expect that your project will operate under conditions that will almost certainly lead to death march behavior on the part of the project manager and his or her technical staff. If a project starts off with these high-risk factors, there's going to be a lot of overtime and wasted weekends, and there's likely to be a lot of emotional and physical burnout before the end of the project.

So the real question is: If you can't avoid death march projects, how can you survive them? What should you do to increase your chances of success? Where should you be willing to compromise—and when should you be willing to put your job on the line and plan to resign if you can't get your way? That is what this book is about. These issues are as relevant for the manager in charge of the project as they are for the technical staff that actually does the hard work of designing, coding, testing, and documenting the system. I'll address both groups in the chapters that follow.

A word about managers and technical staff members: Some of the comments you'll see in the following chapters will imply that management is "evil" and that the project team members are innocent, downtrodden victims. Obviously, this is not the case for all projects and all companies, though the very existence of a death march project is usually the result of a conscious management decision. While the project team members may be willing participants in such projects, they usually don't propose them in the first place.

If you've decided at this point that you don't have time to read this book, here's a simple word of advice that may provide some value for the time you've invested in reading the preface: triage. If you're on a death march project, it's almost certain that you won't have the resources to provide all the functionality or "features" requested by the end-user within the allotted schedule and budget. You'll have to make some cold-blooded decisions about which features to sacrifice and which ones to focus your resources on. Indeed, some of the frivolous features will never be implemented, so it's best to let them die on their own. Other features are important but also relatively easy to implement, e.g., because they're a by-product of the vendor-supplied class library or Computer-Aided Software Engineering (CASE) tools that you're using. To use the medical metaphor of triage, these features will survive on their own. The difference between success and failure on a death march project often lies in the project team's ability to identify the critical features of the system that would "die" without an investment of substantial resources and energy.

Of course, there's more to surviving a death march project than just triage. I'll cover triage in Chapter 3, but we also need to look at peopleware issues, "process" issues, and issues of tools and technology. I've tried to be as concise as possible , so you should be able to finish the whole book in a couple of hours; if nothing else, it should give you a more realistic assessment of your next death march project.

However, please don't get the impression that this book is a "bible," or that it will provide "silver bullet" solutions to all of your problems. There are no guaranteed "right answers" in this book; what works in some companies and in some situations may not work in others. Equally important: the compromises that some managers and technical staff members are willing to make will prove unacceptable to others. I'll make what I consider to be reasonable suggestions, but it's up to you to decide which ones will work in your environment.

I also intend, on an ongoing basis, to collect advice from the field on my Web site at http://www.yourdon.com — from real project teams that have some practical tips on best practices, worst practices, and "breathalyzer test" questions. Even if you don't have enough money in your project budget to buy this book (such penny-pinching budgets are an indicator unto themselves of the risk associated with a death march project!), it won't cost you a penny to check the Death March Web page.

Whatever you decide to do, best of luck on your next death march project. And remember the words of Samuel Beckett:

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.—Samuel Beckett, Worstward Ho (1984)

Read More Show Less

Table of Contents

Preface.

1. Introduction.

Death March Defined.

Categories of Death March Projects.

Why Do Death March Projects Happen?

Politics, Politics, Politics.

Naive Promises Made by Marketing, Senior Executives, Naive Project Managers, and So on.

Naive Optimism Of Youth: “We Can Do It Over the Weekend”.

The “Startup” Mentality of Fledgling Entrepreneurial Companies.

The “Marine Corps” Mentality: Real Programmers Don't Need Sleep.

Intense Competition Caused by Globalization of Markets.

Intense Competition Caused by the Appearance of New Technologies.

Intense Pressure Caused by Unexpected Government Regulations.

Unexpected and/or Unplanned Crises.

Why Do People Participate in Death March Projects?

The Risks Are High, but So Are the Rewards.

The “Mt Everest” Syndrome.

The Naiveté and Optimism of Youth.

The Alternative Is Unemployment.

It's Required in Order to Be Considered for Future Advancement.

The Alternative Is Bankruptcy or Some Other Calamity.

It's an Opportunity to Escape the “Normal” Bureaucracy.

Revenge.

Summary.

Notes.

2. Politics.

Identifying the Political Players in the Project.

Owner.

Customers.

Shareholders.

Stakeholders.

Champions.

Determining the Basic Nature of the Project.

Levels of Commitment by Project Participants.

Analyzing Key Issues that Lead to Political Disagreements.

Conclusion.

Notes.

3. Negotiations.

Rational Negotiations.

Identifying Acceptable Tradeoffs.

Negotiating Games.

Negotiating Strategies.

What To Do When Negotiating Fails.

Notes.

References.

4. People in Death March Projects.

Hiring and Staffing Issues.

Loyalty, Commitment, Motivation, and Rewards.

Rewarding Project Team Members.

The Issue of Overtime.

The Importance of Communication.

Team-Building Issues.

Workplace Conditions for Death March Project.

Summary.

Notes.

References.

5. Death March Processes.

The Concept OF Triage.

The Importance OF Requirements Management.

SEI, ISO-9000 and Formal Versus Informal Processes.

Good-Enough Software.

Best Practices and Worst Practices.

Death March Meets XP.

Conclusion.

Notes.

References.

6. The Dynamics of Processes.

Models of Software Development Processes.

Mental Models.

Spreadsheet Models.

Static Versus Dynamic Models.

Visual Models.

An Example: Tarek Abdel-Hamid's Software Process Model.

Summary and Conclusions.

Notes.

References.

7. Critical-Chain Scheduling and the Theory of Constraints.

Introduction.

What Organizational Behaviors are Dysfunctional?

How Can We Change Dysfunctional Organizational Behavior?

Life in a Rational World.

Critical-Chain Scheduling.

Conclusion.

Notes.

References.

8. Time Management.

The Impact of Corporate Culture On Time Management.

Time Slippage from Stakeholder Disagreements.

Helping the Project Team Make Better Use of Time.

Notes.

9. Managing and Controlling Progress.

The “Daily Build” Concept.

Risk Management.

Additional Ideas for Monitoring Progress: Milestone Reviews.

Notes.

References.

10. Death March Tools and Technology.

The Minimal Toolset.

Tools and Process.

Risks of Choosing New Tools.

Conclusion.

Notes.

References.

11. Simulators and “War Games”.

Introduction.

The Concept of War Games.

Conclusion.

Notes.

References.

Index.

Read More Show Less

Preface

Preface

Our achievements speak for themselves. What we have to keep track of are our failures, discouragements, and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay.—Eric Hoffer, Reflections on the Human Condition, aph. 157 (1973)

I know: You're intrigued by the title of this book, and you decided to peek inside to see what it's all about. But you're busy, busy, busy—and you don't know if you have the time to read yet another book about managing software projects. Especially if it's a book that tells you how things should be done in an ideal world where rational men and women make calm, sensible decisions about the budget, schedule, and resources for your software project.

You may have noticed that we don't live in an ideal world, and chances are that your project requires you to interact with people who seem anything but rational and whose decisions hardly seem calm or sensible. In other words, you're working on a death march project. The wonderful thing about the title of this book is that I don't even have to explain it: Every time I mention it to friends and colleagues, they just laugh and say, "Oh, yeah, you must be talking about my project!" Well, these days it's likely to be my project, and your project, and everyone else's project too—we're all working on death march projects, or so it seems.

The first question you should be asking yourself (though it may not occur to you until the end of your project) is: "Why on earth did I let myself get suckered into such a project?" I'll discuss this in the first chapter, because my experience as a consultant—visiting and observing many such projects from the sidelines—is that the world would be a healthier place if more of us had the guts to stand up and say, "Hell, no, I won't join this death march!"

But assuming there's no escape—e.g., there are no other jobs available or you've got some form of a "golden handcuff" relationship with your employer that strongly discourages you from leaving—the next question is: "How can I survive this project without ruining my health, my sanity, and my dignity?" If you're an optimist, you might even be wondering how you can conquer the obstacles before you and actually finish the death march project on time and under budget. But if you've been through a number of these projects before, you probably know that the odds are stacked against you and that survival is the best you can hope for.

Having worked in the software industry for over 30 years, I find that our profession has a rather interesting reaction to death march projects. In some parts of the industry, especially in Silicon Valley, such projects are glorified as a test of manhood, somewhat akin to climbing Mount Everest barefoot. I felt this way during my first few software projects back in the mid-1960s, and the fact that the same attitude prevails a generation later suggests to me that it's likely to be a permanent phenomenon, as long as technology continues to change as rapidly as it has been during my lifetime. Ours is not a mature industry: Every year there's a new Mount Everest to climb and a new crop of hotshot programmers who are convinced that they can run barefoot all the way to the top.

But another segment of our industry regards death march projects as embarrassing failures. We've all been bombarded with statistics about the prevalence of schedule delays, budget overruns, buggy software, disgruntled users, and outright project failures. We've been told repeatedly by consultants, gurus, and methodologists that the reason for all these embarrassments is that we've been using the wrong methods (or no methods at all), or the wrong tools, or the wrong project management techniques. In other words, death march projects exist because we're stupid or incompetent.

If you talk to battle-scarred veterans in the field—the ones who have gone through a couple of death march projects and have learned that it's really not fun to climb Mount Everest barefoot— you'll often hear them say, "Hey! I'm not stupid! Of course I would like to use the right methods and tools and project management approaches. But my senior management and my end-users won't let me. The reason we have such a ridiculous schedule for this project is that it was imposed upon us on the first day, before we had the faintest idea what the project was all about!" Conclusion: Death march projects occur because senior managers are Machiavellian bastards and/or because our users are naive and unrealistic.

No doubt there's some truth to all this: We do make a lot of stupid mistakes managing our projects, our senior managers do indulge in ridiculous political games, and our end-users do make unreasonable demands on us. I'm convinced that much of this is due to the rapid pace of change, combined with the usual disrespect that each new generation has for the advice offered by the previous generation. Why on earth should today's generation of Java-oriented hotshots pay any attention to the advice offered by my generation, whose formative programming experience took place 30 years ago in Autocoder and assembly language? And how should today's generation of business users know what kind of Web-based application is reasonable to ask for, considering that their predecessors were asking for mainframe-based online systems, with character-based dumb-terminal interfaces?

Whatever the explanation for the phenomenon, I've come to a sobering conclusion: Death march projects are the norm, not the exception. I think that today's software developers and project managers are pretty smart and are eager to manage projects in a rational way; I also think that today's business users and senior managers are much more computer-literate than they were a generation ago and much less naive about what software developers can be expected to deliver with finite resources. That doesn't stop both groups of smart individuals from embarking upon yet another death march project—because the competitive business pressures demand it and the new technological opportunities invite it. The business managers may be fully aware that a rational schedule for their new system would require 12 calendar months, but they'll also tell you emphatically that unless it's available in six months, the competition will grab the entire market for its new product or service. And the technical staff may be fully aware that new technologies like the Internet are still quite risky, but they will tell you that if the new technology does work, it will provide a strategic competitive advantage that makes it well worth the risk.

To put it another way, industry surveys from organizations such as the Standish Group, as well as statistical data from metrics gurus such as Capers Jones, Howard Rubin, and Larry Putnam, suggest that the average project is likely to be six to 12 months behind schedule and 50 to 100 percent over budget. The situation varies depending on the size of the project and various other factors, but the grim reality is that you should expect that your project will operate under conditions that will almost certainly lead to death march behavior on the part of the project manager and his or her technical staff. If a project starts off with these high-risk factors, there's going to be a lot of overtime and wasted weekends, and there's likely to be a lot of emotional and physical burnout before the end of the project.

So the real question is: If you can't avoid death march projects, how can you survive them? What should you do to increase your chances of success? Where should you be willing to compromise—and when should you be willing to put your job on the line and plan to resign if you can't get your way? That is what this book is about. These issues are as relevant for the manager in charge of the project as they are for the technical staff that actually does the hard work of designing, coding, testing, and documenting the system. I'll address both groups in the chapters that follow.

A word about managers and technical staff members: Some of the comments you'll see in the following chapters will imply that management is "evil" and that the project team members are innocent, downtrodden victims. Obviously, this is not the case for all projects and all companies, though the very existence of a death march project is usually the result of a conscious management decision. While the project team members may be willing participants in such projects, they usually don't propose them in the first place.

If you've decided at this point that you don't have time to read this book, here's a simple word of advice that may provide some value for the time you've invested in reading the preface: triage. If you're on a death march project, it's almost certain that you won't have the resources to provide all the functionality or "features" requested by the end-user within the allotted schedule and budget. You'll have to make some cold-blooded decisions about which features to sacrifice and which ones to focus your resources on. Indeed, some of the frivolous features will never be implemented, so it's best to let them die on their own. Other features are important but also relatively easy to implement, e.g., because they're a by-product of the vendor-supplied class library or Computer-Aided Software Engineering (CASE) tools that you're using. To use the medical metaphor of triage, these features will survive on their own. The difference between success and failure on a death march project often lies in the project team's ability to identify the critical features of the system that would "die" without an investment of substantial resources and energy.

Of course, there's more to surviving a death march project than just triage. I'll cover triage in Chapter 3, but we also need to look at peopleware issues, "process" issues, and issues of tools and technology. I've tried to be as concise as possible , so you should be able to finish the whole book in a couple of hours; if nothing else, it should give you a more realistic assessment of your next death march project.

However, please don't get the impression that this book is a "bible," or that it will provide "silver bullet" solutions to all of your problems. There are no guaranteed "right answers" in this book; what works in some companies and in some situations may not work in others. Equally important: the compromises that some managers and technical staff members are willing to make will prove unacceptable to others. I'll make what I consider to be reasonable suggestions, but it's up to you to decide which ones will work in your environment.

I also intend, on an ongoing basis, to collect advice from the field on my Web site at http://www.yourdon.com — from real project teams that have some practical tips on best practices, worst practices, and "breathalyzer test" questions. Even if you don't have enough money in your project budget to buy this book (such penny-pinching budgets are an indicator unto themselves of the risk associated with a death march project!), it won't cost you a penny to check the Death March Web page.

Whatever you decide to do, best of luck on your next death march project. And remember the words of Samuel Beckett:

Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.—Samuel Beckett, Worstward Ho (1984)

Read More Show Less

Customer Reviews

Average Rating 3.5
( 5 )
Rating Distribution

5 Star

(2)

4 Star

(1)

3 Star

(1)

2 Star

(0)

1 Star

(1)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 5 Customer Reviews
  • Anonymous

    Posted July 2, 2014

    The story of my life

    The story of my life

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted September 28, 2007

    A good start

    This book is going to be as influential as 'The Mythical Man-Month'. Yourdon tackles some issues that need to be addressed in the modern software development industry. He does offer some insightful analysis as to why things get as bad as they do, and his strategies and recommendations are useful. However, this book is typical of 'guru' books in that there's enough useful information in it for few brilliant articles, but not enough to fill a whole book. The book is 230 pages long but a good quarter of it is verbatim copy of E-mails Mr. Yourdon received from other contributors. It is right and appropriate for him to cite his sources, but there has to be a better way of doing it. There's also a fair bit of filler material: white space, bulleted lists, diagrams, and unnecessary repetition. The writing is cumbersome, such that if there's a choice between a simple word and a complex word ('use' and 'utilize', for example) Yourdon picks the bigger word every time as if he's getting paid by the letter. The personal anecdotes and stories are interesting, but I buy technical books for useful content, not to 'chew the fat' with the author.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted June 23, 2003

    I read this book in one evening.

    If nothing else you will find the examples in the book humorous because they are just like the projects you've been on. I found a whole list of ideas for ways to deal with problems on my own project. Not just for project managers either.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 13, 2002

    Political aspects of your project

    The book illustrates that politics exists in your project as well. To determine all major political players, involved in the project is the task of any participant: from the stakeholder and project manager to the minor developer. It¿s a hard task to spot all the players, but once you did it, your project will get more chances to survive and you will keep your sanity. This book doesn¿t have easy answers, but it will encourage you to start analyzing things which you never thought about.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 20, 2010

    No text was provided for this review.

Sort by: Showing all of 5 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)