Acknowledge (and Learn from) Failures

From WikiContent

Revision as of 19:36, 3 January 2009 by Sberczuk (Talk | contribs)
Jump to: navigation, search

As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. Maybe that framework was not the right choice. Maybe you made a guess when you should have collected data. If you try something new, the odds are you'll fail from time to time. Without trying, you can't learn, and without learning you can't be effective.

It's important to be honest with yourself and stakeholders, and take failure as an opportunity to improve. The sooner everyone knows the true state of things, the sooner you and your colleagues can take corrective action and be help the customers get the software that they really wanted. This idea of frequent feedback and adjustment at the heart of agile methods and it's useful to apply in your own professional life regardless of your team's development approach.

Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. This is counter-productive; telling people what they want to hear just defers the inevitable realization that they won't get what they expected, and it also takes from them the opportunity to react to the information. Maybe a feature was only worth implementing if it cost what the original estimate said, and changing the scope is to the customers benefit, for example, so acknowledging that something won't be done on time gives the stakeholder to power to make the decision. Not acknowledging a failure puts this power in the development team, which is the wrong place.

Most people would rather have something meet their expectations rather than get everything they asked for. Given bad news stakeholders may feel a sense of betrayal. You can temper this by providing alternatives, but only if you believe that they are realistic.

Not being honest about your failures denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.

You can apply this idea not just to major things like daily standup meetings and iteration reviews, but also to small things like looking over some code you wrote yesterday and realizing that it was not as good as you thought, or admitting that you don't know the answer when someone asks you a question.

Allowing people to acknowledge failure takes an organization that doesn't punish failure and individuals who are willing to admit and learn from mistakes. While you can't always control your organization, you can change the way that you think about your work, and how you work with your colleagues.

Failures are inevitable. Acknowledging and learning from them provides value. Denying failure means that you wasted you time.

By Steve Berczuk

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools