Embracing Failure Leads to Expedited Innovation and More Robust Solutions

March 12, 2018 by Vinko Buble

“The greatest teacher, failure is.” - Master Yoda

Problem Illustration by Taylor Grant

If you spend enough time with founders or high-tech workers you might overhear something like "fail fast, fail often". Sayings like these conjure up images of self-righteous entrepreneurs (love 'em or hate 'em) and the pursuit of success at any cost. They also leave many of us keenly aware that when it comes to our own workplaces, we certainly are not going to be rewarded for making mistakes—quite the contrary! So why should we embrace failure? Let's face it: no one actually wants to fail, and most of us can't afford it. Moreover, the bravado of expressions like "move fast and break things" is sometimes used to celebrate reckless gambles that don’t benefit anyone. The real lesson of embracing failure is just the opposite, however. “Failing faster” actually means failing safer, and using failures in an experimental framework to produce more resilient final products.

Embracing experimentation first and foremost requires facing our fears of being wrong. Ironically it’s our fear of failure that leads us to take more risks. When we’re scared of being wrong, we might avoid testing assumptions and refuse to acknowledge problems until they get too big to ignore. When we’re more comfortable with being wrong, we become better at working out problems before they get too big. We also gain insights from an experimental framework that we could have never imagined and inspire us to radically change our approach. Innovation-minded developers are good at designing low-cost experiments to quickly prove their assumptions wrong. The results of these carefully designed experiments help them avoid the much costlier failure of building a robust solution to the wrong problem.

Problem Illustration by Taylor Grant

The most common misperception about “failing fast” is that it’s about rushing to prove yourself right when in fact proper experiments are designed to disprove a hypothesis. Like scientists take care to isolate the variables in their experiments, innovation-minded developers learn to examine and test their designs feature by feature. This not only pinpoints errors, it helps a development team break up tasks into smaller and smaller parts until executing is easy and failing is safe. When failures are organized in a methodological framework like this, they stop being causes for shame and become a crucial source of information. Even after many failed experiments, we can be as confident as Thomas Edison when he famously exclaimed, “I have gotten lots of results! I know several thousand things that won't work!”. In the end, each of these failed experiments lends strength to a solution and allows a development team to feel more confident as they ramp up to a fully-fledged product.

Can founders without major VC support afford all this experimentation? Methodical experimentation might seem like a slow and expensive way to get things done, but ask yourself which costs more: a series of small, failed experiments that lead you to a better idea; or a robust solution that fails when it hits the market because it doesn’t solve the right problem for your customers? We look at innovative products and see elegantly designed solutions, but we don’t usually see the tests that were the scaffolding for those ideas. By “failing safer” through experimentation, Innovation-Minded Software Developers help product teams avoid big failures and build more resilient solutions.

High-Tech Startups Cut Costs with this Innovative Approach to Software Development

January 22, 2018 by Vinko Buble

Long distance runners know that energy conservation is the key to a strong finish, and today’s software developers can parallel this mentality with an approach to innovation that values simplicity and precision while saving development resources.

Cleaning Up Feature Creep: How Smart Software Developers Improve User Experience

April 3, 2018 by Vinko Buble

While you might not consider yourself a “hoarder”, it’s likely that you’re holding onto software features that your users no longer benefit from. All developers can form a sense of attachment to features, especially when they required lots of time to build, or once served an important purpose.

Subscribe to newsletter

First name
Last name