What does the expression "Fail Early" mean, and under what circumstances is this approach most useful, and when would you avoid the approach?
views:
196answers:
4
A:
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).
Samuel Carrijo
2010-05-11 00:00:24
Again, not the right answer. You have essentially the same point as Steve Robillard, and the same mistake I'm afraid. Failing early is what you should do with exceptions at runtime!
NomeN
2010-05-11 00:13:16
@NomeN: To be fair, Samuel's describing the "why", not the "how".
Andrew Grimm
2010-05-11 00:31:25
This is the correct answer and it was discovered decades before programming languages evolved to provide structured exceptions at the language level.
Windows programmer
2010-05-11 00:44:43
+3
A:
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.
Steve Robillard
2010-05-11 00:01:50
Nope, although what you say is a correct point it is not connected to the term "failing early". Andrew Grimm has the right explanation (to his own question no less!.
NomeN
2010-05-11 00:10:06
@NomeN: "The Passionate Programmer" suggests "failing early" should apply to business as well: if there's something going wrong, tell other people, don't cover it up.
Andrew Grimm
2010-05-11 00:30:14
Again, this is the correct answer and it was discovered decades before programming languages evolved to provide structured exceptions at the language level. (Also this correct answer was posted 2 minutes later than the other correct answer, the one which is falsely asserted to be "Again, not the right answer.)
Windows programmer
2010-05-11 00:46:17
Indeed. If a project or business has to fail, it's better to fail it early than late (you'll save some money).
Pascal Thivent
2010-05-11 07:11:48
+5
A:
"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.
Andrew Grimm
2010-05-11 00:04:52
Er. Did you set this up? It's ok for people to answer their own questions, but you answered pretty completely, a mere 5 minutes after you asked the question, which makes me think you already knew the answer before you posed the question
Michael Mrozek
2010-05-11 00:12:58
@michael mrozek: To be fair, it is not a complete answer to his original question. But it would be less suspicious as an edit of the question than an answer
NomeN
2010-05-11 00:18:35
@Michael, @NomeN: Can you link to something in meta expanding on your opinion?
Andrew Grimm
2010-05-11 00:27:19
Yes, exceptions are a perfectly good example, a perfectly good tip of the iceberg of situations where failing early brings the benefit of saving immense expense down the line. Imagine if Toyota's acceleration system had failed before cars came off the assembly line instead of after.
Windows programmer
2010-05-11 00:48:05
@Michael, @NomeN: "It's also perfectly fine to ask and answer your own question, but pretend you're on Jeopardy: phrase it in the form of a question" http://stackoverflow.com/faq
Andrew Grimm
2010-05-11 03:34:58
I specifically said "It's ok for people to answer their own questions", but I think that FAQ entry is intended mostly for people who ask a question, search around for a while, find the answer, and then post it on their own question because nobody else knew. Based on how fast you answered, it looks like you posted the question *already knowing* the answer, which is a bit silly; you might as well have just blogged about it. I could sit here all day posting questions I already know the answers to, and immediately posting those answers
Michael Mrozek
2010-05-11 05:32:18
@Michael Andrew is adding value to SO and sharing his work here, I don't anything wrong nor silly with that. And yes, you could even use SO as a blog and it is even encouraged. See http://meta.stackoverflow.com/questions/17463/should-i-ask-a-question-i-know-the-answer-to and http://meta.stackoverflow.com/questions/2706/moving-a-personal-technical-blog-to-stackoverflow-serverfault
Pascal Thivent
2010-05-11 06:03:51
@Michael: If those questions and answers are worthwhile, they'll be voted up, and that's ok. If they aren't, they won't, you'll stop doing it, and that's ok.
Andrew Grimm
2010-05-11 07:17:55
It's fine, I didn't mean to start an argument, I just asked if he already knew the answer and it got turned into "how dare you post a question you already know the answer to". I think it's silly in most cases, and that meta post was hardly unanimous, but if the majority are fine with it then go crazy
Michael Mrozek
2010-05-11 14:25:57
Pascal Thivent
2010-05-11 16:58:55
@Pas I meant "go crazy" colloquially as in "feel free to do so as often as you like", not "I find it crazy that you're doing that"
Michael Mrozek
2010-05-11 17:33:25
+5
A:
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.
Bert F
2010-05-11 00:39:46
To explain via a counterexample, something which does not "fail fast" would be most web browsers and HTML. Consider this invalid HTML: `<div><b>Bold Text!</div>` It's missing the `</b>`, but web browsers choose to do the opposite of "fail early" by trying to recover from the problem and hoping it doesn't make things worse. In their case, it's a sensible route to take. But when you're writing code (rather than a visual presentation layer) going for correctness is probably a better strategy.
Darien
2010-05-11 01:06:46