NIST Estimates Sloppy Coding Costs $60 Billion/Year
An anonymous reader submits: "Computerworld is reporting on a government study just released that software bugs are costing the U.S. economy an
estimated $59.5 billion each year, with more than half of the cost borne by end users and the remainder by developers and vendors. Better testing could allegedly cut that by one-third."
Wouldn't bugs tend to increase the U.S. economy? Yes, someone has to pay, but that means someone is getting paid. So actually software bugs increase the GDP by $59.5 billion each year.
I skimmed through the article and I didn't see any place where it said how much it would cost to actually produce bug free code. I'm betting much more than the $60 billion arbitrary figure they came up with. And any additional cost in such a task would be passed on to the customer anyway, so they'd still foot the bill.
In any case, there's "good enough" software. If you lose 5 minutes to bugs per day, but overall the software saves you 2 hours a day vs. your previous way of performing the task, then you're coming out ahead anyways.
I give it until the end of the week before we start seeing opinion pieces, some disguised as "independant think-tank studies," suggesting how to fix this. And I'll just bet the best-funded pieces are all going to suggest formal (ie: commercial) structures, not some silly little "standards" that just anyone can follow.
Nope, no sig
Comment removed based on user account deletion
Honestly, I bet "better testing" probably would cost the US economy more than $59b.
1. Longer time to market = longer ROI
2. Additional costs of testing = higher package price
Given that we exist in a free market society, I'm willing to bet that free market principles are in effect and $59b in software bugs is a good balance.
Skiers and Riders -- http://www.snowjournal.com
There is silver bullet. We must emulate the parallelism of hardware ICs in our software ICs. In a 1995 article titled "What if there's a Silver Bullet..." Dr. Brad Cox wrote the following:
Building applications (rack-level modules)
solely with tightly-coupled technologies like
subroutine libraries (block-level modules) is
logically equivalent to wafer-scale
integration, something that hardware
engineering can barely accomplish to this day.
I disagree with Dr. Cox, primarily because subroutine libraries have no analog in integrated circuits. The biggest difference between hardware and software is that the former operates in a parallel, signal-based environment, whereas the latter uses sequential algorithmic code. I believe that this is the main reason that hardware is orders of magnitude more reliable than software. My approach completely eliminates algorithmic coding from everyday software development.
Blame software unreliability on a software coding practice that is as old as Lady Ada Lovelace: the algorithmic code. I am convinced that, if we stop basing software construction on the algorithm, we can expect several orders of magnitude improvement in the reliability of our software.