- Because our customers don’t know what they want, they find out from the people that want the system. They sometimes get this wrong.
- Because I don’t know what to code, I find out from our customer. I sometimes get this wrong.
- Because I make mistakes while coding, I work with an IDE. My IDE corrects me when I’m wrong.
- Because I make mistakes while thinking, I work with a pair. My pair corrects me when I’m wrong.
- Because my pair is human and also makes mistakes, we write unit tests. Our unit tests correct us when we’re wrong.
- Because we have a team who are also coding, we integrate with their code. Our code won’t compile if we’re wrong.
- Because our team makes mistakes, we write acceptance tests that exercise the whole system. Our acceptance tests will fail if we’re wrong.
- Because we make mistakes writing acceptance tests, we get QA to help us. QA will tell us if we’re wrong.
- Because we forget to run the acceptance tests, we get Cruise Control to run them for us. Cruise Control will tell us if we’re wrong.
- Because we forget to maintain the acceptance tests, we get QA to check that the system still works. QA will tell us if it’s wrong.
- Because we only made it work on Henry’s laptop, we deploy the system to a realistic environment. It won’t work if the deployment is wrong.
- Because we sometimes misunderstand our customer, we showcase the system. Our customer will tell us if we’re wrong.
- Because our customer sometimes misunderstands the people that want the system, we put the system in production. The people who want it tell us if we’re wrong.
- Because it costs money to get it wrong, we do all these things as often as we can. That way we are only ever a little bit wrong.
- All posts are released under CC 3.0 by-sa unless otherwise stated.
Follow me on Twitter!My Tweets
- breaking models
- business value
- capability red
- deliberate discovery
- evil hat
- learning models
- open source
- real options
- spike and stabilize