The Happy Path


The best-laid steps to a happy outcome ...

The best-laid steps to a happy outcome …

For the great enemy of the truth is very often not the lie—deliberate, contrived, and dishonest—but the myth—persistent, persuasive, and unrealistic. Too often we hold fast to the clichés of our forebears. We subject all facts to a prefabricated set of interpretations. We enjoy the comfort of opinion without the discomfort of thought.

John F. Kennedy, Yale University Commencement (June 11, 1962)

As a programmer, I have often participated in software development projects.  It was in that context that I first came across the phrase “the happy path.” It describes the sequence of choices that a program-user might make that would result in an output that exactly matches the program-designer’s specifications for the desired behavior of the finished, working program.  Ever since I first heard it, I have continued to be impressed with the elegance of the phrase.  It suggests a springtime walk through flower-gardens and birdsong, leading after a short stroll to a sunny glade complete with butterflies, bunnies, and tables laden with appetizers and champagne.  The happy path is always problem-free and always delivers exactly what end-users want.  It’s a lot like the rainbow that ends with a pot of gold, and is almost that elusive.

Sometimes programmers also use the phrase to talk about the process of software development. When we start planning a project, everything is all bluebirds and sunshine, the Disney version of project management. Smiling bespectacled programmers follow carefully mapped out plans for each development milestone, cheerful music playing in the background. Every carefully defined step leads to the next, following a completely articulated work breakdown structure (WBS). All goes swimmingly as planned towards the successful completion of the project, no unforeseen factors arise, nobody gets sick, and everybody is happy. The boss give you a promotion, the customers write glowing reviews, and you have created a great new piece of time-saving software for the world.

“The happy path” captures several fairly complex ideas in a very simple, easily understood phrase. The basic idea is obvious: it refers to the outcome that will make people happy.  In other words, it is the pathway through a project that results in everything going the way everyone hopes.

Most people are optimists.  We have a tendency to minimize risk factors in any endeavor and imagine the best case scenarios. One of the great things about being human is our ability to take great leaps of imagination and our ability to solve problems. Programmers really like solving problems, so maybe it should not be too surprising that programmers probably spend just about as much time creating new problems as solving old ones.  Why? Because the first time through an attempt to solve a problem, we inevitably create bugs — which are nothing other than new problems to be solved.  Programmers learn very early in their careers that there are almost always unknown bugs in the system they could never guess would arise.  All of us deal with possible outside forces we have no control over (weather, deaths, illnesses) as well as the many factors we could guess might pose problems, if we took the time to do so.  For programmers, bugs are just a fact of life, as certain as death and taxes.  The surest way to make bugs worse is to assume they aren’t there.  Programmers know that the costs of assuming the happy path can be enormous — to their customers, to the companies they work for, and ultimately to their careers

The first thing you should know about the happy path is that it is the exception, not the rule.

Next, let’s look at an idea that is implied by the phrase, but is not explicit.  By using the word “happy” to describe the desired result, the phrase gives a nod to the fact that this is the end that everyone wants–that will make people happy.

Perhaps I read more into this word-choice than anyone ever intended when the phrase first emerged, but it seems to me that there’s an ever-so-slightly cynical suggestion that the pathway through to such a happy result may be overly suffused with the rosy glow of optimism.  It’s what everyone wants — and all too often people tend to see what they want to see.  It is very easy for people to be so strongly influenced by wishful thinking, their hopeful conviction that things will go right, that they fail to look honestly and realistically at the actual likelihood of events unfolding along the happiest of paths.

Another important notion conveyed by this simple phrase is that any outcome (happy or not) is the result of a sequence of events, one leading to the next. A result is one end of a path.  And paths frequently fork at one or more points.  Have you ever followed an unfamiliar path through a forest and come to an unmarked fork? The fork you should take was probably not obvious.  And where you ended up may have depended a great deal upon which fork you chose.

Likewise, events in a project (or in a software program) proceed through a sequence of alternative options, each of which leads to new and different alternatives, and eventually the sequence terminates in some result.  Whether or not the result is desired depends entirely on the path that leads to it.  Some paths might lead to a happy result, but many more of the possible paths probably won’t.

Almost invariably, in my experience, project teams prioritize the happy path.  Of course we all want to be entirely clear about the desired outcome when we are working on an important project.  But if we only allow anticipate the particular sequence of events that constitutes the happy path, we are almost certain to not be prepared for major obstacles and those obstacles can often be big enough to stop the project in its tracks — or at least cause it a lot of costly delay.

This is the main reason why most software projects do not get completed on time and within the original budget.  The planning focuses most of its attention on the happy path and downplays the potential pitfalls.

Nobody likes to be the “nervous Nellie” who is always bringing up concerns, so project members tend to avoid talking about their “negative” opinions, at least in the beginning.  By the time that the issues are obvious, they are all that anyone will talk about, usually along with a lot of finger-pointing and acrimony.  By that point in a problem project, everyone sees the obstacles and the general feelings among the team are anxiety, stress, and fear.  Not exactly conducive to creative problem-solving.

As I read most predictions about how the current explosion of digital capabilities will transform all of our lives in so many happy ways, one thing stands out.

A lot of people are looking at the happy path.


Leave a Reply

Your email address will not be published. Required fields are marked *