Photo by Sebastian Ahmed

How to “fail fast and fail often”


In this article I describe how this seemingly provocative concept is actually a template for up-leveling development to attain high-velocity and efficient use of people-time.

Not really Failure

If Thomas Edison “failed” 10,000 times so he can “succeed” once in taming incandescence, it would suggest that even a great inventor with copious amounts of grit is “failing” most of the time. The reality is that none of these were true failures. These were just steps in the process of his relatively expedient two-year journey.

True failure is a determination of a result which did not meet a desire within a required timeframe.

The determination of failure is made by a beholder, which could be you, your manager, a customer, the market, or even society. Had Edison taken another year to invent a production-quality bulb and no other competitor had beat him to it, Edison would have still succeeded. Success is thus time-bound.

Failing Fast … and efficiently

a reliable measurable outcome should require a fraction of the total time and effort required to manifest the product.

The “product” here constitutes your deliverable, not necessarily the final end-product.

  • Abstract models and prototyping environments which provide useful insights, quickly. Usually developed and simulated by a small team. This is the second line of defense. Many failures can and should also occur in this loop. A good example of this is the use of virtual platforms and high-level models for embedded systems.
  • Front-loaded “canaries in the coal mine” during development which can predict undesired outcomes early in the process. This is the last line of defense which may require resetting the development loop back into the prototyping loop. These “canaries” usually require a “shift-left” methodology where initial designs can be vetted earlier in the development phase. An example “canary” could involve test-driven development.

nothing here requires rushing, reducing quality, cutting corners, removing features, thrashing around, or working your team to burnout.

It is about working “smart”, by up leveling the capture and simulation of design-intent while dealing with well understood randomness up-front. This is no simple feat and requires building a team that can attain this level of capability. It is thus an investment.

Failing Often … but with direction

  • The path of failures towards the successful outcome must be self-guiding with an overarching directive which can manifest itself in the early iterations.

these models must provide not only whether the outcome is a pass or fail, but more so they must indicate a direction to take for the next iteration.

Without such a compass, you will run out of tries, because you can only fail so often for any given project before reaching “true failure”. What such a compass constitutes depends on the problem at hand, but telemetry and intelligent processing thereof, is a generally great pattern to gain inspiration from.

Succeeding fast and succeeding often

Failing fast and failing often requires capabilities, and purpose in people and the development process with a bias towards early prototyping which is fast, provides a sufficiently reliable measurable outcome, and requires exposing the churn to fewer people. Fewer people and shorter periods of time means efficiency.

Technology Leader | Systems Architect | Programmer | Photographer

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store