• 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
  chapter.
• 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
  projects.

_{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
  organization.
• 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}