zerosleeps

• 110g self-raising flour
• ¼ teaspoon salt
• 15g margarine
• 55g sugar
• 1 beaten egg
• 70ml milk
• Lemon essence

Mix flour and salt, and rub in margarine. Mix in sugar, egg, and milk. Add lemon essence.

Sandi Metz in the opening chapter of Practical Object-Oriented Design in Ruby: An Agile Primer:

Agile believes that your customers can’t define the software they want before seeing it, so it’s best to show them sooner rather than later. If this premise is true, then it logically follows that you should build software in tiny increments, gradually iterating your way into an application that meets the customer’s true need. Agile believes that the most cost-effective way to produce what customers really want is to collaborate with them, building software one small bit at a time such that each delivered bit has the opportunity to alter ideas about the next. The Agile experience is that this collaboration produces software that differs from what was initially imagine; the resulting software could not have been anticipated by any other means.

If Agile is correct, two other things are also true. First, there is absolutely no point in doing a Big Up Front Design (BUFD) (because it cannot possibly be correct), and second, no one can predict when the application will be done (because you don’t know in advance what it will eventually do).

It should come as no surprise that some people are uncomfortable with Agile. “We don’t know what we’re doing” and “We don’t know when we’ll be done” can be a difficult sell. The desire for BUFD persists because, for some, it provides a feeling of control that would otherwise be lacking. Comforting though this feeling may be, it is a temporary illusion that will not survive the act of writing the application.

BUFD inevitably leads to an adversarial relationship between customers and programmers. Because any big design created in advance of working software cannot be correct, to write the application as specified guarantees that it will not meet the customer’s needs. Customers discover this when they attempt to use it. They then request changes. Programmers resist these changes because they have a schedule to meet, one that they are very likely already behind. The project gradually becomes doomed as participants switch from working to make it succeed to striving to avoid being blamed for its failure.

Doughnut Time, 37° 49′ 3″ S, 144° 57′ 57″ E

From the opening paragraph of chapter 12 of The Flying Kangaroo:

The aviation industry has changed to such an extent that it’s difficult to imagine some of the characters who worked in Qantas in years past ever holding down a job at the airline today. Most would not take offence if you suggested they would find it hard to reconcile themselves with either the advances in technology or perhaps the pressures of doing business in an increasingly competitive world. Broadly speaking too, in aviation and most other industries, the days of the colourful people would no longer be tolerated in an environment of shareholder interests and 24-hour media scrutiny.