Fail fast, fail often. In the new development world at my office (now two years old), this mantra has been repeated countless times. While at first it seemed like it was another one of those Silicon Valley fads that come and go after a couple years, this one seems to have legs, mostly because it’s common-sense — and it works.

One of the books we were recommended on how to improve our Agile development processes was “Fail Fast, Fail Often — How Losing Can Help You Win” (synopsis/highlights). The basic synopsis of the book is “When you have an idea, just do something with it as fast as you can, learn from your mistakes, make adjustments, and try again. Lather, rinse, repeat — over and over and over again as quickly as possible. There is no real finish-line in the process, just a thousand (or usually more!) adjustments all along the way.

The real problem that “Fail fast, fail often” attempts to address is inaction/inefficiency because of indecision. Fear, specifically being afraid to fail, makes many of us freeze and get stuck in the “idea” or “design” phase for too long, and sometimes great ideas die before they ever see the light of day. The fear of failure or second-guessing something can be utterly paralyzing and can bring everything to a screeching halt. In the software world, we call this “analysis-paralysis,” in which progress moves very slowly because of over-designing, indecision, and fear. In essence,  poor leadership and weak decision-making because of the fear of failure.

On my development team, we used to have these days-long design sessions to hammer out every minute detail of a new feature from the user experience, classes, services, database tables, and everything in between. Literally everything was planned out before a single line of code was written. It was mind-numbingly boring, then we would rush out and develop the thing as fast as we could with the time we have left. We never really failed until the last possible minute, and then it was usually ugly at best or disastrous at worst. The solution to this problem of “failing last” was “failing fast” and it’s been literally hammered into us.

Now, two years later, we are adept at failing fast — we can fail fast like nobody’s business!  And failing often? Why, we’ve got that one down too! We can do both so well that now we have the opposite problem of building complex features not being adequately designed before we start cranking out the code. We rush in and write code until we hit a roadblock, then we back off and design a little bit, then jump back in and repeat until the next roadblock. In short, we’ve swung from one extreme of over-thinking with too little action to the other extreme of over-acting with too little fore-thought.

A problem with mantras like “Fail fast!” is that we tend to forget the original problem we we were trying to solve. We solve one problem with another, then another, then another (and adding processes and safeguards along the way) until we forget what the core problem originally was, in this case, over-thinking and over-design — analysis-paralysis. The real point of “Fail fast, Fail often” isn’t being good at failing, it’s “learning from your mistakes” and adjusting your processes (or products) to be successful. And part of that is learning to have moderation when it comes to new ideas and new processes. “Eat the meat, spit out the bones” is probably a better mantra than “Fail fast, fail often” but isn’t nearly as catchy, particularly since we’re all familiar with failure.

How often is the same true in our everyday lives, where we fall prey to analysis-paralysis? How often do we wait to put off making those big decisions and worry ourselves sick with indecision until we end up worrying more about our indecision than the actual problem? Of course, it’s usually foolish to dive into a pond without looking first, but how many times do we stare at that same water and wonder how deep or cold it really is, when we should really just try it out first? The flipside is jumping into something without thinking about it first — leaping without really looking. How about using experience, common sense, and a little of that wisdom that we’ve been blessed with?

Along with “failing fast”, another major adjustment we’ve had to make at the office is learning to be comfortable with being decidedly uncomfortable and continually learning new languages and methodologies. It’s one thing to be challenged by the immediate problem to solve with software, but quite another to be challenged with syntax, architecture, and other fundamental considerations. Imagine going to work everyday and feeling like you know very little, as if you’ve just started the job a week ago and know next to nothing about the system. It’s not a pleasant feeling, particularly when it drags on for awhile. But it’s only a feeling, and the more you get used to it, the easier it gets (well, at least in theory!).

Imagine having to write a term-paper about a subject you’re not completely familiar with. As if that isn’t enough of a challenge, throw in the fact that this paper needs to be written in a different language, must be peer-reviewed, and written as a team effort with several different people who are just as bewildered and bumbling as you are! Not only that, but imagine that your grade (if not your entire academic future) hinges on getting an “A” on that paper!

That’s what life in the office has been like for most of the last two years, and there’s no sign of that changing anytime soon. Though we’ve been quite productive, it hasn’t felt that way because we never really have time to settle in and fall into a cadence/rhythm with anything. I suppose there’s another life-lesson in there somewhere, in that you really are making progress even though you may never feel like it — until one day you finally stop and look back and see the huge distance you’ve actually covered.

In writing books, it’s not the meticulous planning and scene/character details that will turn a book into reality, it’s the writing. It’s plopping down clumsy words and disjointed ideas on paper as quickly as possible and often having no clue how they’re all going to fit together, but writing them nevertheless, all the while accepting that a large percentage of those words will be thrown away before it’s all over. The most prolific writers preach over and over that what matters most is that you’re actually writing something tangible every day and moving the plot along, regardless of how good it is or whether it’ll be thrown out tomorrow. Writers write, builders build, teachers teach, and doers do!

To stitch it all together, failing frequently is a part of just about everything we do, whether we like it or not (which we usually don’t!). What we do with those failures, whether we let them define us or not, and whether we stop trying because of them are just decisions to be made. Most of the greatest inventors, artists, and writers failed hundreds if not thousands of times before they “got it right”, but they’re seldom remembered for those failures — only their success. They stumbled, fell, got back up, and tried again and again. They didn’t necessarily embrace failure as much as accepted it, learned from it, and kept going. Perseverance is not only a principle, but a practice to be cultivated and continually developed.

“Let us not lose heart in doing good, for in due time we will reap if we do not grow weary.” — Galatians 6:9