Lean development #2

In chapter two, Amplify Learning, Mary Poppendieck writes that the preferred method for solving complex problems is to use the scientific method. You observe, create a hypothesis, then devise an experiment to test the hypothesis. The interesting thing, she writes, is that to maximize learning, you have to have a 50% probability of failure when testing your hypotheses. In other words, if your hypotheses are always correct, you don’t learn as much. It is by failing that you learn. This speaks loudly in favor of experimentation in software development, either by creating prototypes or (which is even better) by writing real code.

One thing I didn’t know: you often see the familiar Fred Brooks quote: “Plan to throw one away, you will anyway.” What he referred to was that, in order to learn enough to develop a system, you need to create it twice: first you create an experimental prototype, then you create the actual system. However, he retracted this twenty years later, saying that it implied a sequential process, a waterfall process – which he says is wrong: to succeed, you need an incremental process, with progressive refinement. I guess that some parts of a system will be clear the first time around, while some parts will have to be rewritten a few times.

Poppendieck quotes Ed Yourdon as saying that any piece of code needs to be rewritten three or four times to be consistuted as an elegant, professional piece of work. For prose, we take this for granted, he says, why not for code?

Today, iterative, adaptive processes are widely regarded as the most suitable for software development. But Poppendieck writes that upon trouble, we are inclined to turn to a more disciplined process, that in fact is sequential, or waterfall: we first want the requirements to be signed off by the customer, then we consider them “frozen” and start implementing, resisting any changes the customer wants, and so on. I feel that this is true. This, she continues, contradicts control theory, since you are actually lengthening the feedback loop. What you must do is to shorten it: do shorter iterations, with more frequent feedback from the customer; accept new requirements only at the start of the iterations, and so on.

With too short iterations, you get what in control theory is called thrashing – that is, that the system (the team of developers) never has time to react to feedback until new feedback arrives. At the other extreme, with too long iterations, you get oscillation – when you act on incoming feedback, reality has plenty of time to deviate until feedback arrives again, so the “course corrections” are too big. The appropriate iteration length depends on local circumstances, though. You’ll have to try and see what works. My gut feeling is, however, that it is better to start with shorter iterations. For XP, the recommended length is 1–3 weeks, and I’d say that many are inclined to pick 3 weeks in the beginning, but I feel that they would be in a better position to judge after having tried one-week iterations. I guess that if you are unfamiliar with agile processes, you feel that there will be too much time in meetings with so short iterations.

The above was posted to my personal weblog on January 8, 2003. My name is Peter Lindberg and I am a thirtysomething software developer and dad living in Stockholm, Sweden. Here, you’ll find posts in English and Swedish about whatever happens to interest me for the moment.


Related posts:

Posted around the same time:

The seven most recent posts:

  1. Tesugen Replaced (October 7)
  2. My Year of MacBook Troubles (May 16)
  3. Tesugen Turns Five (March 21)
  4. Gustaf Nordenskiöld om keramik kontra kläddesign (December 10, 2006)
  5. Se till att ha två buffertar för oförutsedda utgifter (October 30, 2006)
  6. Bra tips för den som vill börja fondspara (October 7, 2006)
  7. Light-Hearted Parenting Tips (September 16, 2006)