You need to remember the context when this study supposedly took place. "Production" used to have a literal meaning -- producing physical media. 100x was a reasonable number to believe in that case even without extreme situations like a mission to Pluto.
I first learned this in QA training. It's been decades so I don't remember if 100x was mentioned. They listed all the people required to fix a bug once it had gone to production. Off the top of my head that included:
- Customer support handling calls from customers -- possibly thousands of times. This isn't necessarily part of the cost of fixing the bug, but it's part of discovering a bug in production.
- Some combination of managers and product managers prioritizing the bug and scheduling programmers to fix it.
- Programmers finding and fixing the bug.
- QA validating the fix.
- Writing an installer for the fix.
- QA validating the installer.
- Producing the fix.
- Shipping the fix to effected customers -- which may be all customers.
We were being trained to do QA, so we compared that to the cost involved when QA discovers a bug. That was essentially just the cost of us writing a bug report and programmers fixing the bug.
Adding onto this, if the fix requires some kind of notice or error message detail that didn't previously exist it can also require work from your internationalization team to translate that error into N languages your software supports.
I did forget that. I'm pretty sure that was actually listed in the training because the company I was at made software that was translated into a lot of languages.
Replying to myself because I got too excited and hit enter.
Compare the above to a modern SaaS company. Customer support handling the reports is a fraction of the cost because it doesn't require spending time on the phone with each customer. Most don't have QA, so those costs are gone. No writing and validating installers. No cost of making and shipping physical media.
One other thing is that programmers were a lot cheaper then. So the time a programmer spent actually fixing the bug was even less significant.
The costs are not gone, they became externalities. If you're a SaaS customer, and wrote some code that (unwittingly) depends on the bug, now you have to rewrite it, for instance.
There's a more subtle issue with fixing bugs once you have shipped: Some customers might consider the bug as part of the product and built functionalities around it.
Learned of this one [0] the other day, in the remarks of System.Net.IPAddress.TryParse:
"Fixing this bug would break existing apps, so the current behavior will not be changed"
In other words, the obvious method to use to validate whether or not a string contains a valid IP address can't be used because existing applications expect the broken behavior, and thus it will not be fixed. Correct parsing of an IP address is an exercise now left to the user (to get wrong).
I first learned this in QA training. It's been decades so I don't remember if 100x was mentioned. They listed all the people required to fix a bug once it had gone to production. Off the top of my head that included:
- Customer support handling calls from customers -- possibly thousands of times. This isn't necessarily part of the cost of fixing the bug, but it's part of discovering a bug in production.
- Some combination of managers and product managers prioritizing the bug and scheduling programmers to fix it.
- Programmers finding and fixing the bug.
- QA validating the fix.
- Writing an installer for the fix.
- QA validating the installer.
- Producing the fix.
- Shipping the fix to effected customers -- which may be all customers.
We were being trained to do QA, so we compared that to the cost involved when QA discovers a bug. That was essentially just the cost of us writing a bug report and programmers fixing the bug.