Investing in Failure
Investing in Failure
Zone Leader Matthew Casperson continues his series on the "laws of enterprise" by looking at rebounding from inevitable failures.
Join the DZone community and get the full member experience.Join For Free
With the influx of DevOps-related products and services on the market, today’s application delivery toolchain has become complex and fragmented. Watch Avoiding the DevOps Tax to learn best practices for integration and automation to realize a faster DevOps lifecycle.
Casper’s fifth law of enterprise states that:
If you are only willing to invest in quantifiable and proven ideas, you’ll only ever invest in the competition’s ideas.
Investing in failure is a seemingly absurd idea. Failure is a dirty word in enterprise, costing money, degrading performance, tarnishing reputations and never creating anything that shows up on the bottom line.
The paradox for developers is that there is little opportunity to do the same thing the same way over and over again.
If you are a chef, you could well build a successful career learning how to flawlessly prepare the same dozen dishes over and over. If you are a surgeon, the ability to flawlessly perform the same operation over and over will save lives. If you are a formula one driver, the ability to flawlessly navigate the same few tracks over and over will put a gold medallion around your neck.
If you are a software developer, your job is to instruct a computer to flawlessly execute the same code over and over, while you yourself move on. In fact the ability to not have to write the same code over and over is one of the goals of a good developer.
Which is not to say that developers can’t benefit from repeatedly applying the same patterns or methodologies, and learning to improve on them with each new project. But there is limited value in solving the same problem over and over.
The question that then faces a lot of enterprise developers is what to move on to once a problem has been solved?
Answering this question usually involves completing a long, arduous decision making process, and these processes are often built around a fear of failure. Check are put in place, endless consultation lists are established, committees are formed, times are estimated, and maybe at the end of it all enough people have said “I guess so” to allow a project to be started.
The only guaranteed way to navigate this maze of failure avoidance is to propose projects that have been proven to work and which can be easily quantified. Which then begs the question, "Proven by whom?" The answer is probably the competition.
The mark of a good IT organization is the ease with which they embrace failure. New ideas can be prototyped, evaluated, abandoned and resurrected without fear of failure, and with a comfortable level of cost and risk. Failure itself becomes a way to explore new ideas and learn from mistakes, and is accepted as inevitable when creating products that set trends rather than merely keeping up with them.
“It’s OK to fail” might be some of the hardest words to say in enterprise, but learning to make failure work for you is essential when business as usual is no longer satisfactory.
Opinions expressed by DZone contributors are their own.