Learning through contrast

Praise for failure abounds. No, sorry, praise for learning from failure abounds? Failure is not only part of the tried-and-true approach trial and error, it's also deemed essential - i.e. not only inevitable but recommended - for learning. And if you're less scientifically inclinded you can hear it from an entrepreneur on the beach like Erica van Eaton:

Failure isn't failure. It's an incredible learning opportunity merely disguised as a mistake.

But what does that mean? Should we all not just embrace failure but actually provoke it? To me it sometimes sounds like that.

This would be bad advice, though, I think. Sure it's high time to improve the still pervasive failure culture which focuses more on who to blame than how to actually learn from failure. But that would not redefine the basic nature of failures: they are waste.

A failure (aka error, mistake) is an unintended deviation from a plan. Therefore failures are surprises by definition. Which means failures are interrupts. They always occur at the wrong time. And they are always a sign of a lesser quality then intended.

There is nothing, really, nothing good about failure.

Don't let yourself be fooled by (well-ment) folklore.

However, there is truth in what's being said about failure and learning. As long as the term "failure" is used, though, this wisdom cannot fully come to fruition. "Failure" is tainted.

To me, what's actually meant is: Contrast is an incredible learning opportunity. Contrast is essential to learning. We learn a lot by consciously creating contrasts.

This is especially important for software development. Bugs, failures are waste. Each and every time. We should avoid them pretty much at all cost.

But contrast, which means a tangible difference between two or more states should be created even more often. Because it's through contrast that a customer can determine what she wants.

Planning means laying out a path to a future state of the world. That's fine if you're very experienced in what you're trying to accomplish. You don't need to experience "a world in contrast" to know what you want and how to get it.

But whenever you're not sure about what you want and/or how to get there... you should not plan, but move forward by creating contrasts. The less you know, the more contrasting states you should explore. It's like with A/B testing.

In that light I would even replace "error" in "trial and error" with "contrast": trial and error is an approach to problem solving by very consciously generating contrasts. There are no errors in trial and error, there are only larger or smaller deviations from a target state. Even if the deviation of an outcome of a trial is not known in advance does not mean it's unintended. Not being intended, though, is characteristic of failure.

Or to say it even more clearly: experiments cannot fail. Any outcome is a valuable outcome from which you can learn. Maybe you don't learn what you thought, you'd learn. Well, bad luck ;-) Still you learn. And that's the mere purpose of experiments.

Experiments are contrast generators. So if you want to learn through contrasts, start experimenting.

No need to embrace failure

If you stay open minded, experiments cannot fail. Although you might favor one possible outcome over another, you'll make progress in any case. And the beauty of it: no outcome is a waste of time, no result will catch you on the wrong foot.

Here's a contrast I just experienced:

I'm on a small vacation in Austria. To the left a picture of the town Au/Vorarlberg on past Saturday, to the right a picture of today. A stark contrast, isn't it? ;-)

If I hadn't known already, I would now learn something about my weather preferences for a vacation :-)

This of course is trivial. But it holds for each and every contrast. Show a user two versions of a user interface, and she'll know right away which one she likes more. Learning happened! Or even: show a user one version of a user interface when there hasn't been any before.

Of course this does not only work for user interfaces. Any requirement can be transformed into a tangible form for the user to give feedback. Even small behind the scenes aspects of single interactions. Use special test beds if you need.

The more you move to an experimental work style (or even life style) the fewer the failures. And the higher the frequency with which you generate contrasts, the quicker the learning.

This is not really new to the software development community. RAD tools are rapid contrast creation tools. Agility's short iterations are about frequent contrast presentations.

But still... so much talk revolves around failure. I find that detrimental to the progress of our profession. We should be more conscious about the true enabler for learning: contrast.

And the more intentionally we create contrasts, the more efficienct and more effective will learning become. Also, I guess, the more we focus on "contrast" as a term, the less we'll play the blame game. "Contrast" is neutral, untainted, open for many interpretations.

Go for contrast!