Exceptions aren't Exceptional
Darye Henry • Aug 29, 2017
reposted from Medium with permission
One lesson that I’ve learned over and over again (because apparently learning it once wasn’t good enough) is…whatever can happen, will happen (read Murphy’s Law). My simple explanation for this is that given enough time, whatever can possibly happen in a given situation will eventually happen. Sometimes it good, most of the time it isn’t.
The best case scenario, in any situation of consequence, rarely happens. I mean, pretty much never happens. But even though you just nodded your head in agreement, when you plot out your next start up, software feature, date with your spouse :), you are going to imagine the best case scenario, and depending on your level of experience, that is all you will imagine. You will draw out your plans and envision that when everything goes right, you’ll be diving in your golden coins like Scrooge McDuck, without planning for the inevitable concussion and compressed spine from diving into a pile of hard coins — didn’t think that through huh?
Now don’t get me wrong, there is nothing wrong with dreams and goals. You’re supposed to dream of the ideal situation. The ideal situation is what drives us and keeps us motivated. HOWEVER, if your plan only considers the ideal situation, then you’ve failed. And more specifically, you’ve failed at planning for failure, which will most likely cause you to fail. Failure is to be assumed and should be built in. Contingency is the default, not the exception. This is true in software, this is true in business, this is true in life.
In software we have something called “exception handling” — how does the software respond when an event outside of the expected path occurs. With software you don’t have the luxury of ignoring the unexpected path because the unexpected is to be expected — stuff always breaks, servers go down, customers revolt, and, oh yeah, there goes that perfect date night you planned.
So the real question is how do you do some real life exception handling?
FAILURE IS TO BE ASSUMED AND SHOULD BE BUILT IN. CONTINGENCY IS THE DEFAULT, NOT THE EXCEPTION.
First thing is take time to think (I’m a big fan of thinking). Realize, it’s easy and fun to think of the one and only desired path, but we can’t live in a dream world. Have you taken time to think of the more realistic, more plentiful, wayward paths that will most likely (read, definitely) happen?
We implement this mindset at DeveloperTown Starts when defining new features for any given software product. There is one desired way for the new feature to work, but we take time to find out that there are 5 known possible errant outcomes. Then we build protections in the code, so those outcomes are gracefully handled. But even with all that we know, there are probably another 5 cases that are yet unknown.
Here’s a simple question you should ask yourself for any idea, plan, strategy: What can go wrong?Next step… answer that question over and over and over again until you don’t have any answers left. Then share your idea with somebody else and ask them the same question.
I know, I know, this sounds depressing (and it can/will be). For many people, they don’t hear “What can go wrong”, they hear “Why this won’t work”. Therefore, hearing so many ways something could go wrong, would just serve to cause them to ask if it’s worth it and question the meaning of life. But that’s good! It’s a reality check for you, and an early one. A reality check that happens all in your head is much better than one that occurs in real life.
For example, imagine spending all your life savings on a new startup idea that crashes and burns. Think about that just a little longer… I’ll wait. Ok, so aren’t you glad that was only a mental exercise versus a real situation? So think it up, hurt your brain a little, make yourself feel bad for a while. Your therapist would never tell you this but… THINK BAD THOUGHTS! It can be healthy.
We need to break the habit of merely wishful thinking, so that our concepts will stand up to scrutiny and become a reality. Don’t be afraid of the hard questions. If you are, then you’re not ready! Or maybe you’re ready to learn the hard way, which is valid too and many times the only way we learn. It’s just, well, hard.
Now the real question is, once you find all the holes in your logic, all the ways your competition will eat you alive, how you will run out of money too early, how your first developer will write bad code, what are you going to do with this information? Are you going to throw your hands up and quit? Are you going to wallow in self doubt? Or will you take the time and come up with preventative measures and resolutions then plow forward?
In order to rise and overcome these challenges, you need to handle these “exceptions”. Come up with a plan on how to deal with each one, it’ll make you and your idea stronger. Don’t be discouraged by the potential pit falls. You’ll find out that exceptions really aren’t as rare as the term makes them sound (they’re not all that exceptional). Exceptions are normal, exceptions are normal, exceptions are normal (I’m hypnotizing you).
IN ORDER TO RISE AND OVERCOME THESE CHALLENGES, YOU NEED TO HANDLE THESE “EXCEPTIONS”. COME UP WITH A PLAN ON HOW TO DEAL WITH EACH ONE, IT’LL MAKE YOU AND YOUR IDEA STRONGER.
Good strategies handle exceptions, just like good software does. Because once you really understand “whatever can happen, will happen”, then you’ll understand that if you want to be successful, you don’t have a choice but to gracefully handle failure.
Addendum: I am by no means advocating for analysis paralysis or to avoid risk because of high chance of failure. When it came to marriage, one of the riskiest decisions a person can make, I didn’t have all the data and I didn’t know all the potential pitfalls, and it was the best decision I made in my life.
All decisions can’t be made by having an immediate answer to all potential future problems. Some things you will just have to figure out in the moment.
So with all of that said, go take some risks!