Head to Pillow (or How to Sleep at Night with Imperfect Software)

This post is part of a series that I’m doing to respond directly to reader questions.

Today’s question is “How does a founder sleep at night knowing that testing on their application is not adequate?”

There are a number of ways to answer this question, including answering the exact question, but I thought I’d take a bit wider view on this one because I think there’s a deeper issue in this question.

There’s a myth that people who have not ever built software come into building tech expecting, and that is that you can build software that won’t break. While you can get close in systems like air traffic control, most of the time the juice of trying to even get close to zero defects is not worth the squeeze. It costs so much time and money that you end up in paralysis.

If that’s the case, then how do you build something that’s tested enough to let you sleep at night? Here’s some guiding principles (many of which you’ll have read before on this blog), and I hope it answers this reader’s questions:

• From the very beginning of your project, build in test automation. By far the most mistakes in software projects happen when a developer changes something that has unintended (and undiscovered) consequences. Something that feels innocuous and isolated flips a trip wire in some other part of the application and boom! all hell breaks loose. By covering the core parts of your application in test automation, this risk diminishes significantly.
• Let people who don’t have any idea what you’re trying to do use your app as soon as possible. Other humans have a way of finding problems that you will never find within your four walls. And, by closely observing them, you’ll learn a ton about what you didn’t do right.
• If you need still more validation, use a service like Applause. Getting QA done with an external service lets you pay for what you use / need, and they’re not friends and family (see previous bullet).
• If you have your own human QA (even if it’s informally done by people in your office), have a documented test plan that you follow with every test cycle. You can quickly build a test plan in Excel or Google Sheets that has the following columns: Action, Expected Result, Actual Result, Tester.
• Whether automated or human, always be refining your suite of tests.

All of these will help you get there, but ultimately if you’re building software you need to be OK with outages, screwing up, and handling it like a pro, sometimes at 3 in the morning. If you’re not OK with that, you’re probably in the wrong business. Suck less every day. It’s as simple as that.