An Iterative Lifestyle

An Iterative Lifestyle

Iterative Failure

I started this article by writing about "iterative failure," a process of failing forward, fast and often. What I realized is that most development is about the ITERATIVE process and much less about the failure.

About Failure

"Failure is not an option" is attributed to Gene Kranz, flight director of Gemini, Apollo, and Space Shuttle missions. Gene Kranz confirmed in an interview, that this sentence was made up for the film Apollo 13. But he liked it so much that he used it as the title for his memoirs and autobiography.

Became ...

Fail early, fail often, but always fail forward.” ― John Maxwell, Failing Forward

FAILURE: It is a harsh word. No one enjoys failure. Yet failure is an inevitable part of human existence. Without failure there is little forward progress; Without failure, innovation is rather incremental; Without failure, there is no reason to celebrate success.

Failure in development is reframed as intentional iteration and experimentation. It is not a failure in the catastrophic sense. Failure is simply a series of setbacks, false starts, wrong turns, and mistakes that are expected and tolerated because the developer purposefully iterates over code variations finding new and better ways to frame the concepts. Through iteration, developers seek to make the code better, and this happens through an anticipated cycle of pivoting and adapting.

  • Conduct early and frequent experiments with code to test parts of the idea.
  • Reflect on what was learned from the iteration and determine how to integrate the learning into the next iteration.
  • Let others in the developer network know about the iteration because they will be a good source of information and feedback.

Intentional Iteration

Development is NOT about failure or failing repeatedly. We need to have a shift from a success/failure mentality to an iterative design mentality. What we as developers (using Test Driven Development) are doing is ...

  • Developing a means of testing the code (for some aspect no already in the design)
  • Writing code to pass the test
  • Verifying the test covers the code correctly

Then, we begin another ITERATION if the results are not what was expected.

I’ve talked about this as dealing with failure, but just recently realized that many of us are simply viewing an iterative process as a repeated failure; not focusing on the goal of solving a problem.

In science and art, the iterative process is a cornerstone of learning, creating, and moving forward.

On the smallest scale, do we fail when a function does not work as expected? NO; we’ve written code that needs adjustment.

On a larger scale, do we fail when some part of the system does not work right? Users do not come back saying the system has failed. It simply does not work as expected.

In both cases, some code gets reworked ... not left in a broken state. There is no failure, only another layer of iteration.