onsdag den 14. september 2011

Why is it good to fail fast?


The concept of failing fast seems to be part of much agile and lean thinking. However the concept is not in the agile manifesto nor the principles behind it. Traditionally failing is not seen as something good so that got me wondering why agile think it is good and if there is both a right way and a wrong way to fail fast?

In agile we do want to be able to respond quickly to changes and most agile methods (1) prefer short iterations and it is also one of the guinding principles that we should deliver software frequently. The reason we want short iterations is so we can quickly get feedback, and respond accordingly.

But failing fast is not just something related to iterations and feedback – failing fast has also become somehting to strive for in the daily work and coding. For example in this article by Jim Shore he tells about failing fast in code and how that can help you debug faster and build more robust code.

However if I was to tell a team to fail fast and gave them Jims article as an example, it could still easily be viewed as one one to solve a particular problem and not an explanation of why it is generally good to fail fast.

Reading the article something else hit me when Jim starts to talk of assertions, how and when to put them in your code, and how to structure the message that you want the assertion to give. Perhaps it is not the failing fast that is important, it is the fact the we get good information about a problem early on – or in other words: we get structured feedback that lets us act on it.

That harmonises very good with this article by Braden Kelley that I found while researching why failing fast is good. The authors advocate that the central question you should always as yourself when experimenting is: ”What do we hope to learn from this effort?”. And I think that is the same that Jims does with his assertions – he only inserts them when he can learn something significant from them, and uses a lot of time structruring the information he gets back – i.e. he thinks about what he hope to learn from inserting the assertion at precisely that place.

So to me ”fail fast” cannot be seen as a meme in itself – it has to be put into a context and serve a purpose before it becomes valuable. Failing is just one outcome of an experiment and unless you have procedures in place to learn form it (like the Deming circle: Plan-Do-Check-Act) or it holds no value.

Being a language oriented person I agree with Braden Kelley that failing is a negative word, and since what we really want people to do when we say fail fast is learn fast, why not just say that: ”Learn fast”. To me that much better catches the thinking behind agile and lean than fail fast.

  1. I say most because I do not know all agile methods out there. However all the ones I know prefer short iterations.

Ingen kommentarer:

Send en kommentar