How to never fail

In rock climbing, courses are graded based on their difficulty, and in general, the higher the grade the harder the course. There are several grading scales, where one of the popular ones is the Yosemite Decimal System. On that scale, the 5.12 grade is considered magical, and for many intermediate climbers it is considered to be out of reach.

For climbers aiming to beat the challenge of climbing a 5.12 wall, one of the more important lessons is: fall. The fear of falling during the climb stops you from trying difficult moves, keeps you from testing your limits and eventually prevents you from pushing your performance envelope. So – fall. Again and again, first in a controlled environment where you know nothing bad will happen, then fall from a little higher (you’re always connected to the rope, and you must always follow all safety procedures) – but trust your equipment and, more importantly, trust yourself.

In Software development, there are many ways you can fail – you could miss deadlines, you could have bugs, the project could exceed its budget, the customer may not be happy with the results, and it could be all of the above. So we add guards – we create a project plan, get a bug tracking system in place, do automatic testing, make sure there are reviews and reviews of reviews, get a project manager, a program manager a product manager and development manager, make sure they all meet and update each other regularly, and we then add the secret ingredient – a buffer.

What’s good about buffers is that you can never have too many of them. And if you fail, the easiest way to learn from your mistake is: add some more buffers next time. The problem is, in my view, that we’re getting too used to buffers. At times we don’t even remember why we added some of them to begin with, we just know that if we don’t do another review, get another meeting in place or add some extra time – something really bad is going to happen.

No one likes it when bad things happen to them. No one like to fall. It hurts, and you could get injured. But aren’t we missing an opportunity to learn what we can really do? Isn’t adding another buffer a dangerous block to seeing what our limits really are?

I realize there are many open questions here (like: are the customers willing to pay for you taking extra risks, and should they? can you actually control the amount of risk being taken without getting yourself killed in the process?). It may be that when things get complicated enough, when the project becomes big enough, you just have to add brakes and balances, or you will cause more damage than good. But does it mean we have to give up on our full potential at this point?