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".
