Like everyone else working in IT, I don’t have to worry about losing touch with failure. Often, it seems we’re so well acquainted, I don’t pay enough attention. In prior years, I followed the three bounce rule: don’t worry about what you’re coding until the compiles have failed more that three times in a row.
Last Saturday, at the Fall PDX CodeRetreat, Matt Plavcan gave those of us attending the chance to experience failure at a new and different pace. After introducing himself, Matt began the day by letting us know that he was leading us through a series of challenges where we would fail. The primary goal as to implement Conway’s Game of Life. For each session, we would pair up in coding teams. After 45 minutes, when we had failed to finish the challenge, we would stop and delete the code we’d written.
Conway’s game of life is driven by only four simple rules that determine if a cell on a grid is turned on or off, dead or alive. In addition, Matt told us that the four rules constituted everything needed to create programs. He told us that later he’d show us the game of Life coded in the game of Life. Wasn’t sure what that meant, but it would have been a discouraging condition if he’d thrown that in as a coding requirement.
The CodeRetreat gave me a chance to sample a couple environments I’d never worked with: Ruby and Python. I enjoyed the learn as you go way of working with their test suites and maybe catching a bit of how the whole test driven design process worked.
I also got a chance to brush up my Java skills. Nine years ago, I was able to suss out what was going on in the complex, layered code in some test questions. At least, able to work out enough to pass the Java certification exam. But I haven’t worked anywhere that I’ve used it.
Working with a language IDE that you haven’t used in a long time is the same as getting back on a bicycle, provided that you used to crash a lot when you rode. I remembered that Eclipse provided code completion, but not how to trigger it. With just forty-five minutes at hand, it was a case of strap on the helmet and keep moving. Sort of a refresher course with bruises.
One technique saw that I haven’t used much, is what I’d call coding by Google example. I’ve done that some, but I usually search my local work source libraries instead. Part of that comes from being very embedded in the context I’m working in. Still, the Google Search provides the opportunity to find something different, maybe better.
Writing a bunch of throw-away code wasn’t the only thing we did. Between coding sessions, we gathered in a big circle to share our experiences. For many, there were technical issues: dealing with a language or frame work brought comments from some, other issues around pair programming brought comments from others, and there were comments on the nature of designing a program to implement the game.
Despite all the failure going on, the review sessions produced no notes of blame or self-recrimination. Everyone failed, so no one could feel like a failure. This might have been different if the half the teams, or even a single team had succeeded in completing the challenge. By guaranteeing failure, Matt assured that failing was simply part of the learning process, not a sorting mechanism.
As promised, we got to view the Game of Life programmed in the Game of Life.
Life Coded in Life
When it first started, I saw elements that I was familiar with: cyclic phases, gliders, flippers, and emitters. I saw an interesting collection of structural elements, cycles and reactions but it didn’t look like something that was implementing a higher logic. But further along, it’s all in the view.
And people had very different views on what the day had taught them. Matt asked us to each sum up what they would take away from the experience. For some, it was about the what the tools could do; for others, it was about learning test driven design; for me, it was about the value of failure. Rapid failing was a new learning tool. People agreed with my remark that failure after forty-five minutes was a lot more fun that failing after forty-five weeks.
In the end, one thing I did not fail to do was to thank Matt for putting together a great experience. I intend to make the most of what I learned. Working with code that’s almost thirty years old doesn’t provide an optimum situation for employing Agile/XP practices, but I’ve done what I can to adapt some of the techniques: incremental coding, refactoring that initially maintains the code behavior, and shorter feedback loops.
One area that still stalls me sometimes is when I’m not sure how to put together a good test for the new or changed feature that the business requires. A new approach could help: instead of looking for one good test, put together whatever tests I can, no matter how tiny. or how little I think it will tell me. Progress through small fails and successes.
The subtitle of Kent Beck’s seminal work eXtreme Programming Explained is Embrace Change. Maybe the Agile/XP world could expand that to: Embrace Change, Befriend Failure.