Greg’s Law: there’s an economic value in a bug not existing

Think of a bug. Any bug.

Actually…

Think of the worst bug you can remember. The one which had the biggest impact on the business, the users or the product. You decide what the measure of “worst” is. We all have our own yardstick for terror.

Now estimate the financial impact of the bug both in the direct and the indirect costs, but also the intangible costs of bad feelings, customers leaving, leads going cold or taking longer to buy.

Now work out how long it would have taken to fix the bug upfront if someone had written the requirement. How long to program the fix, ensuring it never gets into production?

The economic value of that bug fix is the difference between the impact of the bug and the cost of coding the fix. This is a number nobody thinks about, but has a direct impact on cashflow and profit of the business.

We think of this as Greg’s Law: There is an economic value in a bug not existing.

The more unknown bugs are out there in your code, the higher the risk that you’re going to have to pay off the technical debt pretty soon. But that line doesn’t appear in your accounts as “technical debt which might be called in at any time.” We trundle along happily ignorant of the potential cost of bugs.

This underpins much of the thinking about software quality and processes. The sooner a bug doesn’t exist, the more valuable the software is since it comes with fewer unknowns; the lack of bugs causes the software value to increase.

With hindsight you can measure how valuable it would have been for a defect not to exist, and this can be something worth doing since it puts into sharp focus the cost of your previous technical debt.

Now think of some other bugs and estimate the time spent on working around them, on avoiding the functionality, on talking around them in sales demos, on writing extra software to detect and fix broken data and connections, and on every other avoidance technique you had available.

This is more than the cost of the programmer’s time.

An issue which causes one office admin to take 10 minutes extra each day costs more than a full working week each year per person who uses the software. An issue which causes 1% of your ecommerce conversions to fail doesn’t just cost that sale, it costs all the repeat sales in future. A bug in your app which causes a crash will accelerate the uninstalls and depress growth.

However you measure your software quality and failures, not including long running issues when they finally surface can give a very skewed view of things. The longer bugs are around and the slower you’re able to address them, the less profitable you’ll be. That’s Greg’s Law.

There are ways to fix this, but there are a number of common strategies which will not work:

First, scale the team to deal with issues as they’re reported. This doesn’t work because the background knowledge required by developers slows down the process and they rapidly end up providing workarounds and placating customers rather than solving problems.

Second, work around the issue, which just annoys customers and your internal team. This becomes a 10 minute issue using up a working week each year.

Rely only on debugging by hand: manual replication, adding in more and more logging messages, repeated calls for “more information to replicate the issue”. If your team is doing this, you are losing money and the faith of your customers.

Developers who understand all this invest heavily in their tools, since they know this is the way you scale your team and reduce the impact of complex and hard to repeat bugs. They set up clean working processes from product ideas, through dev, automated test and deployment. When a question about the live environment comes in they have the information there.

But that doesn’t often happen because tools look expensive. Spending a portion of a programmer’s salary on something which might be useful is viewed by accountants and managers as a waste of money. Toys for coders.

Apparently (but not really) expensive tools are compared with a zero cost of rather than the total cost of bugs existing.

Tooling can be expensive but, as Greg’s Law tells us: bugs can be far more expensive.