Fail Fast, Learn Fast, Act Fast

I read with some interest Alan Shalloway's blog "Why I Hate Fast Fail" -- I highly recommend you read it.    Additionally, if you are reading this there is a good chance that you may know me professionally and know I frequently say "Fast fail, Fast fail...." The title of Alan's blog does not make me feel a need to "defend myself" -- quite the contrary, I agree with his basic point -- the desire to be precise in our language on what we mean by "fast fail".    Quoting from his post -- "Fail fast is not our goal. Learn fast is."   My corollary to his statement is that we seek to "act fast".    My use of the term "fast fail" comes from seeing how it is difficult to learn when there are too many failures and/or cascading failures to analyze.

For example if we had some tests that required for a room to be illuminated.   We might "measure" how effective a reading rate is for an individual at various levels of light.    Suppose the 1st "test case" is "turn on light switch near door" and no light comes on at all.    If we waste time analyzing the "failure" of the subsequent reading rate test (in a dark room) before we learn why the light switch test failed, we waste valuable learning time.   Does the light fail to come on because of a switch faulty, the light bulb itself, the wiring, something else?   We need to quickly learn which it is, and act quickly to take corrective action so that we can again repeat the test cases.

I have spent years watching otherwise talented engineers be overwhelmed to by "too many" failures that they dismiss the feedback (learning) that is possible from the testing process.    Don't design your test to fail quickly, design them so that a failure produces a learning opportunity that can't be ignored -- that must be acted upon. Once the value of these learning opportunities is realized, no competent software engineer will resist the chance to respond (act) quickly.     I am now adjusting my mantra to "fail fast, learn fast, act fast".