I seem to be starting a series of posts on good advice gone bad. KISS is a great piece of advice, Fail Early is another. Like KISS, it’s advice that scales: it’s as appropriate to function design (don’t return spurious default values on failure) as it is to project management (find out that something’s gone wrong now, not in three months time). The basic idea is the same: provide instant feedback that something is wrong. Don’t let the problem grow.
On the other hand, there’s nothing in “Fail Early” that says that you need to completely fail. I once was advising on a store-front application. It took the prices and products from various third-party suppliers. However, if there was anything wrong with the data, the whole feed would fail.
Now, it certainly “Failed Early”. But it didn’t observe the spirit of the phrase. For one thing, it didn’t actually tell anyone. It waited for someone to notice that the prices were wrong on the live site. It’s definitely feedback, but really the sort you want. The worst of it, though, was the “all or nothing” approach to failure. Now, sometimes you’ll make a decision to do it this way, but typically this will be because data is inconsistent if you don’t. A price list is not one of those cases. 99% of prices could typically be processed completely successfully.
So, Fail Early. But don’t Fail Catastrophically.
Colour Coding 