There are a number of ways to measure how well your processes are, one such way is to celebrate every time your product fails before it’s release. What is ‘Fast Failing’ and why you should do it? We will explore that in this post.
What is Fast Failing?
Let’s define what Fast Failing is? Failing fast is a method of finding flaws in a product as quickly as possible. It is to build a process that reacts to issues quickly. If any issues are found, people should be notified automatically. When issues are resolved there should be a high degree of confidence that the same issue will not occur anymore.
Given that we now have an understanding of Fast Fail, why would you want to fail fast?
Certainly it is better to see your product flourish, perform and have a steady pace of progress. Having been involved in many projects, there is no such thing as a perfect project. Every project has failures and plot holes during the course of it’s journey. What are failures? What can go wrong?
Failures can come in the form of broken features, missed requirements, performance issues etc. As a developer, tester, project manager, you will want your project to go through without any issues. If your product has issues, how can fast failing help?
If we implement a process which helps in fast failing, what does it actually help with? I can boil it down to a single statement – you will find your issues before your customers do.
Failing Fast is Important
Before we talk about the ‘how’, let’s talk about the ‘what’. WHAT does fast failing help with? Why is it important to fast fail?
From a development point of view capturing issues early results in one thing, cheaper resolutions. Let’s explore a scenario:
“You have developed an application and are about to release. Just before the release stage you demonstrate your application to your key stake holders. Sadly, at the worst possible time you discover a bug just before the demo. The bug is trivial and small however as it was found during the late stage of the entire process. You do not have much resource to resolve the issue. On top of that if you do resolve the issue, you will certainly need to retest your entire application. Assuming you get that done, you will have to go through an entire process of getting your application approved. At best, your deadlines will be moved and your key stake holders will be a little upset. At worst you may fail to delivery your product.”
Let’s assume you found the same issue but much earlier during the development process. If done correctly, you may have found the issue before writing a single line of code. What do you think your cost would be finding an issue early in your process vs finding it later.
How To Fail Fast
The concept of failing fast is simple, put in place processes that helps to capture issues early and quickly. How does one do this?
Talk about your Stories
The earliest place to capture issues is before you write a single line of code. How do you do this? One of the most effective methods is to get all the relevant people into a room and discuss what features, stories and tasks need to be implemented.
To do this, you should ideally have a Product Manager, A Technical Developer and Test Engineer. Each profession would supply their own technical views on the tasks to demonstrate what is needed and how to achieve it. This will help bring to light possible issues.
To date, most issues that I have seen caught early was through this method.
Write Tests
How do we know that the features that we have already implemented will not break? The answer to this is to write as automated tests. In simple terms, an automated test is simple some code that tells you how your application behaves. More importantly, it will tell you if it behaves the way you expect it to. Assuming if you were to write hundreds of tests which capture the features of your application.
If every test passes, this would at least guarantee that the automated features are working. The value you getting from writing tests comes in the form of failures. If a test fails, then you instantly know that one of your features has broken.
Always Run your Tests
It is strongly encouraged that you run all your tests against every new feature that you implement. This will give you a great deal of confidence that your new feature is working.
Running your tests every might actually not be enough. You should also consider running your same tests in multiple environments each with their own environment settings. This helps to see how your product behaves in different situations. You have to note that your product may run perfectly on your machine but may not do so on your customers machine. Catching this early in your automation process will help you to resolve the issues before your customers call you.
Demo Early
This can easily be one of the most underrated methods that you can use. You should ensure that you actually demo your application to your clients iterively. Do not demonstrate your product at the very end of it’s development. There is a high change they may not like it and may ask for some changes. This would be a disaster if this happens at the end of your project.
Demoing your product early to your customers results in early feedback. Early feedback for a product is much easier to manage and resolve.
So, what do you think about Fast Failing? Is there anything in this post that you feel I might have missed? Would you do things differently? Let me know in the comments section below.
