Acknowledge (and Learn from) Failures

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
As a programmer you will do things wrong. Maybe you underestimated. Maybe you misunderstood requirements. 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 can correct and be sure that the customers get the software that they really wanted.
+
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.
 +
 
 +
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.
Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. 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 the power in the development team, which is the wrong place.
Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. 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 the power in the development team, which is the wrong place.

Revision as of 23:09, 28 December 2008

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.

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.

Acknowledging that something isn't working takes courage. Many organization encourage people to spin things in the most positive light rather than being honest. 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 the 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 also denies you a chance to learn and reflect on how you could have done better, and improve your estimation, or technical skills.

Agile methods are based on this sort of frequent, honest, feedback, but you need not just apply this idea to daily standup meetings and iteration reviews. It also applies 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 yo 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.

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