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?

  1. 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
  2. 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..”
  3. 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.
  4. 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.

Posted in Random, Startups on July 23, 2012   0


I’m amazed these days how many business co-founders with an idea search for a CTO rather than build their idea.  I’ve been pitched countless times with a “great idea” that just needs that savvy CTO to help co-found.   But I think senior tech folks aren’t needed to prove an idea.   An idea is something that needs to be proven through market testing.

Lean Startups are all about well “lean-ness”.  Hiring a CTO before you have a fully baked idea is not the right use of resources.  A CTO will plan and architect out your company technology strategy over a long period of time.  But the most pressing needs of an initial startup are getting a prototype going, acquiring customers and proving a business.   Getting a full blown CTO to start coding and building something before you have a customer #1 and a proven design is not always the right path.    A great CTO can get upwards of 200 – 300K.  You don’t want to hire a Donald Trump to build your 3 bedroom, 2 bath family house in Kansas!

Another misconception about Computer Science is that what gets made in the beginning (i.e. the foundation of your software), can’t be changed later.   Unlike our brothers/sisters in mechanical, structural, and other hard-core engineering areas, software code gets constantly rewritten, refactored and redone.   When I worked on Internet Explorer, we built it on the NCSA Spyglass Browser code base.   Bit by bit the code from the original was removed and redesigned.   I don’t think any of the original code is still there.

What I do see people doing is hiring offshore or local contractors to get going.  Also hiring employee/programmer #1 is a good solution for business founders.  Programmer #1 is not the guy who needs to build the next Google Page Rank Search System, but rather the dude to get things going.   In fact, often times I think a hack-a-thon pro is way better suited then someone who’s thinking a year down the road by building elaborate build systems with nice architecture.  Programmer #1 is going to be faster, cheaper and more nimble for the early startup.

This all makes sense if you’re building a straight web site to sell your idea.  The one big exception here would be on startups that are built on a technical heavy idea.   Well if you have a startup building rockets for reaching space or advanced biotech, then I would hope there is a technical co-founder onboard.

I’ve also visited many startups post-raise with a successful development team looking for CTOs.     They’ve made it that far by being nimble.

Posted in Cofounding, Startups on July 8, 2012   0