fail-fast-fail-early


What does the expression “Fail Early” mean, and when would you want to do so?


What does the expression "Fail Early" mean, and under what circumstances is this approach most useful, and when would you avoid the approach?
Essentially, fail fast (a.k.a. fail early) is to code your software such that, when there is a problem, the software fails as soon as and as visibly as possible, rather than trying to proceed in a possibly unstable state.
Fail Fast
by Jim Shore
edited by Martin Fowler
http://www.martinfowler.com/ieeeSoftware/failFast.pdf
...
Fortunately, there’s a simple technique that
will dramatically reduce the number of these
bugs in your software. It won’t reduce
the overall number of bugs, at
least not at first, but it’ll make
most defects much easier to find.
The technique is to build your
software to “fail fast.”
Immediate and
visible failure
Some people recommend making
your software robust by working
around problems automatically.
This results in the software “failing slowly.”
The program continues working right after an
error but fails in strange ways later on.
A system that fails fast does exactly the opposite:
when a problem occurs, it fails immediately
and visibly. Failing fast is a nonintuitive
technique: “failing immediately and visibly”
sounds like it would make your software more
fragile, but it actually makes it more robust.
Bugs are easier to find and fix, so fewer go into
production.
...
Also note the related concept of a fail-fast iterator - an iterator that, after a certain modifications to the collection outside of the iterator, throws as soon as possible rather than proceed in a potentially unstable, or non-deterministic state.
Failing early embodies the idea that when building software the earlier you fail or a test fails or you find a bug the easier it is to correct (and cheaper as well). It also applies to your business model. Better to find out early (in beta for example) than after you have launched.
"Fail Early" means that the program should raise an exception and stop working if something goes wrong. (It is described in the Pragmatic Programmer's list of tips as Crash Early)
In my bioinformatics work, I tend to use a "Fail Early" approach because my highest concern is ensuring correctness. By contrast, Rails allows you to hide failures. For example, Rails' try allows you to call something on an object, and it won't raise an exception if that object is nil. I guess this is because with web sites, ensuring that the program keeps running is more important than correctness.
I once had a junior oracle programmer working for me who put an "ignore everything" exception block around all his code so errors were never seen. This initially made his code look impressive but:
A) Bugs took far longer to find;
and
B) I lost all (well, 80% of my) faith in his abilities after that.
I have since taught people that this is a very bad thing as it hides errors.
Do not confuse this with a code module being able to cope with poor quality inputs (such as HTML which is not also valid XHTML in a browser) - these do not need to result in a failure at all. More likely, they did cause a failure many years ago but the way to resolve it was to make the system take reasonable assumptions about how to recover.
It means: "Catch bugs as early as possible". If possible, you want to know they are there as soon as they are there =).
The earlier you catch a bug, the cheaper it is to remove it. If you could know the bug right at the time you wrote the buggy line, it would be awesome. You would know exactly what you were intending to do, and have the most power to remove that bug quickly.
On the other hand, if you just catch the bug one month later, or after it's released, the damage is a LOT greater. Users already have to deal with it, you won't remember what you were thinking so well (or maybe you won't be even working for the company anymore, so someone will need to find out what your thoughts were).

Related Links

What does the expression “Fail Early” mean, and when would you want to do so?

Categories

HOME
shell
deep-learning
zend-framework
fftw
jelastic
requirements
opendj
zip
mapbox
special-characters
octave
speech-synthesis
intercom
mongodb-csharp
libusb
do-while
dynamic-sql
nodemcu
lilypond
visual-studio-extensions
dynamically-generated
mount
delimiter
handler
carrierwave
google-earth
magento-1.8
rselenium
sendbird
roblox
apic
demo
visa
levenshtein-distance
subclipse
wc
x++
flask-restful
opennms
aquamacs
pair-programming
scalding
edit
reshape
py2neo
universal-analytics
smartfoxserver
webjars
google-cloud-console
vulcanize
hclust
vorpal.js
firebase-security
appscale
cfchart
bizagi
cda
fuzzywuzzy
mobiledoc-kit
concurrentmodification
intel-c++
dock
toolkit
haskell-warp
sha512
graphics2d
document-repository
nodelist
beatsmusic
browserify-shim
tweenlite
xml-namespaces
verold
grails-domain-class
reflector
functional-java
maven-scm
square-bracket
xmltodict
rfc5322
ebay-lms
observium
scringo
cmmi
epiceditor
cardreader
bjyauthorize
device-width
qtconcurrent
iboutlet
ilasm
google-maps-mobile
event-receiver
dataform
socketserver
silent
globals
non-clustered-index
eclipse-marketplace
filesystemobject
wcf-instancing
asynchronous-wcf-call
sqlobject
technical-debt
ifilter

Resources

Database Users
RDBMS discuss
Database Dev&Adm
javascript
java
csharp
php
android
javascript
java
csharp
php
python
android
jquery
ruby
ios
html
Mobile App
Mobile App
Mobile App