Planning
Preparation
- quality at the beginning (design)
- quality in the middle (construction)
- quality at the end (testing)
- Preparation is the goal of risk reduction.
Causes of Incomplete Preparation
- Lack of experience.
- Lack of self-restraint on the part of developers.
- Managers don’t understand.
Arguments for Planning
- The most common project risks in software development are poor requirements and poor project planning.
Appeal to Logic
- Avoids expensive, incorrect choices.
- From a management point of view, planning means determining the amount of time, number of people, and number of computers the project will need.
- From a technical point of view, planning means understanding what you want to build so that you don’t waste money building the wrong thing.
Appeal to Analogy
- When you build other things (e.g. a house), you need to plan before construction.
- If you are planning a highly iterative project, you will need to identify the critical requirements and architectural elements that apply to each piece you’re constructing before you begin construction.
- A builder who is building a housing development doesn’t need to know every detail of every house in the development before beginning construction on the first house.
- You don’t start decorating the Christmas tree until you’ve put it in the stand.
- You don’t start a fire until you’ve opened the flue. You don’t go on a long trip with an empty tank of gas.
- You don’t get dressed before you take a shower.
- You don’t put your shoes on before your socks.
Appeal to Data
- Studies over the last 25 years have proven conclusively that it pays to do things right the first time; unnecessary changes are expensive.
- Errors caught at the end of construction or after release are 10-100 times more expensive.
- On average debugging and associated reword takes ~50% of the time spend in a typical development cycle.