They say that the most bug-free code is the code you never write. This may sound sarcastic but it’s true. The less code you write, the less likely it is to be wrong.

But less code can also end up less useful. What about edge cases? What about desired functionality? What about customer or user demands? You have to strike a balance.

How likely is that edge case? How important is it that the system accept it instead of reject it as unsupported? What’s the relative value in supporting it, in profits or other outcomes? Every dollar you spend on coverage is a dollar you may never get back. But that investment may make all the difference to a user otherwise locked out of the system, and profit alone can’t capture the value of that.

“[I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”. Every new line of code locks your system into a fixed way of thinking. Every feature left un-automated and reserved for manual invervention retains the advantages of human assistance and human oversight. As long as someone can intervene when the system cannot address a problem, new opportunities for learning arise. If you did the math, how many lines of code would you have left in you?

Every edge case you cover is more code that could impact the entire system. Code that “should never get called” is often the least hardened and least trustworthy, yet a black swan event may lead to the code run countless times with no one there to pull the andon cord and stop it. (Search for the horror stories around million-dollar mistakes with Facebook ads, AWS services, high-frequency trades, and the like, just not right before bed.) It all comes back to how the code you don’t write is code that can’t break. Spend those remaining lines of code wisely.