Change is Inevitable
  • Software is like modeling clay, not rocks

  • Let the customer play with the clay [action bar]

  • Software is too complex to specify completely

  • You're only done when the customer says so

  • Change is the customer's prerogative

Notes:

Software is not rock. It's clay. Indeed, it is more malleable than all physical media. This mutability is ignored by classical methodologies. Make the most out of the mutability, don't hide behind clay pretending it is rock. Look what happened to the three little piggies.

[action bar] One good example of this was with the action bar on our investment club site. We had the concept of an action bar in our prototype. Our initial users liked it, but we didn't have any over the shoulder experience. When we launched, users were having a really hard time finding the actions in the action bar. We sat in on some users. The problem turned out to be that the bar was a solid color with embedded buttons. When we removed the bar background, it was much more visible. We and our prototype customers were too close the solution and expected to see the action bar there.

It is rare for the customer to know exactly what she wants before she sees something. There's nothing wrong with going back and getting different rocks. It's a learning experience. You learn where you can find all different types of rocks. This will help you later in the project when you need a slightly different type of rock.

Software is inherently complex. A specification can't capture its essence without becoming software in itself. Many people have tried to execute specifications directly. This is actually very valuable, but only through specialized interpreters. It's called declarative programming, which is essentially extreme refactoring. Writing the specification is then just like writing software.

As the software artifact is realized and the customer plays with it, she'll learn more about the type of solution she wants. In classical methodologies this is called feeping creaturism, but in XP and other agile methodologies, this is just part of solving the problem for the customer.

The customer is driving, not the programmer. The customer shouldn't be told "no", unless the solution is not possible. It's the customer's job to decide whether a solution is "too expensive".