It’s a funny term – yea “HAPPY PATH”. But I see software engineers, product designers; even bricks and mortar architects falling guilty to overusing it. Wikipedia defines the “happy path” as the “default scenario featuring no exceptional or error conditions, and comprises the sequence of activities executed if everything goes as expected.” The happy path is often the 99% case that a user does every day with our software. A person who enters or leaves a building by opening a front-door is using the happy path; they almost never crawl through a window or a backdoor.
So what’s the problem with it? The problem is we as engineers are so focused on coding, designing and making our happy paths that we neglect the unhappy path. The unhappy paths, even though not as likely as the happy path can cause huge problems. Major software security flaws result from unhappy paths. Who would pass a 50 megabyte string without a NULL terminator to my function? Answer: a hacker who wants to take over your website to exploit a buffer overrun. Who would want to exit a building through a window? Answer: a person trying to escape a fire because the front door is blocked.
But unhappy paths in our software aren’t always as spectacular. Sometimes simply ignoring some basic exceptions to our basic scenarios can cause problems for our users. HTTP clients (like the Mozilla Browser) may expect to work well with a particular version of a server, but a newer or older server version (less typical) may cause the client to fail to load a web page. In another example, some users may not have required version of the .NET Runtime installed on their computers. When they go to install software which uses the .NET Runtime, they could get forced into a 45 minute software update just to get a piece of software running on their computer.
Notice how over focus on our happy paths makes for bad design. A 5-story building with an elevator and a small staircase in the back of a building is a good example. A person on the 5th floor needs to wait for an elevator to take them to the 4th floor, or be forced to walk 5 mins to the back of the building to descend a floor.
So how does one avoid unhappy paths?
- Don’t rush things. Midnight coding is fun in high school and early university years, but its not the way to build quality into our software
- Teach ownership of code. Teams that build software should feel like features are owned. Especially when software is built by contract or hacked together, it’s easy to treat things like “Done, I’m finished”. But software is a living, breathing, changing product. And having ownership of a feature allows people to say, “hey, I can make this better or I just thought about the case where someone is coming out of the shower and this/that happen..”
- Don’t just write unit tests for the happy path. TDD (Test Driven Development) trains people to think about all the cases. But think and rethink to make sure you cover your unhappy paths too.
- A little randomness is good. Make brainstorming a good practice to review people’s work. Ask questions like “What if…” and “What happens when…”.
Finally, building happy paths is fine as long you remember there are also unhappy paths out there. A cold camper trying to light a fire in a forest is fine, as long as they stop to notice the bear and the “no fire danger” sign next to them in the darkness.