Fail safe, not fast

Iterating toward a fail-safe environment

“Fail fast.” “Fail often.” “Fail better.” You’ve probably read or heard a dozen variations of this phrase. In our world of constant innovation, data-driven approaches and endless A/B tests, change is the only constant.

For businesses, failing fast usually means a process of trial and error. Making a product better by analysing every step in its development, measuring and interpreting data, collecting user feedback, killing poor features, improving good ones.

Failing fast for software engineers means something completely different. We cannot push a product into the market and then wait to find out how badly it crashes. Maybe in 2008 that was acceptable (anybody remember Twitter’s Fail Whale?), but not in 2018.

Today, engineers build environments and processes that are designed to learn from failure. Such designs help us to ship and iterate faster. But, and here’s the catch, they must not crash.

When was the last time that Spotify, Evernote, Twitter or Facebook crashed on your device? Yes, they are often slow, the UX can be infuriating, animations can glitch. But I bet nothing drives you crazy like a full-on crash.

Now, you probably aren’t going to leave Facebook if it crashes, you’re too embedded into the ecosystem. But you might leave Spotify. And you’d definitely consider leaving a mapping or e-commerce app. There are plenty of alternatives and it’s easy to switch.

Businesses can fail fast and fail often because every failure leads to improvements and better decisions. But not you, software engineer. Your mantra should be different. Your mantra should be: ship fast, iterate often and don’t crash.

But how do you make this mantra a reality? There are four key elements: process, testing, engineering and people.

Process

It’s not about how fast you can code, but how fast you can reach the market with a product that customers will benefit from, and how quickly you can start learning from data and feedback. A strong process is how you get there.

In 2000, customers had to wait a year or more for a new version of Windows or Photoshop on their desktop computer. Within ten years your Facebook smartphone app was updating over wireless internet about once per month. Today your apps update overnight via 4G, often bringing usability updates that make your experience faster and easier.

Less means more. Work on the highest value pieces of your product and ship every week. With fewer changes, fewer things can go wrong. Fewer things need to be tested. There are no prizes for 1GB app updates with a bunch of broken features that people don’t need.

Testing

Quality Assurance is about ensuring that your product doesn’t degrade with each new release. QA makes sure that missing features are missing by design and that new ones don’t break old user experiences. QA also ensure that business data isn’t biased by random crashes.

So, how do we test properly? By using automation, multi-stage processes and by ensuring that testing is the responsibility of all team members.

This is how we do it at Azimo.

Engineering

Engineering is about standards , code quality and your understanding of patterns (design, architectural) and their profits and drawbacks. It’s your self-awareness about why you do the code.

It’s also about writing code that matters. Business logic that is specific to your product and brings value to users. The rest of code can be probably generated for you by tools like Dagger, Butter Knife or our newest open source: Api Error Handler. They not only improve your code, they generate the code you don’t want to write.

People

We build our product for people. To bring value to the society. To make change. To democratise financial services. That’s why the most important KPI in our tech team is to keep the number of crash-free users above 99.5%, all the time.

But our our product is also built by people.:

If your team simply writes good code, you might make a decent product. If your team deeply understands the problems of your users, you will make a great product.

Tomisław, Azimo’s CTO in A manifesto for engineering culture

Tomislaw’s article explains how we built our engineering culture, and why it matters.

Conclusion

The process, testing, engineering and people are the key ingredients that support our mantra: ship fast, iterate often and don’t crash.

In the future there will be no coders, only engineers. Software will be writing the code under the supervision of software engineers. Software engineers see the full picture and deeply understand the problems of their users — are you one of them?