The Power of Positive FailureBy Paul Ballard
While it might seem a bit paradoxical to think that there could be such a thing as a “good” failure the fact is that some failures lead to better code, better developers, and ultimately a better product. On the other hand, some failures are only “bad” and lead to nowhere particularly pleasant. It helps to know which failures to fear and which to embrace, but of course first you have to be able to tell the difference.
The primary difference between good failures and bad, are the actions that arise as a result. If for example, you have a significant defect in production that causes panicked late night meetings, emailed threats from management, and teams overdosing on NoDoze then it’s easy to get caught up in the frenzy to fix the defect and forget that this is an opportunity to learn. Sure, after the fire dies down and the executives all move on to other catastrophes you might do a root cause analysis and there may even be actions to take afterward. But many times without the intensity and focus that the defect caused even the best of intentions to improve can get lost in apathy and a “business as usual” mindset. That failure becomes only bad, leading to no improvements.
Defects however aren’t the only cause of “bad” failures. Developer apathy or an unspoken acceptance of mediocrity can also lead to code that is destined for failure, whether it be defects, lack of innovation, or loss of a competitive edge. In these cases, most often the actions taken is nothing, a quick sweep of the code under the rug or into production and the assembly line of crap code keeps moving.
Good failures however, lead to immediate actions and long term benefits. For example, a team that is committed to adopting TDD could decide to create a defect based on the lack of code coverage for a particular bit of work. That defect could count against them in the short term, perhaps wrecking their sprint velocity or even causing a release to be delayed. But in this case, the failure of the immediate item will have the long term affect to galvanize the team to correct the coverage in the next iteration which will improve the quality and testability of the code for as long as that software exists. It will also work to create better, more disciplined developers. And that is a very “good” thing!
The way to make failure a good thing is to change the way the team thinks of failure itself. In fact, the very acceptance of a failure as a “good” thing by a team will create the opportunity for teams to challenge themselves and their own level of quality. Getting a team to hold themselves to a higher standard AND be willing to fail as a team for not meeting that standard is a powerful motivator and the best possible example of positive peer pressure. If for example, a junior developer causes the team to fail to meet their own standards for quality it’s reasonable to believe that before the end of the next iteration everybody in the team is going to be looking to make sure that the junior developer is successful.
Context is decisive. If you can change the mindset of failure from one of negative impacts to positive action, you can exponentially improve the quality of your products and your teams. Now get out there and start failing!
About the Author
- Meet the Author: David Batten on Continuous Deployment with Team Foundation Server 2010
- Power Up Your Windows Home Server with Power Pack 1
- Get The Windows 7 Privileges Your Code Deserves!
- Choosing To Cut Loose The “Boat Anchor” Developer
- Unleash The Power Of Intents in Android!
- Pluralsight Top 10: Building a Great Software Development Team
- Video: Feel the Impact! Test Impact Analysis with Team Foundation Server
- Get Fast Access to 3500+ Code Samples
- The Err of Business Analysts
- Top 7 Windows 7 Tips and Tricks for Power Users