Slashdot Mirror
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.
But what choice do they have? You can't buy the older, more stable versions of ANYTHING anymore. As soon as the "New! Improved! Now Shaves Your Cat!" version of QuickPr0n Plus hits the shelves, the older, patched, and reasonably stabalized version of QuickPr0n Plus has been yanked and is no longer for sale.
How many people who got computers with WinME on them really wanted ME and hiow many simply had no choice?
This even holds true with Linux and other Oopen Source/Free software. Many times only the newest versions are available without hunting high and low for a forgotten mirror that has last year's model on it.
Boobies never hurt anyone. - Sherry Glaser.
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
So, the money went from the economy, to the...
To....
You see this kind of headline everywhere!
Well all I know is some of it went to me, because I either help people with buggy software, or help them with its alternative that would never have caught on unless the first stuff was crap.
I think crappy software generates $60 billion a year in business.
If computers worked, I would starve.
Comment removed based on user account deletion
Sack a third of all programmers and productivity would improve. There are many people in this industry who are mentally incapable of ever being competent programmers. They can't cut maintainable code and their bug ridden spaggetti mess just causes problems.
My experience from 10 years of contract coding is that the top third of programmers do 90% of the work, the next third do 30% of the work, and the bottom third do -20%. Sack them and productivity would improve.
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
Yes. Sloppy engineering is a symptom and not a cause.
Engineering at Thiokol did present data about cold-weather hazards to management. The problem was management's decision to disregard the data.
Here's an excerpt from something Boisjoly said:
Some discussion had started between the managers when Arnie Thompson moved from his position down the table to a position in front of the managers and once again tried to explain our position by sketching the joint and discussing the problem with the seals at low temperature. Arnie stopped when he saw the unfriendly look in Mason's eyes and also realized that no one was listening to him. I then grabbed the photographic evidence showing the hot gas blow-by and placed it on the table and, somewhat angered, admonished them to look and not ignore what the photos were telling us, namely, that low temperature indeed caused more hot gas blow-by in the joints. I too received the same cold stares as Arnie with looks as if to say, "Go away and don't bother us with the facts."
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.
I currently work testing airplane navigation sofware per RTCA DO-178B (Software Considerations in Airborne Systems and Equipment Certification). Although its now almost ten years old its still a very guide for the development of reliable software. I often find myself wishing that Microsoft would follow DO-178B when developing/testing Windoze.