Fail Fast Not Slow
To Fail Or Not To Fail
Bugs bring costs and risks for the project. Unfortunately, they are an inevitable during software development.
There are two simple techniques that may speed up or down dealing with these defects: fail fast and fail slow.
Faster bugs are discovered, faster are fixed.
Fail Slow is a software development technique that allows the software to continue working right after an error, but fails in another unexpected and strange path later on.
Fail Fast - says to fail immediately and visibly when an unexpected error occurs. The outcome of this approach is in easier capability to discover bugs and fix them, that inevitably leads to better code and stability in production.
Why Fail Fast?
- help discover defects
- problems are easy to find
- reduced costs of bug fixing
- state is more protected, due to better stability
- better confidence in software, most likely it does the job correctly
Example
Probably, most descriptive and clear example where it excels is the work with configuration file that has some typo in it.
fail fast gathers configuration values and performs validation on the application startup. In case something is missing or does not pass validation, an exception will be issued and that error will be immediately and visibly.
fail slow performs silently the process of gathering configuration, and the failure will occur only when the setting is actually used in the code.
In described scenario fail fast brings obvious benefits. Immediately will be signaled misconfiguration issue, and no need to wait for some code block execution that will reveal it at unexpected moment in future.
How To Fail Fast?
- determine the kinds of defects your software may face
- include in failure help information on how to fix the problem
- emplace failure close to the problem that may occur (makes it easy to find)
Where To Fail Fast?
Needless to say, fail fast is not bulletproof plan for tackling defects. Good point is to identify what failures are the hardest to find in software, that are even difficult to reproduce. For such scenarios a well-placed failure may save hours or even days of effort.
On the other side, it does not make sense to fail fast through assertions after every variable assignment statement, otherwise the code will blow up with impractical assertions.
Fail Fast In Real Code
However, in production mostly a failure sounds not quite nice. The great news is that for it we can use the best from both approaches. Global exception handler fulfills gracefully this requirement. At frontend side this may be presented nicely through some kind of alert with user-friendly information, while in background the failure will be recorded and notification with high priority sent to tech support.
Global exception handling will cover the quick fix notification and overall system stability for end user experience.
Fail Fast Keynotes
fail fastbrings the possibility to be notified earlier of unexpected situations that should not escape developer’s attention.fail fastavoids pretending that everything is fine, and the problem is somewhere in another place.
22 March 2018