Agile Careers


Jim ("Cope") Coplien is an old C++ shark who now integrates the technological and human sides of the software business as an author, coach, trainer, and executive consultant. He is one of the founders of the software pattern discipline, and his organizational patterns work is one of the foundations of both Scrum and XP. He currently works for Gertrud & Cope, is based in Denmark, and is a partner in the Scrum Foundation. He has authored or co-authored many books, including the recently released Wiley title, Lean Architecture for Agile Software Development. When he grows up, he wants to be an anthropologist. 

Log in to register a comment.

Subscribe here.

Blogs Blogs
« Back

There is No Failure — Only Feedback

We’ve all made mistakes. Some even admit it. The best of us learn from our mistakes. But the very best of us have a talent to ignore our long-cultivated reflexes that lead us to hide the consequences of our errors. A great career carefully courts failure.

Solving problems is fundamental to engineering. We often separate the problems we are asked to solve from the ones we cause, and classify the former as opportunities and the latter as failures. But we can’t, in general, always avoid failure. The nature of complex problems means we navigate failures as we close in on the solution. As Jerry Weinberg tells us: There is no failure, only feedback. 

History relates many stories of engineering advances at the hand of failure. Johnson (Where Good Ideas Come From,  Penguin, 2010) tells how DeForest’s invention of the vacuum tube came from a misunderstanding of what made it work. Fleming’s discovery of penicillin was similar, as were Daguerre’s invention of the daguerreotype and Greatbatch’s invention of the pacemaker.

Systems thinking literature and philosophy has a cornucopia of advice about failure. Deming’s Plan-Do-Check-Act cycle structures the feedback loop that compensates for missing the mark. We often hear that the fundamental form or architecture of the things in our workplace follows function, but Henry Petroski tells us that form follows failure (“Form Follows Failure,” Technology Magazine 8(2), Fall 1992).

Failure can be your friend. As long as he’s going to be in your neighborhood anyhow, you might as well get acquainted. You’ve heard that you can learn from failure. That realization has become the watchword of those looking for rationalizations when things go bad — when failure causes such pain that we contemplate fairness in creation and the cause of evil in the world.

Instead of rationalizing the big failures by just making lemons into lemonade, go a step further and capitalize on the more common and numerous glitches that are part of day-to-day business. We too often let these go by unheeded. If you pick out a few that you find worthy of attention, you will raise your own awareness of how to do better next time. 

The very nature of kaizen in Japanese culture is rooted in an introspective state of hansei: of deep reflection and of identifying with the problem. Only then are we truly in a position to understand how we can relate to solving the problem, either by removing its cause, or working with others to do so, or to embark on a program of continuous practice to remove the problem. Also intrinsic to kaizen is that improvement comes not so much from solving the problem, but from going to the next level to remove its very cause. There is lasting value in fixing a software bug. There is broad, lasting value from improving the process to diminish the chances that such kinds of bugs can ever arise again. But we need those bugs, those problems, to trigger the process changes. In that sense we celebrate the opportunity that presents itself when a problem arises, though we soberly assess our place in that system.

Speaking of intentional practice, periodic reflection is a good thing. Explicitly take time to reflect on opportunities to improve — as an individual, a family, a team, or as a corporation. It takes trust and courage, but it builds trust and courage as well. William James said “The error is needed to set off the truth, much as a dark background is required for exhibiting the brightness of a picture.”

Trackback URL:

I've seen failure, years wasted, milllions of dollars spent with nothing accomplished. Yes we can still learn something from it, but enough sunshine up the skirt already.

Posted on 12/7/11 11:25 AM.

I guess you've had a hard day, Joshua. Or maybe you're so focused on your job that you've lost sight of the learnings at the career level.

Can you name me one thing you've learned in your many years, and how you've applied that, and exactly how it helped the value proposition?

Posted on 12/7/11 11:29 AM in reply to Joshua Stern.

This sounds like some nonsense soft-skills-workshop, where everyone finds out stuff that they knew before already and the instructor keeps using quotes and references all kinds of historical stories because he has nothing to say of his own.
What is 'kaizen' and why should I know that to understand that text? We better fix the source of the problem and not only the symptoms! Honestly? ;-)

Posted on 12/7/11 3:49 PM.

I appreciate all the historical and philosophical references and the broader context. I wasn't familiar with kaizen before reading this column, but I am now.

Posted on 12/9/11 5:04 PM in reply to Christian Freund.

Are you really going to say you've never been part of a large, failed project, or heard of one? I've not had a particularly hard day (when I posted that, or today), but certainly at best a mixed set of experiences over the past ten years.

What have I learned and how does it help the value proposition? The top of that long list has to be that a lot of old textbook propositions about work efficiency and group practices and human factors on jobs really, truly are serious and pay off bigtime if you simply make a reasonable effort to follow them. And that trying to gladhand your way past because you read a trendy new article or "don't have time", loses 99% of the time. Any serious scientist would expect that kind of ratio, too. It doesn't say not to try stuff, but it says to be honest and objective about things, at the risk of being absurd and counterproductive.

The value proposition in this is that even when I preach it and nobody listens, I can follow it myself and deliver as planned (and having even done the planning was an earlier expression of the same). This is usually appreciated somewhat, although if the other eleven parts of the project are off in the weeds, the total value realized is probably not all that great. Such is too much of the software world these days, and from discussion with friends in even fairly different specialties, it is hardly my isolated experience.

Posted on 6/23/14 3:45 PM in reply to James Coplien.