Death March

  • Title: Death March
  • Author: Edward Yourdon
  • Paperback: 304 pages
  • Publisher: Prentice Hall PTR; 2 edition (December 7, 2003)
  • ISBN: 013143635X

Two things of interest I found in Death March by Edward Yourdan:

  • Formal risk management — This is a concept I’ll discuss later in
    this chapter.
  • Agreement on interfaces — hardware interfaces, software interfaces,
    and interfaces between your system and other external systems.
  • Peer reviews — inspections, walkthroughs, reviews, etc. These are
    commonly understood, but often rejected by death march projects, for they
    feel the effort will slow them down. Intellectually, most of us agree that
    peer reviews are beneficial, but given the kind of pressure we see in death
    march projects, there’s a tendancy for everyone to hunker down and churn out
    his or her own work, without bothering to have it reviewed by other team members.
  • Metric-based scheduling and management — this says that we should
    base our schedules and estimates on metrics derived from previous projects.
    But as noted earlier, there may not have been any previous death march projects,
    and if there were any, it’s unlikely that anyone bothered recording any useful
    metrics (other than a body count of human casualties). But, if there are any
    metrics available from “normal” projects, these can be used to calibrate the
    estimates being produced in the death march project — if only to see how
    hysterically optimistic those estimates really are!
  • Binary quality gates at the “inch-pebble” level — i.e., rather
    than having milestones every three months, during which the project team reports
    that they’re 97 percent done with all coding, there should be weekly, or even
    daily inch-pebbles with “binary” indications of progress. One means
    of accomplishing this is the “daily build” strategy discussed later in this
  • Project-wide visibility of project plan and progress vs. plan
    this is consistent with my recommendations in earlier chapters. Things are
    tough enough in a death march project without having the manager hide the
    status from the rest of the team.
  • Defect tracking against quality targets — one of the ideas here
    is that defects identified, tracked, and resolved early in the development
    process cannot only give an indication of the defect levels in the final delivered
    system, but can also eliminate defects when they are relatively inexpensive,
    rather than waiting until the system testing stage of the project.
  • Configuration management — whether this is called version control,
    source code management, or some other term, it’s usually regarded as an essential
    practice in most high-pressure projects.
  • People-aware management accountability — alas, this is something
    that most death march projects don’t pay enough attention to; as mentioned
    earlier, manay death march projects are set up as suicide missions or kamikaze-style

Death March, Edward Yourdan, pp. 152-153.

  • Innocent (has never heard of Technology X) — this obviously requires
    no time at all.
  • Aware (has read an article about Technology X) — roughly an hour,
    in most cases, is enough for a software developer to be in a position where
    he or she can voice strong opinons about the advantages and disadvantages
    of the tool, even though he or she has never seen or used it.
  • Apprentice (has attended a five-day workshop) — a week, perhaps
    compressed into two days because of the pressure of a death march project.
    But, note that at this point, the developer has probably done nothing more
    than play with canned turorials provided by the vendor, or dabbled with a
    small exercise to illustrate the features of the tool. He or she hasn’t encountered
    the glitches, shortcomings, and “gotchas” of the tool; he or she hasn’t seen
    how (or if) it will scale up for large, complex projects; he or she hasn’t
    tried to integrate it with most of the other tools in the environment.
  • Practitioner (ready to use Technology X on a real project) — a month
    is probably required to explore the nuances of the tool and become sufficiently
    comfortable to use the tool on a “real” project.
  • Journeyman (uses Technology X naturally on the job; complains bitterly
    if it is taken away) — this usually takes 6-12 months, and if the tool really
    is a silver bullet, the developer becomes an evangelist, doing his or her
    best to persuade everyone that it’s the most wonderful tool on earth.
  • Master (has internalized the details of Technology X; knows when
    to break the rules) — usually two or three years, which also means that the
    developer has survived through two or three new product releases, has found
    all of the support groups and discussion groups on the Internet, and knows
    all of the unlisted phone numbers for the technical support gurus at the vendor’s
  • Expert (writes books, gives lectures at conferences, looks for ways
    to extend Technology X into new galaxies) — Page-Jones was focusing on methodologies
    in his paper, and it’s not clear that this applies to tools and technology.

Death March, Edward Yourdan, p. 187, from the Sevent Stages of Software Engineering Mastery by Page-Jones


There are no revisions for this post.

Posted in Books, Computer, Tags:

Comments are closed.