Feedback

This post was originally published here.

I found a great list of items about feedback here. For a TFS version, substitute “Automaton” or “Orcas Beta 1” for “Cruise Control”.

• Because our customer doesn’t know what he wants, he finds out from the people that want the system. He sometimes gets 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. I’ve lost count the number of times better feedback has enabled me to make quicker and better decisions in development. I’ve also lost count the number of times lack of feedback or lack of timely feedback came back and bit me later. That’s why we see so many efforts to automate builds and tests. It’s no secret that better feedback and communication from business owners increases the likelihood of success on a project. It follows then that better feedback and communication from our code should also give a similar effect.