Reasons not to write bugs

Let's say you have a choice between writing code that will work 99.9% of the time, and writing code that will work 100% of the time.

What's the value of that last 0.1%?

• It will save you from a debugging nightmare later, when users report problems that you can't reproduce or diagnose.

• It will prevent service outages from happening if/when the system changes so the 0.1% case is now a 10% case.

• It will avoid contaminating your data with anomalies that downstream consumers will have to patch up, filter out, or (most likely) handle incorrectly — which would create bigger problems further downstream.

• It will save your support team time. If your code serves a million requests per day, that one-in-a-thousand bug is going to affect a thousand people every day. A few of those people are likely to call support.

• It will save your users time. Humans have terrible intuition about orders of magnitude, so do the math. If the bug affects 1000 people per day, and each person spends a minute working around your bug, that's equal to two 8-hour workdays wasted. Every day.

• It will keep your error logs quiet, so you can quickly spot and fix unexpected errors instead of being distracted by expected errors.

Finally, and most importantly — it's just the right thing to do. You and your users both deserve code that works.

True, we can't foresee and prevent all bugs. But we can foresee some bugs. (like the one I was about to write, when I started writing this post instead!)

Sometimes, we know what the "right way" is, but the "wrong way" is just so tempting. My goal in writing this post is to make it seem less tempting.