I have a theory that agonizing over difficult decisions is always a waste of time.

To decide between two or more options, we must predict how good an outcome each choice will produce. Decisions are only difficult when this is an approximate estimate, because if we knew for sure, we’d just pick the option with the best outcome and be done with it!

When estimating future outcomes, we must consider not just what outcome we predicted, but also our confidence as to how accurate this prediction is. Most things in life are at least close to normally distributed, so we can map our confidence level to standard deviation, and plot this as a bell curve where the X axis represents quality of outcome and Y represents probability of achieving that outcome. Considered this way, most decisions look something like:

That choice is easy: we should obviously pick the blue option.

Difficult decisions, the kind we can agonize over for hours, days, weeks, or even months, occur when it is not so obvious which choice to pick. There are two reasons this may be the case. Sometimes our estimates are quite accurate, so standard deviation is low, but the predicted outcomes are very close together:

There is a lot of overlap between these curves, so it may not be obvious which to pick. But here’s the thing: if the outcomes are so close that we can’t easily tell which is better, then it doesn’t matter which we choose! Both will give a similar end result, so we should just pick one and stop wasting time thinking about it.

The other possibility is that the predicted outcomes may be significantly different, but our estimates are poor so standard deviation is high:

There is much overlap between these curves, so we can’t be sure blue will turn out better than red, but also a high chance the outcomes will be quite different, so we can’t just choose at random.

The right way to resolve this situation is to gather more data, which improves the quality of our estimates and thus reduces the width of the curve. Spending more time thinking about the problem can occasionally help, but this usually requires proactive efforts such as building experimental prototypes or researching the problem to learn from the experience of others.

I’ve been trying to train myself, instead of procrastinating over non obvious decisions, to consider whether I am finding the choice hard because the outcomes are too close together, or because my estimates have too wide a standard deviation? If the former, I should just choose something at random and move on. If the latter, I should go do more research to improve my estimates.

Now if only I could reliably tell which is which ðŸ™‚

Have you read Blink yet by Malcolm Gladwell? He covers this a bit in a few of his chapters and it's just generally a fairly interesting book on a very interesting topic (the art/act of making snap decisions).

Political beliefs aside, Bush's book is all about having to make a decision and simply sticking with it. Sometimes you're right and sometimes you're wrong. Put on the Nike shoes and Just Do It.

But, no matter how far you've traveled down the wrong road, it's always better to turn back. With one exception: If you can finish the project and then forget for good, you've got the choice, whether to pull through, or turn back.

When a choice is hard, i'll strart with the more elegant and possibly more complex approach and see where it takes me. Usually the first issues arise early and give you a lot more data to think over your choice. One or two major iterations are inevitable anyway, so you might as well experiment with the real thing.

What i find this blog entry didn't cover is the importance of the decision. How much difference in quality there is in relation to the whole project. Cutting the loading time in half is next to nothing if that time is only a few seconds.

What i also find a very important criteria is the work involved. Most of the decisions follow the 80/20 rule. If it produces a slightly better result it might be a lot more work. So the best choice is the one that just gets the job done.