Lecture 31: Plan to Throw One Away / Hatching a Catastrophe

Today's Lecture

Brooks says
- Plan to throw one (a software system) away; you will, anyhow.
Why?
- Consider our example of chemical engineers
  - Scaling a laboratory result up to actual (and practical) use requires a pilot step
  - Chemical engineers will not try to take a desalination technique from a test tube to processing 2,000,000 gallons of salt water a day
  - Instead, they will scale up first to a gallon, then ten gallons, then 100 gallons, etc. eventually learning how to reach their target goal of 2,000,000 gallons a day

Software projects typically plan to deliver the first thing they build to customers
- Problems
  - These systems are typically hard-to-use, buggy, inefficient, etc.
  - Experience shows that you will discard a lot of the first implementation anyway! (Multics paper, 1972)
Note: this is in stark contrast to the Agile style of software development and in contrast to the data of a MIT Sloan School of Management study
- MIT Sloan Management Review published an analysis of software development practices in 2001
- Strong correlation between quality of software system and the early delivery of a partially functioning system
  - the less functional the initial delivery the higher the quality of the final delivery!
- Strong correlation between final quality of software system and frequent deliveries of increasing functionality
  - the more frequent the deliveries, the higher the final quality!
One difference between what Brooks is talking about and Agile methods is that the first delivery under Agile methods is a partial system that may only implement a single user-requested feature.

Brooks is essentially arguing for rapid prototypes (something which is built into the core of Agile Methods)
- They help gain early feedback
- They are intended from the start to be thrown away
  - BUT be sure your client / user knows this!
But rather than pursue that topic explicitly, he instead focuses on planning for change in a large software project

A programmer delivers satisfaction of a user need rather than any tangible product
- And both the actual need and the user’s perception of that need will change as programs are built, tested, and used. [Cosgrove, 1971]
Other factors
- hardware, assumptions, and environment

Culture must be conducive to documenting decisions; otherwise nothing gets documented
- … the reluctance to document designs is not due merely to laziness or time pressure. Instead it comes from the designer's reluctance to commit himself to the defense of decisions which he knows to be tentative.
Brooks' other points consider
- need to avoid the “too valuable” syndrome in which senior people believe they are too important to program
  - job titles
    - Some labs abolish all job titles, every employee is simply a “member of the technical staff”. Other companies, like IBM, have dual ladders of advancement for management and development types.
  - keep senior people trained, so if the project needs them to join the development effort, they still have the skills to do so
  - use team organization techniques, such that prestige is associated with top development jobs

An engineer is typically very careful in designing a system the first time
- He or she realizes that they are working in uncharted territory
- Extraneous features get delayed until…
The Second System!
- Now, you’ve got some experience and you want to throw everything into the design!

The Mythical Man-Month recommends
- avoiding architects on their second systems
- and throwing out your first system
Well, which is it?!?
- With respect to the former
  - Brooks was speaking of the second “deployed” system
- With respect to the latter
  - Brooks was referring to your first implementation before the “first release”, e.g. avoid turning rapid prototypes into your first deployed system

How does a project get to be a year late?
- One day at a time!
Major Calamities are “easy” to handle
- The whole team pulls together and solves it
It’s the day by day slippage that is harder to recognize
- People are sick; machines go down, etc.

First, have a schedule!
Second, have milestones
- Not “coding complete”
- But “specifications signed by architects”
- Or “debugged component passes all tests”
Government data
- estimates made and revised two weeks early do not change as the start time draws near, no matter how wrong they end up being
- overestimates come steadily down as the activity proceeds
- underestimates do not change until scheduled time draws near

Third, track the critical path
- who is waiting on who to finish what
- Software exists for this: Microsoft Project, OmniPlan, etc.
Fourth, address the “status disclosure problem”
- Managers must distinguish between action meetings and status meetings
  - If inappropriate action is taken in response to a status report, it discourages honest status reports
    - better to schedule an action meeting after the true status is known
- Rule of thumb on schedules: have two dates, “scheduled” and “estimated”
  - the former is owned by the top level product manager
  - the latter is owned by the manager directly involved with the artifact
  - the idea is to encourage the lower-level managers to give accurate estimates and to allow the product-manager to detect problems with the overall schedule ahead of time

The Second-System Effect
- Designers, having been restrained for version 1.0, tend to go too far in designing version 2.0
Plan to Throw One Away
- Do not ship the first implemented system, it will not be ready, you need to plan to throw your first implementation away
Hatching a Catastrophe
- How do projects get late? One day at a time!