Fail Fast to Restart Quicker

The term fail fast in software has its origins in fault tolerance. The idea is that something has gone awry and the safest way to handle the condition is to shut down the whole system to prevent further damage. It is an acceptable trade off since the damage which could be done is worse than the loss of the service the program is providing. The idea is also commonly found in entrepreneur circles where the damage caused is the waste of capital. I am sure there are a number of other areas where fail fast can be applied beneficially, but since I'm a software developer I'd like to show some benefits of fail fast in software development.

One of the applications I have been working on recently has a little annoying UI bug. The top element of a spinner component is not highlighted properly to indicate it is the prompt rather than a selectable option. I decided I would spend a few minutes trying to tackle the bug. I started by verifying that I had an up to date source tree without any uncommitted changes. The cause of the UI bug was determined to be how the adapter was being built giving all of the options an offset of “+1.” Figuring that was silly I just removed the first element, removed all of the “-1,” and set the first item as the prompt. The component was visually correct after this and I was about to commit the changes. However, one last run through application showed another bug. I came to the realization that the UI bug I was fixing was a work around to another bug exhibited at another level. At that point I decided I simply did not have time to run down that rabbit hole for such a trivial bug. A revert command to the source control and I was back onto another task.

On the same project I was adding two features to the application. Feature one went in really smoothly, so much so I had forgotten to commit my changes prior to moving on to the next story. The second story was a little bit hairy. I had a bad false start and was about to revert the changes when I found my problem of not committing the prior story's changes. Instead of being able to revert I had to work through my bad false start to complete the feature. I had to carefully evaluate all the code to make sure I wasn't leaving bad bits in and make sure that the feature was successfully implemented. By not being able to fail fast I probably doubled the time required to implement the second feature.

The ability to fail fast allows a developer to quickly try out ideas for viability before committing to them. Some solutions appear to be a good idea at the start, but over the course of implementation failings can be revealed. Following the course laid out by a bad start can cause design flaws or overly complex code to handle originally unforeseen issues. The complex code can be refactored, but it is often easier and cleaner to start from scratch with a better understanding than to modify the existing bad start. Failing fast is another tool in a developer's skill set which will allow cleaner and better code.

Resources

• http://c2.com/cgi/wiki?FailFast