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.
Top comments (1)
This is a very interesting frame of thought. I would like to add:
Just like "Writing code to pass the test", we could say that the step before is "Writing test to fail the code", since TDD (under some interpretation) prescribes that we specify future behavior via tests.
"Failing forward" describes what I have experienced lately in my spare-time project doing pair programming. We celebrate when we have made the program fail in a new way. Overcoming one problem often does not mean a final goal has been reached. The intermediate steps can often be characterised by having fixed a part, to reveal the next broken part.
Not all errors are happy errors, of course. But there is a special feeling of "We have made it not fail for the obvious reason we have been aware of, and now it fails for reasons we do not yet know." Going from known problems to unknown problems means progress. This is particularly easier to acknowledge when you are not sitting alone with a problem. ;-)