Contact Sales

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!