Applying Fail Fast in Software Development

Our mantra for year 2015 is “Fail Fast”, and I have been thinking of applying this mantra in my day-to-day software development life. I have been studying the behavior of myself, my colleagues, and other well-known software engineers observed stunning and astounding results.

For any regular programmer, the motivation while writing code is to reduce defects and avoid system from crashing. Such a motivation results in implementing defensive coding. Every software engineer has to agree with debugging concept. Debugging is most difficult part of software development cycle (SDLC). It is also observed that the defects which are easy to produce are of the least concern to the developer. In fact, the criticality of the defect is directly proportional to the frequency of its occurrence, rather than the actual flow that the defect breaks. My observation teaches me the most of the time these “rarely producible defects” are due to defensive coding.

Here’s an example:

 // Finding User from list of users where username is matched with given username.
(Username is unique key for user in system)

// Defensive coding

User oUser = UserList.Where(UserObj => UserObj.Username == <givenUsername>).FirstOrDefault();

// Fail Fast Coding

User oUser = UserList.Where(UserObj => UserObj.Username == <givenUsername>).SingleOrDefault();

Above code snippet is good example for defensive coding.

“FirstOrDefault returns a first item of potentially multiple (or default if none exists).”

“SingleOrDefault assumes that there is a single item and returns it (or default if none exists). Multiple items are a violation of contract, an exception is thrown.”

Here there is no possibility of getting more than one user with provided username and if it consists multiple users with same names, then system will eventually fail (Not instantly). Developers are aware of results, as outcome would be single user or null. But, developer prefers to forgive the system rather than failed results from the system. Tough there is a high chance of injecting one of that rarely producing defects.

And also, you might be wondering to prepare our system fragile. I would say “NO”, because this mantra makes our system more robust and amenable. Spartan always says “the more you sweat in training, the less you bleed in combat”, and the same applies here – the more defects found in testing, the lesser are produced during production.

Here’s another example:

// getting max length of username is fetching from config file.

// another example of defensive coding,

int iMaxLengthForUsername = Convert.ToInt32(Configuration.ConfigurationManager.AppSettings[“MaxLengthForUsername”]);

// Fail Fast Coding

Try

{

int iMaxLengthForUsername = (int)Configuration.ConfigurationManager.AppSettings[“MaxLengthForUsername”];

}

Catch(Exception ex)

{

Throw new exception(“MaxLengthForUsername parameter is not configured properly”);

}

You can notice the difference of Fail Fast approach which is mentioned in the above code snippet, that developers won’t assume that the conversation would correctly execute. Nonetheless, the system works more fragile and hence to be sure of successful execution and conversation the latter approach is undertaken.

This approach hasn’t come up overnight. The learning in the aforementioned two examples has come after letting the system fail for the first time, so as to conclude on a better and more stable approach later. Hence, I would prefer to fail fast and fail visibly.

Benefits of Fail Fast approach is, you will fail instantly and find the exact problem in your system. There will be exceptions for some really nagging defects, but for some incidents such as the following the fail fast approach will be most helpful:

• Getting/Setting Configuration parameters
• Fetching data from database (most of time I see data access layer is always in try/catch so if connection goes down it always returns null, and I don’t know what actually happened – avoid this)
• Your business rules are clear (for e.g. one username will be mapped to single unique user, never multiple)

Henceforth, experiment the Fail Fast Approach and share your comments.