How To Fail Fast And Deliver Faster
The term fail fast gets thrown around a lot. It’s good council. The problem is that most people don’t know how to fail fast effectively, or even why they should fail fast. The origin of the term is debated but applies to a lot of situations from business to manufacturing and in our case software development.
Lean Manufacturing
Let’s examine an example of failing fast. A well-recognized example of this is given to us from Toyota and their pioneering of lean manufacturing. There are a lot of things that go into lean manufacturing but I want to focus on one particular aspect, how they use failing fast to improve quality and the speed of delivery.
At a Toyota assembly line, if there is any problem encountered or flaw found, the entire assembly line is stopped and the problem is addressed by everyone. The line doesn’t start up again until the issue is resolved. Anyone working on the line has the power to stop the assembly, it’s instant, and it’s expected.
This might sound crazy at first glance. How can stopping the entire assembly line really improve speed? Again there are several factors. One factor is that a flaw if ignored can affect a lot of cars which may then need to be recalled or sometimes just reassembled. By failing fast and giving everyone the power to fail Toyota created a more efficient (both for time and materials) process.
Toyota’s pioneering of the lean process has spread to other car companies and is recognized now as a standard in the manufacturing of all kinds.
LEAN Software Development
But how does this apply to software development? It really applies to nearly every stage of the sdlc (software development lifecycle). Imagine the sdlc as the assembly line for our new software features. That means that at every stage of the life cycle there should be an opportunity to stop the assembly line. Take note that, unlike a physical assembly line software development doesn’t have the physical constraints manufacturing does. So when something needs to stop that doesn’t mean everyone in the organization stops to address an issue. Just those needed for that stage of development are involved. It’s more like each stage of the sdlc is its own assembly line.
What does this look like at the various stages of the life cycle?
Analysis
The analysis stage of the life cycle is the first stage. I find it one of the simpler stages and one that most people or companies will fail fast with. It is where we decide if a feature is worth building. At this stage, it’s decided if a feature should be built. This often includes looking around to see if it’s a feature wanted by users. If it isn’t, the feature is discarded.
This is failing very fast, nearly at the inception of an idea. Failing here could mean that only a single person was involved. As you can imagine if there wasn’t a way to fail at this stage a lot more resources would be spent on the feature and it would slow the delivery of more important features that users actually want.
Design
At this stage, the idea has been vetted. Next, the feature needs to be designed. Sometimes in design, a concept is found to be flawed. Rather than pushing forward with the design, it’s good to fail fast and get people rallied around finding a solution. Sometimes this is just talking through an issue, sometimes it means sending things back through the analysis stage. Either way, it is better than pushing through flawed designs and consuming the time of those downstream on something that is known to be flawed.
Failing fast here will delay those downstream from starting on the feature. But it will free up their time to work on things that have been vetted and are more likely to result in a complete and usable feature resulting in more code/features being delivered.
Development — Automated Testing
Finally, we have development. Failing fast is equally important here but also a much larger topic. This is because developers (especially in larger companies) have their own life cycles for getting code deployed and usable in production. In a lot of ways failing fast for developers is easy. It can start with running unit tests locally. If they fail you fix them. No one else is affected. This is the first line of defense. Ideally, you also have safeguards to pass a code review like linting.
Once you pass those checks you check the code in. Ideally, the ci/cd pipeline will run unit tests, lint checks, and possibly E2E tests. Failing on the build server consumes build resources but still mostly affects just the dev. Iterating over tests and other checks is a great example of failing fast working right.
To this point failing fast has served the purpose of insulating others from problems. This ensures that something that is early enough in the process doesn’t affect others while it doesn’t affect them.
Development — Code Review and Manual Testing
The code review or manual testing is often the first place other eyes are on the code. It is another example of failing fast. There are trusted people in a place to identify quality issues and fail fast.
Development — Process and Tooling
Most organizations, even if they don’t have those processes and standards in place, will recognize the values of automated testing, code reviews, and manual testing. The trick is those same organizations will forget the reason those standards are important. They are important because they force failing fast.
If we view processes and standards as means to fail fast we will see even greater velocity and stability in our code/features. Let’s look at a couple of processes that are often misunderstood and ignored.
Development — Branching Strategies
I have seen a lot of branching strategies. Most that I run into are a variation on the git flow strategy. Organizations often like it because it is familiar, easily understood, and more closely matches old release strategies. The problem with git flow and its variations is that it promotes a later than ideal failure point. A lot of the time it comes down to merging specific code for a release and that is the first time the code is seen in a combined state.
On the other hand, by using Trunk Based Development (TBD) code is merged into the trunk (often the master or main branch) by every dev every day. Doing this gives a very early failure if something is wrong. By using TBD you move the failure from a release into an earlier state that is more easily fixed or reverted.
Development — Monorepo
Monorepos are gaining a lot of popularity right now. One reason is that a monorepo promotes failing fast. Let’s look at an example. When the Angular team (at Google) is ready for a new release of the Angular framework they trigger a build in Google’s monorepo. That will kick off automated tests and builds for the 700+ Angular apps in the repo. When there are failures the team looks back at the new version of Angular and make adjustments. Then kick off another build, and iterate. If this wasn’t a monorepo Google would need to publish a new version of angular, then go update all 700+ Angular project repos then if there was a problem repeat the process.
By using a monorepo Google causes a much faster failure and in turn a much faster and more stable delivery of Angular.
Conclusion
Just as in manufacturing keeping a lean mindset and failing fast in software development will increase velocity and improve quality. All it takes is a little discipline and remembering that to fail fast is to deliver faster.
Now that you’ve read this article and learned a thing or two (or ten!), let’s kick things up another notch!
Take your skills to a whole new level by joining us in person for the world’s first MAJOR Angular conference in over 2 years! Not only will You be hearing from some of the industry’s foremost experts in Angular (including the Angular team themselves!), but you’ll also get access to:
- Expert panels and Q&A sessions with the speakers
- A friendly Hallway Track where you can network with 1,500 of your fellow Angular developers, sponsors, and speakers alike.
- Hands-on workshops
- Games, prizes, live entertainment, and be able to engage with them and a party you’ll never forget
We’ll see you there this August 29th-Sept 2nd, 2022. Online-only tickets are available as well.
