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."
...and in other news, the sun is found to cause sunburn.
Why do we produce faster processors, because programmers are writing sloppier code. And so the viscious cycle begins.
Kinda makes you wonder to whom these costs are actually profits... I got my money on Microsoft =D
Of course, sloppy coding by open source developers costs nothing.
We all want a piece of that 60 billion to fix the bugs!
The revolution will be televised. Blackout restrictions apply.
It originally only cost the economy $6 a year, but there was an unfortunate rounding error in the code that figured out the total cost...
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.
A goverment agency complains that the software industry wastes sixty billion a year in bugs. So how many trillion did the government waste this year?
...
That's more than Bill Gates could personally finance.
IANAL, but imagine a beowulf cluster of in Soviet Russia all your belong are base to us welcoming the new SCO overlords.
...now we get to hear all the ignorant (but believe they aren't) programmers claim that due to some alleged "method" their programming is perfectly bug free and runs more effecient than anyone. Seriously it's as though half the programmers here that supposedly have fantastic high-paying jobs are just making sure that unidentified people are still interested in hiring them even though it would be "stupid" for their parent company to let them go.
...and in other news, you're a tard. Did the headline say "sloppy code == bad"?
This is an article about the impact of bad code, not bad code itself.
--
pants ahoy
"Better testing could allegedly cut that by one-third"
My routines show that number to be 1003.02% that can be cut.
Testing costs money. It's a trade-off.
Yes, we all need to make better efforts towards releasing better software that's been more thoroughly tested.
But, despite this sloppiness, the higher than historical growth in worker productivity in the U.S. over the past 10-15 years has been attributable in no small part to the adoption of software and the automation of business processes.
"Provided by the management for your protection."
Microsoft is posting a $59.5 billion increase in revenue for last year.
Things you think are in the Constitution, but are not.
Because of some sloppy coding at NIST, it's actually $600 billion, not $60 billion. Just misplaced that decimal. Sorry about that, won't happen again!
This is not going to change until software companies become liable for damages when their software fails. Otherwise there is simply no economic incentive to hire competent programmers and do rigourous testing.
Yes, sloppy coding has great costs, but blaming the coding for the state of software engineering is like blaming the rubber O-ring for the Space Shuttle disaster, when everyone knows that it was an organizational issue that prevented the knowledge of the critical temperature from getting out of engineering and into management. Most of the software industry (and I include system analysts, architects, and customers who don't know what they want and won't let us help them determine it) is responsible for:
It doesn't matter how well you code, if the contract requires the coder to deliver an unusable product then that'll be what's delivered.
The fact is people buy software based on its features, and more often than not the latest and greatest feature is a bigger selling point than stability and security for desktop apps.
As long as consumers use this criteria for making their purchase decisions supply and demand will favor the companies who crank out software quickly.
And we will continue to have to deal with bugs.
more than half of the cost borne by end users and the remainder by developers and vendors
Last I checked, I was being paid to deal with this stuff. When my salary goes negative, I'll be retraining as a burger-and-fries-technician.
Poorly made cars cost the US $XX Billion/year, shoddy toilet seats cause millions in health insurance costs, and badly done yardwork costs millions in property value reductions.
Seriously though, why do people expect software to be perfect? It's designed by humans, made by humans, tested by humans, and used by humans. I'd be willing to bet that 85% of the people complaining about some bug in their software are the same people that opted to get the new version 3 months earlier and for 2/3 the cost than to get the "perfect" version that would have taken longer and cost more money.
The situation is a basic economic trade-off. Consumers are consistently choosing to save money when contracting for software without realizing that, hey, big surprise, the money you're not spending is the money that was going to fix all the bugs that are costing productivity now.
Software makers are only to blame in that they offer their customers the option to have buggy software sooner rather than tested software later. If these organizations would stop trying to cut corners and not squeeze every last drop of blood out of the developers in an effort to get the product out the door by the end of the week, maybe it wouldn't be crashing every half hour. When was the last time you heard about engineers taking shortcuts to make sure a construction project finished on time? It's unheard of in physical projects, but in software, consumers think they can get ahead by not waiting/paying for a completely finished product
While this article isn't too bad I've been seeing an alarming amount of press regarding how bad software is. I read arguments comparing software to cars or roads.
<idiot>I built a wooden box to hold a kitchen trashcan last weekend. That box is completly bug-free. Why can't windows be like my wooden box?</idiot> Well, writing windows is harder.
The bottom line is that unless people are ready to wait longer for software and pay more for it you're going to get unpredicable levels of defects. Even if you are willing to wait, you're going to get defects anyway. Writing software is simply hard to do.
That which does not kill me only makes me whinier
Better testing could allegedly cut that by one-third
What about the other 2/3? Is that wasted money that is completely unrecoverable?
I don't understand how this figure could have been generated other than pulling it out of thin air.
-- Adam
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.
If anyone's interested in the _real_ cost, wait until lawyers weigh in, as I expect they already have somewhere. I know Burroughs used to get sued on a regular basis before joining Sperry Univac and hiding behind a new name.
A feeling of having made the same mistake before: Deja Foobar
When overworked programmers make a few mistakes because they've been up all night working on something for an unreasonable deadline their manager demands, it's a horrible thing that the government feels it's necessary to look into?
I bet if there were some sort of programmers PAC that invited Dick Cheney out for a round of golf once and then a report like this one wouldn't have seen the light of day.
Mas vale cholo, que mal acompañado.
Wow. They have said the same thing about illegal drug usage and goofing off at work. I just hope that the politicians and the WSPTOTC (Won't Someone Please Think of the Children) don't create a crazy War on Sloppy Coders and start busting down doors, pointing automatic weapons at coders and shouting "You with the undocumented line of code! Hands off the KB or I shoot!" If I see a TV commercial where some guy with a pocket protector laments "I killed a judge with my sloppy coding", then I am moving to another planet.
This article it typical alarmist FUD. No mention of how much money is saved each year by coders. The sloppiness comes with the territory: unrealistic deadlines, sloppy documentation, buggy interfaces, clueless management, and a changing world. This world of perfection exists only in the minds of the pencil pushers at NIST. In the real world, coders sometimes make mistakes because they are...human.
"What is the sound of one belly slapping?"
I know it's dumb, but first-to-market still trumps quality procedures at all of the places I've worked at, or know of via former co-workers. There are rare exceptions, but it's always due to some nonconforming individual lucky enough to have enough power to force some minimal amount of quality upon a product.
Customers want a solution right away, management forces development to dump those cumbersome QA processes, the QA department gets slashed to the bone and/or filled with cheap new hires who haven't a clue about testing, and the drive is to HIT THOSE (arbitrary) DATES!
Cripes, no wonder the ones who know how to build quality software quickly and cheaply don't get to lead projects for long. These bugs are not a technical problem; they're a business problem. Most techies really want to write quality code, but aren't allowed to, due to these factors.
You can imagine why I might want to post this anonymously.
Profits? Hah.. try being salaried and spending many, many overtime hours attempting to route your network around an M$ bug, or repairing damage done by a M$-enabled worm...
Moderation totals that amuse me for one of my posts: Flamebait=1, Insightful=2, Funny=2, Overrated=1, Underrated=1
Please.
This is much like the rather PR-centric announcements from virus experts that ${VIRUS} caused $${LARGE_AMOUNT}. It's just an estimate, and without an example of an economy with perfect software, it's rather useless.
Yes, people need to strive to create more robust software, but throwing large numbers around tends to blur the issue, in my opinion.
It would be an interesting article if they proposed a system whereby companies are required to reimburse their customers if the software they buy turns out to be a buggy POS.
I could make a living buying second-hand copies of Windows ME and getting refunds from MS :)
Microsofts sales are definitely below 60 billion.
You are the dot in slashdot !
Here's a quick quote:
:^)
[There are very few markets where "buyers are willing to accept products that they know are going to malfunction," said Gregory Tassey, the NIST senior economist who headed the study. "But software is at the extreme end, in terms of errors or bugs that are in the typical product when it is sold."]
Need I remind anyone of the Pinto? How about the recalls we've had recently with everything from tires to airbags? Even if the failures aren't that harsh, who hasn't heard a mechanic say, "Welp, the '89 model uses a Peugeot transmission. They're not exactly, um, the best." Having spent some time under a few vehicles, let me assure you the mechanics aren't always lying.
So there's at least one market where one hardly hits perfection with version 1.0.
Of course software has bugs, of course bugs take time to fix or for a user to work around. The trick is that no software will ever be released bug free that does much more than print "Hello World!" to the console. It's not how much time bugs cost; bugs are a fact of life. The question is whether fixing those bugs would be worth the time it'd take to get them out. With a quick angry glance at the IIS team, often it isn't.
It's all 0s and 1s. Or it's not.
That's why I support linux -- where sloppy coding is free (and Free).
Slashdot: come for the pedantry, stay for the condescension.
...how much money does having buggy software in place save companies? Surely it lets business do things they wouldn't/couldn't do before? If you take that into consideration, some of these megacorporations 'losing' millions to buggy software wouldn't have existed in the first place. Catch 22.
For similar logic, the testing and procedures to develop less buggie code is probably not in the interest of the software writing companies. Microsoft is completely capable of writing bug free software. Trust me, if Bill Gates said look boys we write bug free software, it could happen. However, the would release new copies of Windows every 10 years, they would have possible 10 new features, and nothing inovative.
This $60B loss will continue to happen, until the users pass the loss onto the vendor so they have to eat it all. The other problem is that $60B is an accounting number, and doesn't account for all the savings because they left the bugs in. It is entirely possible that removing the bugs during the cheapest phase (design), would have cost more then $60B dollars.
Yeah, that makes sense. How can the user be to blame here? The every day user sees the computer as a tool that should be working and secure(actually they probably don't think twice about the security part). How can it be the users fault that there is a file attached to another file that could be a virus? I would say that if anyone is to blame for the $60 billion lose would be virus writers and sloppy coders, not the end users.
Also this was mentioned in another cost, if it cost $60 billion someone has to be collecting $60 billion, do they not?
Thank You.
Comment removed based on user account deletion
what ever happened to the 4k assembly competitions... ;)
;)
... and if you had 'em... DAMN!
now that was a challenge... make the coolest full graphic demo in 4k compliled..
i'm still amazed at what those guys could do with a 386/16 and a 4k program...
i remember one specifically that used some vga timing tricks to double VGA resolution -- and render some really sweet 3d graphics.. (fully lighted, textured, etc)
some of these things even had sound....
and another that used similar timing tricks with page swapping to get 4k colors out of EGA with some simple sinusoidal scrollers, blue ->black BG fade at the bottom..
you just dont see stuff like that anymore
I know it's all non-open source and non-portable to other platforms... but that wasnt the point...
some even required a specific VGA card and/or sound card
hell.. you never even see cool stuff like smooth scrolling in text mode
It's a pity that society encourages sloppy and inefficient code.. but... what can we do about it?
how about this: have your source publicly available so that you're encouraged to write code that is efficient, portable, and easily readable...
oh... wait...
;)
p r m t h s
Sloppy coding is the unscientific way to point the finger. More than likely its not the code thats sloppy, its the release dates set by Marketing and Sales, feature list that are promoted before development begins, and poor testing by people more concerned about "this font isn't bold" rather than testing the core product. *sigh*
I wonder if its just a coincidence that sloppy coding costs 60B/yr and MS total revenue fora year is the same figure....
Ok, so the study has determined how much is lost to bugs and who foots the bills. Interesting.
But the concept that by better testing you can reduce this amount is nonsensical unless you know how much the additional testing would cost.
If you spend 50 billion a year on additional testing in the US to reduce the cost of bugs from 54 billion down to 30 billion... you get no savings.
Sure, it may "cost" 60B a year, but this is in a market where consumers are accustomed to flaky products. A look at any Microsoft product's success reveals a patience for buggy code, and even a desire to purchase upgraded product versions. In many cases companies actually profit off of new and improved products. We actually sell more copies off the shelf because the previous versions have so many problems. So bug on!
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 who decides what the US economy is? More and more, I get the impression that when reports and studies talk about the "US economy" they actually mean "the big businesses with lobbyists."
Science may someday discover what faith has always known.
I don't think that I'm far off by saying that a large proportion of bugs go unfixed because vendors can easily avert having to address the problem by saying that it's a result of someone else's piece of software on the system. And when the problem is finally pinpointed, the changes needed to rectify the situation probably lies on one specific company (it shall remain nameless, but we all know what company this is--it is the company with the largest desktop OS user base), and they sit on it for ages before something is remedied, if at all. How many times have we heard on slashdot, "I sent them info about such-and-such bug and even a potential solution! And received no word in reply, nor indication that a patch would be made available."
Imagine if the software industry's mode of business shifted from one of "buying a product" to one of "purchasing a SERVICE." For me, I'd rather pay for a service to ensure that I have all the tools necessary to do my job right, without worrying about instability, than to have a product with all the supposed bells-and-whistles that I can use without problems only 50% of the time.
Linux at home
If it werent for crappy coding and bugs, many of us would be out of a job. Just remember that the next time you have to apply a service pack to yer exchange server or run an IIS update to protect from the latest worm. Those bugs keep IT on the payroll. (yes, yes, I notice that I mentioned IIS... shame on me. :)
You can still do a useful comparison between productivity when using the "ideal" software and productivity using the "current" software.
The complete analysis of hours of work per day would look like this:
Without software: 8:00
With bug-free software: 6:00
With existing software: 6:05
The benefit of having the software is obvious, but the cost of the bugs is real.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
Football pools -- $241 billion/year
Alcoholism -- $1533 billion/year
Drugs -- $800 billion/year
Coffee breaks -- $526 billion/year
Bathroom time -- $715 billion/year
Krispy Kreme Donuts -- $445 billion/year
Software company lawyers -- $440 billion/year
Neckties -- $211 billion/year
Slashdot -- $688 /year
Computerworld is reporting on a government study just released that developers spending their time reading slashdot rather than fixing software bugs is costing the U.S. economy an estimated $59.6 billion each year...
So does this $60 billion offset the amount of money that the software industry claims they lose to software pirates?
How much money do software pirates lose by using illegal copies of sloppily coded software?
News at 11.
$60 BN? Time to cut back on the "bug bounty's" then. (envisioning Wally from Dilbert: "I'm gonna code me a minivan today!") 8^)
DMCA - Chilling free speech since 1998.
I suspect that many if not most of the problems with software today are that the requirements that drive the designs that drive the implementation suck. If testing is the answer then we should realize that test plans are constructed from functional requirements documents. If you don't know what your building, then how can you test it?
I want to be alone with the sandwich
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.
In other news, rounding for attention-grabbing headlines cost $0.5 billion.
Comment removed based on user account deletion
This really should have started out as a cottage industry, as so much else has in the computer industry. But Autocoding really is the solution direction to such software problems.
Funny... M$ products account for $59.4 billion of that total number.
Domains for only $8.75/year! Transfer your domain for on
Everyone wants to blame M$ on this one but don't forget the IRS computer snafu. If they screw up your returns chance are the work does not get redone. They just bill you with the threat of audit to back up their sorry code!
The wages of sin are unreported and back taxes are hell to pay.
Comment removed based on user account deletion
Save 90 to 95 percent on the costs, and have fewer bugs in the first place, plus own the code outright - either BSD (owned by the feds) or GPL or one of the variants.
--- Will in Seattle - What are you doing to fight the War?
I herby invoke the slashdot revised Goodwin's law of 2002!
1) Get to market first, at all costs
2) Continue to add features, based on customer feedback
3) When the product gets good enough (after 4 or 5 major revisions) tout its reliability and stability
More about Microsoft's philosophy here: Microsoft Secrets. It's an old book, but still provides valuable insights into why the world of commercial software development has become more and more insane over the years.
Developers operate in an environment driven almost completely by market forces. Of course this begs the question - how much money would the economy loose if software were not driven by marketing and sales, and developers actually were given enough time to create virtually bug-free programs?
Read the EFF's Fair Use FAQ
Here was the main culprit, responsible for $59 billion of the $60 billion.
Coders need to realize that with great power comes great responsibiltity.
When I pay to have sex with a prostitute its like I'm paying to urintate on a little girl.
Costas DOTSLASH usdsers 6 0 billions mouse clics per yearly
The revolution will be televised. Blackout restrictions apply.
IHRTSY (I haven't read the story yet;)), but I assume that these bugs are costing the economy by slowing down business, not making someone pay directly... and if you slow down business, GDP actually goes down.
Here's a gdenken for ya: Imagine if software bugs were so horrid that they prevented the use of software completely, and business just. Just because they'd have to pay software companies more to get updated versions does not mean that all the business lost due to the bugs would be compensated for.
How much money do MY bugs cost? Do fatal bugs in my code actually RETURN productivity to the workforce? Do bugs in my code actually make money for the US economy?
In the frequently encountered sw development environment good coders are typically placed into a situation where we have to cut corners to meet deadlines. A faulty design or architecture has to be forced in due to time and/or money constraints. How many people here have had to develop to poor &| missing requirements? How did those projects work out?
Another issue, IMHO, is the proliferation of "look, you don't have to think anymore" IDEs. I am currently working maintenance on an "enterprise" project (the only thing enterprise is the price tag) which was built using Java-J2EE (enterprise ready) and deployed on enterprise hardware and app/db servers. Yet our throughput is abominable and we have huge memory issues.
The people who originally wrote this mutated plague 'o the land clearly had NEVER written a Java app in their lives and were writing code more-or-less out of the book (I was hired on when we started maintenance). However, it was written using a very powerful IDE which did a lot of code generation and allowed people with below-average IQs to become Java programmers... If they had tried to write this thing using a text editor, they would have been exposed and thrown out much earlier.
The power of thought and understanding cannot be underestimated. I am leery of any tool that seperates the user from the underworkings of any system, be it OS, language, DB or other. In the end, these tools allow people who have little understanding to create something that barely works.
Just because it will 'javac' doesn't mean it works for sh!t...
Computer Science is Applied Philosophy
No amount of testing can salvage a sloppy design and coding. You need a team of skilled and trained engineers who are dedicated rather than people who just look forward to Friday and who should really been in someother field. Not someone who is in for making money. I guess the problem lies on the so called project managers imbeciles most of whom should be really doing some telemarketing stuff. The silver bullet to highly successful projects is - dynamic leadership, environment and dedicated, highly trained and skilled engineers. All other talk about testing is just rambling...
My 2 cents
Computer tools are amazing, when you think about their complexity. Learn to to live with their quirks, and when delayed (i.e. waiting for Winodws to reboot),do something else that is also productive instead.
RG
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.
You may call it "sloppy coding."
I'm going to call it "job security."
--
http://www.aikiweb.com - AikiWeb Aikido Information
Then, of course, you have to account for the price of quality. It is possible to write extremely high quality software: the guys who write software for the space shuttle do so, for instance. But such robust software costs a fortune and (perhaps more importantly) takes a great deal of time to develop.
In reality, we have nobody to blame but ourselves for the poor quality of software (open source software aside, though it's not immune from poor quality). If people in general were willing to pay for greater reliability for software, those who provide better quality would be doing better than those who don't, and other software houses would take notice of this and start to produce better quality software themselves.
Rather the opposite has happened, of course. And it's not just limited to software, either. Look at the goods sold at such places as Wal-Mart: such goods are often of inferior quality to other similar goods, but they often sell better regardless.
When are we finally going to figure out that people want what's barely good enough for the cheapest price possible? Quality only matters when it's low enough that the product in question falls into the "not good enough" category. Warpage of the market by monopolies aside, the market has decided that the quality of software available is good enough. Otherwise, that software wouldn't sell.
Things might be different if people were thoughtful enough and had enough knowledge to determine the total cost of ownership, or to even care about such a thing. But they're not, probably due in large part to the dumbing down of the U.S. population.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
A microsoft ad. Coincidence, irony, poetic justice... You decide.
Say the avaeage american eats 25 ice cream cones a yaer (one every other week). That's 6.25 billion a year. Now lets suppose that 25% of ice cream cone eaters are sloppy ice cream cone eaters, and create some sort of a mess.
Let's further suppose that it takes one minute to clean up the ice cream cone mess, and that costs about $15 per hour including benifits, suprivisors, etc.
That means the US loses 312 million per year due to ice cream cone messes! Surly we can reduce this cost with public awareness ads.
That's
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
I just lost 2 hours work to a spontaneously corrupting Adobe Pagemaker document. Everytime this happens, I add another Adobe employee to the list of those that will be lined up against the wall. So far, they're going to need to hire more people, because I'm going to F***ing strangle everyone in the company.
And, what, $59 billion in sloppy code is from Microsoft?
Statements like the above are very misleading. On most of the major projects I have worked with over the last five years, time to project launch was always the
number one consideration. In every case, I was ground relentlessly by senior management on a continuous basis about time-to-launch. If I stated that a project would take eight months to complete, the next question from senior management would be on ways to release the product in six months.
The following day, I would get grilled on how to release the product in five months, or maybe four months.
I experienced these same conditions while working for a number of different employers; when I pushed back on the release dates, a reason always appeared why our company would collapse in wreakage if the project were not released by the nearer deadline.
I and the programmers that I have worked with finished some projects on time; others we did not. We worked in deliberate languages (C, C++, Java) and RAD languages (Perl, Python). The specifics of the project changed, but the mentality of an uninformed management never changes.
I am very proud of what we achieved, bugs and all. I think that we did a hell of a job under very difficult circumstances.
The statement that software bugs cost American industry $60 Billion makes me laugh when I hear it. For the most part, the bugs are caused by management refusal
to spend the time and money it takes to write bug free software.
The overwhelming majority of bugs can be easily eliminated by good developers if the following elements are in place:
Good Functional Specifications
Explicit Coding Standards
Unit Testing of Code Modules
Peer Review
Sane Project Deadlines
There's not much else to it. That, and the desire to do good work will fix 90% of the so-called problem.
"Man is nothing without the works of man" -- Helvetius
Another man's trash is another man's treasure.
Why that's about one third the software companies losses due to pirates. No wonder we don't feel sorry for the big software companies.
Yeah right and that is why it took four years to launch Mozzila. I am sure it took four years and there were no buggy lines of code. Had to cost some good chuck of money.
I'm bothered that this article focused so much on testing, when the real solution lies so much further up the development "pipeline".
Testing is very important, but it really is of limited use when the software has chronic design problems. If the nature of the software lends itself to hack-n-patch type fixes that build up into a painful thicket of code, then no real progress is made through testing.
Testing is intended to shake out the last few bugs in a well-thought out system, and the users delight in using the final product....<wakes up>...oh, I must have dozed off there...where was I?...oh...<hack-hack-hack punch-punch compile damn-it! hack-hack...>
Healthcare article at Kuro5hin
What-ever. If we're going to issue over something, then let's talk about the short- and long-term ramifications of externalized costs due to industrial pollution, automobiles, environmental mismanagement, bad/corrupt urban planning, and similar factors that have been with us for far, far longer than the measly few decades software developers have been doing their worst. No matter how bad your office productivity suite is, it probably won't give you asthma or lung cancer.
One thing to consider (not the only one of course) is that anyone who's worked for a manufacturer/software company knows that a massive source of revenue is support. In fact some companies rely on those support dollars beyond what they're getting for new purchases. especially those products which are big ticket (e.g. Avid, Discrete Logic, Oracle, SAP) which cost over $100k+ to buy into and then %15 (or some percentage) of the cost per year for support. Just so you can get someone on the phone to explain that that's "known issue" and "we're working on that for the next release", etc. etc.
The problem is that the support model helps drive revenue and if a company made perfect code, poof, support dollars start to dissappear. Besides, most companies can't produce a marketing flyer that's error free, let alone made bug free code. Plus, when you build a complex app, how on earth can you imagine every possible user interaction that can go in to it? Given enough tries someone will figure out how to break it in some unimaginable way you never thought of because there's more of them using it and less of you testing it.
just my thoughts,
-s
This is just ridiculous. Software "enginering" doesn't exist ... it's just an idea in people's heads. Software right now is a craft. You have a bunch of skilled artisans (programmers) writing code, but the whole program is in their head, the people represent the software, and the quality of the code is directly a result of the quality of the programmer, and the managements ability to understand this process and keep the programmers going in the right direction and talking to each other.
... and I think my degree is good because I was exposed to some of the best software craftspersons. There's no rules and definitely no big black book of programming.
Only in the most ridiculous cases do people practise "software engineering" (like at NASA) because it's too hard the way they do it now (mathematical proofs).
And I speak as a software program manager and I have a good degree
Simon
home page
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.
(emphasis mine)
I'm sorry but I have to take exception to your tone. Simply skimming a news blurb does not give you the right to trash the NIST study or label their conclusions as "arbitrary." Until you've made an effort to digest whatever analysis is contained in the 309 page study (and there is a link to the PDF file so don't say you can't do so) you really shouldn't be shitting on someone else's work. I don't think I'm being harsh by taking you to task over this. That news bulletin is an advertisement of sorts for the study. You can't possibly expect to get a full understanding of their analysis from a news blurb, for chrissake.
I'm sorry but one of my pet peeves is armchair philosophers who seem to think that they can best the experts without actually doing any work.
GMD
watch this
Even if true, the amount is a pittance compared to the costs of bad management. Dotcoms and Enron anyone?
When the companies start slashing staff because the stock went down a couple of percent. The testers. It seems like the testing team is always the first to go.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
As a former quality assurance engineer, I assure you that a good portion of buggy code which makes it to the customer does so only because the product "must be released on time" so that profit$ can be posted in a specific quarter to meet expectations.
Give the developers and testers 3 more months, and version 1.0 will be 1.0, not 1.0 alpha. Sure, version 1.1 should could be good, if new features weren't also expected...
I've been paid a fair amount over the last few years to write sloppy code--I'm sure the number is a lot bigger than that...
Liberty uber alles.
To Statsdot maybe...
Funny enough, but the same article is on progress.org.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
The real problem is that most humans don't know what they're doing or why they're doing it half the time, and these studies simply point out some of the implications of that...
Cigarette smoking costs $10000000 a year
The war on drugs $2000000000 a year
NASA to crash things into Mars $300000000 a year
Who cares, shit costs money. It takes money to make money. Big deal.
How much is saved by using computers over typing everything on type writer and storing everything on sheets of paper and microfilm.
Sure better testing should be employed by a lot of software developers, but the market is really what drives this sort of thing.
Will someone pay $3000 a licence for this app because it was tested really good and is really solid or will they buy the not so well tested competitor's version of $1000 a licence?
If people want better software they are going to have to pay for it. Someone has to pay for testers and shit.
It's called capitalism.
Sloppy coding earns me approx. $31.75/hr!
**WARNING** Microsoft bashing!!
It has been brought up many times that having bug-free software is not in Microsoft's best interest. It's the bugs, subsequent versions of the same software and dropped support for old versions that keep the company raking in the dough.
I'm not sure I have to go into great detail to explain how that works, but clearly, there is a business model in the works here and not just sloppy coding.
What about the costs needed for better testing?
US Population: approx 0.25Bn
Cost of Windows XP: $200
Total cost: $50Bn
Yeah sounds about right
useless government studies cost $120 billion a year.
I can tell how this would go. If bugs cost us $60 billion a year, and better testing would result in one-third fewer bugs, who wants to bet that this extra testing would cost about $20 billion? :)
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
just another story with BS statistics. Where did the data come from, the national census? if not it's either highly extrapolated or just BS.
cool thanks for modding +5 Predictable
Generally a lack of standards or enforcement, though one of the great hazzards is idealistic inexperienced (or worse, experienced) people with grand visions of the perfect tool followed by shock, dismay, even anger when users fail to share the author's enthusiasm. Time lost on poor communication is added cost to projects/products.
Experience has taught me enough to ask what the user is actually going to do with it and see past just their "want", because what they need is often considerably different (and usually much simpler.)
I'll generally create prototypes to show users to get feedback on look, ergonomics, and usability. Early communication and feedback are essential to a smooth project and a good product. I'll never know all the answers, so giving users a shot early on saves us both of us headaches down the road. Few things are more painful to a coder than having to completely re-engineer an application when it's about 90% done.
This reminds me of so many times meeting with a user to discuss a few changes to an existing application, to find they don't even use it, or use it properly because it was dumped on them or never updated to follow their needs. At some point many just give up on asking for fixes and find another way, particularly when the IT channel has been unresponsive for a long time. Extra time doing work arounds, or cleaning up the mess of users doing short cuts probably doesn't figure into the study, but I've spent enough time and cycles trying to clean up or form links between messy data.
A feeling of having made the same mistake before: Deja Foobar
Everyone knows that today you need more Harddrive space than ever. That is a fact.
However, I think that alot of that harddrive space is wasted on sloppy coding. At one point, hard drive space was so expensive, that you couldn't afford to have sloppy and inefficnat programs. 8mb of memory was standard, you didn't have 512mb to mess with and leak to. Look at your OS even. Windows 95 fit onto 30mb or so. You could sqeeze it even more if you started deleting things that weren't needed (paint, wordpad, etc...)
Now, look at your WinME or WinXP install. I just did a clean install of XP Pro, and it's taking up 1,082,413,755 bytes (about a gig). Yea, that's a bit much.
Ok, I will give it to you, WinXP Pro has more features and functionality than 95, however is it 34x the features and functionality? Is my computer 34x better, or have 34x more applications and programs that I use? No!!!
I think that this code has been bloated to hell. At one point running DOS/Win3.1 and even NT 3.51, I knew what 90% of the files on my computer were, when they were put there, and what they were for. Now, who knows what 'adsmw.dll' does? (Ok, I know one of you guys probably know, but...)
Also, they haven't optimzed anything, or made anything faster. Win95 could run on a 486 great. WinXP choaks on a 300PII with 64mb. Again, we have gotten more features, but for a system to run smoothly do we need 10-20 times the processing power to make it run well? I think that's absurd. Again, we have came far, but dont' tell me that it couldn't be faster with current hardware.
Linux isn't free from this either. Again we have more features now, but look at the requirements of Redhat 5.2 to 7.3, they have gone up ALOT. And now its THREE CDS!!! That's even beating MSFT. We have alot of programs on linux, but come on, that's crazy. No you don't need all that stuff, but the size of the "Standard" install has gone up dramatically.
Now on to games. Let's take Ultima Online. I remember in the Alpha test and Beta test, a 486 DX/4 was more that enough. I ran it on a Pentium 90, it worked great. Now the system requirements are what? Pentium 233 with 64mb ram? It doesn't sound like much (the engine is pretty dated.), but they haven't gotten ANY new things in it that would have really increased processor usage. No new graphics in the 2d version, no sounds really, just bad programming.
Has anyone looked into the Demo Scene lately? I want them to program my OS and games for me!! They program stuff on 64k that most games can't do in 64MB!!!
I think that most of the time now, the programmers are seeing these fast 2.4ghz systems and thinking "Who needs to optimze their loops on a system that fast"? And "Let's use Long Doubles for everything, even if it's only a bool, more consistant that way..". I personally hope that they start seeing that they can run faster if they program better...
Tibbon
tibbon.com
The problem started when Engineer was no longer in charge of schedules, Marketing type were. Then things really bottomed out when Finance start setting schedules according to when they needed to have the revenue in the books. All this shorten QA schedules, then development schedules, then staff sizes. Put the necessary time back into schedules and software bugs will shrink.
Better testing could allegedly cut that by one-third Not likely. Testing of the software isnt that big of an issue. "Most" bugs that are found by customers are already present in the bug tracking databases of the people that developed the software. It's the will of the Product/Program managers to decide wether to spend the dev/qa time to fix the issues. Arent STM dates a bitch?
Look, I already said I'm sorry, and now that I know about off-by-one errors, I'll be more careful.
A.C.
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."
experts estimate that friction costs the economy $200 billion per year.
Comparing boob jobs to broken windows is different, one is a luxury item, something you don't need. And the other is a loss, someone caused you to buy something that you already have. Every house needs windows keep the heat in/out (esp. in places like Alaska), but nobody needs boob jobs to live (well maybe in extreme cases).
Does this number factor in at all the amount of money SAVED by using computers in the first place? Or is it just a measure of how much money we could be saving if software was 100% efficient.
Here's another funfact instead of a inflated $60 billion:
Unrealistic ideas and the opinion that computers could solve all problems cost the American people the entire freaking economy in the last two years.
This article it typical alarmist FUD. No mention of how much money is saved each year by coders.
This world of perfection exists only in the minds of the pencil pushers at NIST.
(emphasis mine)
So are you saying the article is shit or the 307 page NIST report is shit? Or both? Yeah, there's no mention of how much money is saved by coders. That's because that wasn't part of the NIST study. If you had bothered to even skim the NIST report (the PDF is just a click away) you would have read on page ES-2:
The objective of this study is to investigate the economic impact of an inadequate infrastructure for software testing in the U.S.
Note that the objective of the NIST report is not "Software: benefit or liability".
In the real world, coders sometimes make mistakes because they are...human.
Just because software developers are human doesn't mean that they should be blind or ignorant of the very real costs borne by society because good testing procedures have not been instituted at most companies. NIST isn't saying "coders are crap". They're simply pointing out that software bugs are a serious problem. And then they back it up with 300+ pages of analysis.
GMD
watch this
You've obviously never experienced the benifits of a $20,000 toilet seat.
http://www.nist.gov/public_affairs/budge t.htm
Because if you dont some yahoo newbie programmer will insist upon using [insert language learned at college here (java)] despite the fact that its less portable, poorly integratable, and terribly slow (for the specific requirement, say a device driver).
Contrary to popular belief, it is possible to write C++, and even C code, that does not contain memory leaks or buffer overflows, just a matter of programming practice and discipline, and not a matter of some compiler/or interpreter holding your hand.
billions every year.
... Surprize. Project X DOESN'T WORK! And its gonna cost three time as much to replace the crap code... And it still won't fuckin' work cause the next guy won't have known something else.
And do you know why they don't? Because ego gets mixed up in it.
NO mangager will ever admit that he doesn't know everything. They too scared.
NO PHB will ever admit that either. They too stupid.
End result
I own http://www.softwareprototypes.com
Mailing campaign. Hand-outs. Post-It pads. And NOT ONE CALL. NOT ONE EMAIL. NOT ONE. Its not like I'd even got a chance to fuck up. They weren't even interested.
I now own a dog grooming salon and the dipshits in the DP/MIS/IT world can all go fuck themselves.
That's another things. How long has the automobile industry called itself automobile industry? Since day dot.
In twenty-five years, my profession hasn't even figured out what the fuck to call itself. Toy makers, tyros and jack-offs.
I don't know wether to be angry or relieved that I've give up on the whole idiotic lot.
I lurk here to see what other loser stupidity they come up with.
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
How can they even think to come up with that figure of $59.5 billion??? If they had done their homework at all and studied the software company I work for, they would have to totally revise their numbers...
Up, of course.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
Come on now, thats just funny. It caters so well to the /. audience as well.
I Browse at +4 Flamebait
Open Source Sysadmin
2. The BSA tells us that piracy costs the idustry about 11 biliion.
As far as I can tell, the software industry owes us around 19 Billion in refunds.
Isn't playing with fake statistics wonderful?
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Yeah. And a better education system would cut the other two thirds. I believe that better programming practices would reduce the number of bugs installed to begin with, thus reducing the amount of testing that must take place.
Better programming begins with better design. The purpose of a program and its interface to the outside world (user, system, etc.) must be spelled out initially. Nothing that doesn't fall into the predefined limited functionality belongs in the program. Period.
I mean, you can make a bunch of programs if you need a bunch of functionalities and stuff, but you shouldn't have a ton of junk in the same program. If you know what I mean. I guess you don't, cuz I can see the flames coming.
The program would be well designed, meaning the basic flow of the program would be defined, and then any number of possible ideas and algorithms would be explored during design time. The program should be designed such that algorithms can be exchanged with as little fuss and trouble as possible. In other words, encapsulation and modularity. The design would require the highest level of efficiency possible, meaning that spacial and temporal resources aren't wasted. In English, that means that a text editor wouldn't require 128 megs of RAM and 6 gigs of hard disk space, and would use up as few processor cycles as necessary, by design. In other words, a totally unoptimized program would execute so efficiently that any optimization would practically be a waste of time. You'll find that programs designed for efficiency are generally more reliable as well, because more thought goes into them before any implementation takes place. Finally, robustness would be a pervasive part of development. Testing mechanisms would be built in to the programs, and by design, those mechanisms could be removed at compile time. I'm not talking about debug information generated by the compiler. I'm talking about tests the programmer, tester and "preview release" users can invoke. A testing suite would also be designed, at design time. Project management is also part of the design process... in other words, for each component of the system, what resources (folks, time, money, etc.) are required, what problems are anticipated, etc. All of this is done by the programming team, not by some stupid manager who doesn't know jack about schitt. Once a ton of design takes place, management reviews it. Which features will be present in which release, etc. As much of everything as possible is anticipated beforehand. (Yeah yeah, you'll never anticipate more than 0.0% of the problems beforehand, but it gets you thinking, and that in itself will reduce greatly the number of errors made later.) Management reviews the design, multiplies all time estimates (which are already over-estimated by the programmers) by 2.5, and sign it or whatever. They can't ask for any new features or whatever until the program is written, debugged, tested, released, feedback comes in, a "huge fixes" release is released, more feedback comes in, and it's time to figure out new features again. This could take weeks or months, depending on the scope of the project or whatever.
Once all that designing takes place, implementation begins. That doesn't mean that design ends. In fact, there's no 'design -> write -> compile -> debug -> fix -> write...' cycle. All of those items are done all the time, like you're multitasking or something. Yeah, you could draw out an operational chart showing all those items, so you'd spend most of your time doing whichever stage that you're on (like debugging most of the time, doing everything else some of the time). This is useful because you might be debugging some obscure problem, and then one of your fellow programmers will say, "Hey, who needs this damn routine in the first place?" (The routine you're debugging.) Maybe the design can change a little bit and then the section that contains that damn bug isn't even necessary. Know what I'm saying?
Also, when I spake of education, I was speaking about all the branches of logic, electronics, math, etc. that are no longer studied as part of the programming curriculum or whatever. I'm talking about heavy duty stuff that programmers need to know cold, because it's actually USEFUL! Seriously... learn a little bit about electronics and you'll be surprised at how a few hundred lines of code can literally be replaced by tens of much simpler lines that execute thousands of times faster (not kidding!) and produce exactly the same results, or better (meaning with less problems and side effects). Seriously... when you design electronics, there's no erasing that capacitor once its soldered on the damn board. You gotta draw it right because you can't erase the metal once its cut. And if programmers thought like this more, and didn't think "oh yeah, we can always change it later" then programs would be better. Because, as easy as it is to delete a bunch of text and change it, you and I both know that sometimes you can't change stuff because of side effects. So yeah, it's easy to type, but as a programmer, you gotta pretend that you're carving the damn program in stone, because you'll probably find that it is carved in stone once you've written about 100,000 lines.
So where was I? Oh yeah, programming... So while you're implementing, the design is reviewed often, perhaps every few days or once a week at least. Problems encountered during implementation are tested against the design, and changes to the design are almost invariably made, with a big eye towards reducing or eliminating coding changes.
Oh yeah, and all this is done by the programmers again. The team meets often to review each others work, ask questions, find errors of any kind, criticize, rip the code apart, put it back together, and stuff. This constant reviewing is similar to the peer reviews that used to take place back when compilers ran on mainframes, where folks paid hefty fees for computer time, and had to schedule an appointment weeks in advance. In fact, I'd advocate dropping a mohogany grand piano hood (or whatever that cover is called) on the programmer's hand who makes the most mistakes during a project. That'll teach him (and get him to type slower, possibly leading to more thought behind each character typed). In fact, I'd get rid of the backspace and delete keys on the keyboards, and make the programmers pay a penny for each character they want deleted, and this would have to be done by a specialist who can write machine code to go to that location on the hard disk and remove the character, moving all the others back by one. Some of us would have to give up our whole damn paycheck if that was implemented!
The core routines of the program, holding the most important crap, would probably be written by the whole damn team on a whiteboard, while questions are asked and shit. I don't care how long this takes, it'll save a ton of time in the end. Shit, some of all ya'lls will have to get a huge room with whiteboards all around and sliding ladders like they have in the old-school libraries. (Damn, dude, I love libraries.)
Once in a while, the programming team will actually take a break from the program they're working on (like every friday afternoon, a few hours before you get off work) and study a bit of Knuth or one of the other classics out there. (There are a bunch of them.) Most of those books contain exercises at the end of each chapter. Pick a tough one, and have it solved by noon on Monday. You can think about it all weekend, talk to each other, whatever. This will expand the whole team's range of thought, and cause them to produce better shit.
Oh yeah, and every line of the program would be run through a debugger, in as many combinations as practical, in order to watch what happens when they execute. All the programming do's and don't's learned over the past 50 years would be reviewed constantly, and the programmers would be required to follow all of these (using common sense, obviously).
And of course, testers would be hired who get paid a small bonus every time they get something to fail. They'll be present from the first day onwards, testing even the individual routines before the program runs as a whole. And once the program runs as a whole, they'll get paid even more for each failure. And they'll have full access to the source code, so they can audit it to their heart's content and figure out innovative new ways to crash it and twist it and make it screw up all evil and stuff.
When a program is ready for release, its release is delayed for an additional two weeks (or month, if you can afford it) as the entire damn team tries everything they can to make it screw up. (And yeah, they obviously fix every crappy thing they find. If all ya'll did it right up to this point, there won't be any changes requiring the damn design to change. Just little coding typos and crap.) Then, it's released as alpha-testing to a small group of folks. Then, once that passes, it's released as beta-testing in three phases to increasingly larger audiences. (Each of these testers gets paid a small amount for each bug they find for the first time.) Then, it's released to the final audience as version 1.0.
Now at this point, a ton of support calls will start coming in and stuff, and folks will get suggestions and stuff for wishlists. All this will be accumulated for a few months while the programming team visits each problem and tries to figure out possible solutions. No coding changes are made during this time. These will be explored in theory, with an eye towards killing as many flies as possible in one swat. After a shitload of stuff is accumulated, the programmers choose proposed solutions, go over them along with management, go over proposed solutions, and choose the best ones. The programmers choose the best ones, that is. Management signs it into law, and they can't change their minds. Only the programmers can, if it's important enough, then call a meeting with management again and get the new law signed into law. These are implemented (again, with the same torture-testing as before) and once again, released to increasingly larger audiences, until finally, it's released as a version 2.0. All even versions are "fix" versions. All odd versions are "new features" versions. They can be developed in parallel, with porting going on between versions. Something like that.
I'd even say, during design time, figure out how many bytes of code something will be, how many lines it'll be in the source code, how much memory and time it'll require, etc. Make up limitations, kind of like how car engineers have to make a throttle body fit in a certain place and fit certain restrictions. They get to play inside that area, but other stuff goes in the other places, so you can't make a throttle body the size of the whole damn car and expect the other crap to be changed to fit. Programmers constantly just write crap and assume it'll fit. If you invent restrictions, you'll be surprised how much better the code will be. It'll also be a challenge to make it fit into the restrictions you choose.
Also, here's something all ya'll programmers will like. When the design is reviewed by management, and you say, "Implementing this should take 4 days" (and "this" would be a sufficiently small part of the system that it stands alone and can be estimated, but large enough that it won't be a single line of code or a single routine or something silly like that). Management will say, "Ok. If you can get this part implemented and working properly (in other words, passing all the tester's tests) within 3 days, you'll get a bonus of X." X wouldn't be like 10,000 bucks, but it wouldn't be 2 cents either. It'll be a small amount that when added to the other bonuses you get for getting everything done on time, you'll have some real money. And, a final release date for the whole damn project is estimated by the programming team. This is multiplied by 2.5 by management, and that's their expected deadline. (Then, if it does get done in time, management claims to be "early" and then everyone looks good. Even if it takes twice as long to get done as anticipated. But if it takes two and a half times as long as anticipated, you're on time. And if it takes longer than that, you're only overdue by a very small amount. And if you're really overdue, you're stupid.) Now, if the program can get released within 90% of the originally estimated time (that is, not the 2.5 times more), then the whole damn team gets a hefty bonus. Just to make them think efficiently.
Ooooooooh well.
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.
Geez, another tax-financed study telling us how much is wasted on 'x' behavior in the free market.
Of course, we never see the government tell us how much money is wasted on government behaviors. 60 billion could be found in the couch cushions in the Pentagon.
-Donut
This is the exact comment I was going to post, but I did a text search on this page for "$20 billion" first, since I figgered somebody else would think of it.
Mod me redundant; I don't care. Parent post deserves (+5, Funny; +5, Insightful). That's economics near equilibrium. Do you think the software industry would be that dumb, if it were actually $60 billion in real losses?
IN TEH FUCHAR, LITERSY WLIL EB OPSHANAL!!!!!111
OK--please expound in simplistic terms for a non mathematician to understand.(if possible)*
thanks
*if the branez/trollz want more, offer that too, I guess, for me, simple works. I'm the customer, explain to me why your system will work better and why.
There was a time when American cars where the greatest car in the World, the same applied with consumer electronics products. There was a time when the paradigm said you can not combine price, quality and time to market.
Then there was Eduward Deming and its Quality Management, and something happend to american industry, after some other guys listened to his ideas.
And now a lot of people say that software can only be produced with bugs, with a lot of features, and costly.
Well there is a guy named Watts S. Humphrey and people on other parts of the world are hearing his ideas about software engineerning and CMM, there is no question that someone will find out how to make software less buggy, on time, and in price.
History will tell, remember that those who forget history are set to make the same mistakes.
It's a real shame that the problem usually starts with:
void main()
{
...
}
This number is completely out of context and nearly useless. To get any use at all from it, we need to AT LEAST know how much money that same software saved the users versus no software.
I also don't know why they say software is unusual in its quality. To even make the comparison, you'd have to build a mechanical equivalent to a million line program. I've seen pictures of simple mechanical processors, but none even close to the complexity of a modern program.
I don't know of any item manufactured that is perfectly bug free. Moreover, most of the bugs in mass produced hardware items are intentionally inserted (or knowingly not removed) by the manufacturers to limit the lifetime of the device.
Automobiles are especially notorious for this and cost way more than our home computers + all of there software. We've known how to build million mile brakes for little more than the cost of the
Let's hear some more about how many billions of dollars the "bugs" in the algorithm of applying the energy of combustion of gas to the rotation of the wheel is costing us.
Problem:C/C++ costs the economy an estimated 59.5 billion dollars a year.
Solution: Escalate the use of C/C++
I wonder where all that money goes?
Can be seen in NIST's own EMC Machine control software for Linux. What a hack. It took 30 minutes to get rid of things like #define AND2 && and #define ISEQUAL ==. Who the f would waste time writing such useless macros? And then some dude who had a clue wrote a note on the mail list telling how the algorithms they used where only used in the first expeirmental machines and were ineffecient and dangerous (yes, machine control of cutting blades spinning 6000 RPMs can be dangerous). Your tax dollars at work, writing the worst code, then explaining how it is costing the economy huge amounts of money. What a racket.
In other news, man hours devoted to extra "De Bugging" costs the economy 5x as much as the bugs do. Greater than 50% of this cost is carried by the developer, but thankfully is passed to the end consumer where it belongs.
if I didn't have such a buggy development environment.
type conversion rounding error in slashdot story causes $.5 billion in damages...
IBM had a mainframe program called IEFBR14, whose spec was 'do nothing'. It existed to allow the job control language to allocate files and so forth.
Over the years it had at least two fixes applied to it:
1. Make sure it issues a specific return code of 0.
2. Allow it to work in extended addressing mode, which was not taken into account in the original design.
The first was a spec omission, the second was an unanticipated change in environment.
Testing is incredibly expensive. Most large software projects spend 60-80% of the time on testing. The percentage is higher for more critical projects.
In my COBOL compiler project I spend most of my time writing and running tests. Writing code that doesn't work is fast and easy.
I don't believe it. Its always the code cruncher who gets the blame. How about bad design?
I've seen a horrible database and code which resulted from a bad design (moving target).
If we have a free market, we are saying we will put up with $60 billion in hassle to perhaps get $200 billion in benefit and skip spending $400 billion to engage in (by current methodology) low-defect software development.
Put another way, spelling and grammer errors in Slashdot postings are bugs, but there is a tradeof between time spent checking everything and reading the postings of wisenheimers complaining about one's syntax.
Sorry, Gregory Tassey's 309 page report does not say "software bugs are a serious problem". It says that "Inadequate Infrastructure for Software Testing" is the problem, implying that better testing is the answer.
I'm curious why he commissioned "The Economic Impacts of Inadequate Infrastructure for Software Testing".
I've just reviewed it. In spite of the title, the report really seems to be about "The Economic Impacts of Buggy Software."
There are three approaches to avoiding the costs associated with buggy software:
1. Don't use software.
2. Test it to get (most of) the bugs out.
3. Design and develop it in such a way as to minimize bugs.
This report seems to assume (and we know how sales people parse that word) that the problem is in the testing. Let me argue that the major problem is really in the design and development stages.
I know, because I've managed the design, development, testing and support of commercial software which was licensed to major firms with a MONEY BACK GUARANTEE, and we were never asked for a refund.
Yes, bugs were found in our software. Two of them. Each was fixed within 24 hours of being reported by users.
Morris Schneiderman
morris@intrex.net
Using better languages could reduce software bugginess dramatically, but only if programmers admit they have a problem.
Most developers overestimate the value of custom solutions to every problem. A language like C, with no built-in string type, no collections other than the most primitive array, no memory mgt above the finest-grained primitives, and so on, seduce programmers into working at too low a level of abstraction for most problems.
The nature of C is such that it is a good choice for the software equivalent of "innermost loop" code: small bits of code in constant use with crystal clear functional requirements that never change. The 1% of code that accounts for 95% of all CPU cycles should probably be written in C, massively code reviewed, tested exhaustively, and then left alone to do its well-defined and unchanging job.
Code of this sort should mostly be in the OS itself, or in libraries, although it's also appropriate in the "engine" portion at the heart of Big Apps, like database engines, spreadsheet recalc engines, text rendering engines, etc.
But programmers flatter themselves that everything they write is this type of code and use C for the other 99% for which it is ill-suited. Instead of working at a higher level, using built-in Unicode Strings, well-designed collections classes (where you simply can't write "outside the box"), automatic memory mgt., etc., they foolishly trade safety for speed, reliability for customizability, and so on.
It's so easy to trade safety for speed when you tell yourself that you're such a hotshot programmer that you don't overlook anything (hence no actual loss in safety) and your code is so important that an increase in performance is a Big Deal (probably undetectable to the end user.)
C is the perfect tool for programmers who think this way and a major reason for the general bugginess of software. It's an excellent choice for a small percentage of code and the biggest cause of bugs in the rest.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Of coure we have sloppy coding. We have poor programmers for the same reason we have poor teachers, poor doctors, poor lawyers, poor businessmen. People who are only in it for the money.(teachers may be a bad example) They have no talent for the field, they just do it for the money.
I agree any figure is probably as good as any other when trying to quantify this. Of course, my experience has also taught me that this guess is woefully low.... I'd say 2x or 3x (more wasted time/money) at least...
which aren't asking the right questions?
// The fastest Alt-Tab in the West
Improvements in testing could reduce this cost by about a third, or $22.5 billion, but it won't eliminate all software errors, the study said. Of the total $59.5 billion cost, users incurred 64% of the cost and developers 36%.
This is a load of Hogwash!
Testing can only prove whether or not the code was well written. You cannot fix badly written code by testing it. The most you can do with testing is delay it's introduction into the wild.
Testing is NOT part of the design or development process, which is where bugs are actually created.
Defects found during testing take far longer to find and fix than code audits and walkthroughs take. If you are doing a code audit or walkthrough and you see a bug, you are already at the spot to fix it. If you find a bug during testing, it might take days to determine where the cause is, if ever.
If you want decent code, write decent specs and allow the programmers time to hit a well thought out and non-moving target.
We should start referring to processes which run in the background by their correct technical name... paenguins.
If should a study shows a major impact on general welfare, then the government needs to evaluate which policies are at its disposal to tackle the problem.
Simple as that - the robustness, assumptions etc of the actual study are secondary issues.
This is wonderful for us unemployed programmers! All we need to do is get jobs writing in Sloppy! Does O'Reily have a book on Sloppy? Where are the Teach yourself Sloppy in 30 days books?
...darn, didn't think so...
Does anyone here write Sloppy Code?
Dear Slashdot, I'm a new college graduate trying to get a job making Sloppy Code can you help me?
[signature]
In sales cycles, bugs are not an issue, features are.
;-)
So your compatitors will win if they release more features including more bugs, it's as simple as that.
Besides this, more bugs -> more support -> more money.
The world isn't perfect
I'm very impressed with the work of the kernel developers, but when I first joined the linux-kernel mailing list to resolve a bug when I started testing the 2.3 kernels a few months before 2.4 shipped, I found the process of reporting a bug and making sure it got fixed quite intimidating. I think it takes more intestinal fortitude than most people who might otherwise want to help the developers are likely to have.
That's why I started The Linux Quality Database.
My original concept was to provide a powerful bug database to enable end users to conveniently file more useful and informative bug reports, combined with sophisticated search facilities to aid the kernel developers in looking up bug reports.
For example, one might be able to search by the values of kernel .config file entries as well as hardware that is or isn't present in the user's system. This isn't something you can do with bugzilla, although possibly it could be extended to do so.
Unfortunately the dot-com crash happened and I had to bust my ass just to survive so I haven't got anywhere with the bug database yet.
But I also had the idea of using the site to educate other programmers, testers and users about how they can improve the quality of all Free Software, not just the kernel. So I started writing articles on various topics as they occured to me and posting them in the articles section. All my articles are under the GNU Free Documentation license. The Open Source Development Lab mirrors a couple of them and I'm quite stoked to report has made Japanese translations.
I invite others to contribute articles or advice, and of course since the articles are under the GFDL you are welcome to republish them elsewhere or include them in distributions of Linux or other software.
The articles available so far are:
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
-
Use Validators and Load Generators to Test Your Web Applications
-
Pointers to C++ Member Functions
That last one was posted just night before last, and while it may seem a little off-topic, member function pointers provided a neat and simple solution to a severe performance problem I was having recently. The KDE, AbiWord and Mozilla folks would likely find it helpful. It's not quite finished yet though.I think it's important to take personal responsibility for improving software quality. Rather than griping about Microsoft, your managers or your coworkers, strive to write better code yourself, educate your coworkers (for example by writing articles like I do), and stand up for yourself when the management attempts to bully you into writing bad code.
Don't just try hard. That's like pushing against a stone wall. Learn better practices, and also reflect upon past experiences in your own work and that of others to understand what works well and what doesn't.
In the last couple of years I have found that adopting unit testing and automated functional testing, as well as frequent use of assertions has enormously improved the quality of my own work.
They have also improved my productivity and made my experience of developing it much more pleasant. It's also impressed my clients because my code works so much better than that developed by their own programmers in house, so that despite their urgency to get code into production yesterday, they have been very supportive of my automated testing strategy and my high personal standards for quality - and they are starting to adopt some of what I do into their own process.
The best book I have found for teaching automated testing is John Lakos' Large Scale C++ Software Design. While much of it is of course C++ specific, the majority of it applies to any language.
One important thing to understand is that programs that have a rat's nest of dependencies between modules are difficult if not impossible to unit test - Lakos details methods to quantify, understand and manage dependencies within a program, not only to aid testing, but to enable module reuse (so modules can be used in other programs without dragging everything else along), aiding comprehension by developers and speeding build times.
-- Could you use my software consulting serv
Better testing could allegedly cut that by one-third.
Better testing might find a few more bugs, but it would have been better to have prevented them in the first place. True, code coverage tests and automatic testing catch a few bugs that can not easily be caught in other ways.
However we can do much more. Code reading finds twice as many bugs per hour as testing (see 'Rapid Development', MS-press). But this still relies on 'the human factor'. If we are ever going to create bug-free systems, we are going to have to reduce 'the human factor' further.
Better development tools can help prevent bugs too: visual tools help reducing the amount of code we need to write. Garbage collection can prevent memory leak problems. Folding editors can give better overview.
It could help to have development tools that force the programmer into good habits rather than depending on their discipline. Even a high level language like Java still happily allows the programmer not to check function return values. I'm generally not a fan of functional programming languages, but they did seem to get that part right. Although it could be annoying at first to be forced into good habits, it would soon become second nature. Ever forgot to declare a variable in a strongly typed language such as Pascal or C++? You get the point.
All things taken in consideration, there's nothing that helps prevent bugs like having a solid, complete design before programming starts. Unfortunately in the real world we have to deal with changing needs. Our current generation of development tools doesn't anticipate that our systems will change a lot. When it comes to changing the structure of our application, we are pretty much on our own.
Finally, even with perfect tools it will be a challenge to create perfect systems. Clients have a tendency not to tell what they want, but to tell how they want things done (and not really knowing what they want). As a parallel, at the doctor they would tell 'I want you to give me an aspirine' rather than telling 'I want you to cure my headache', disregarding the cause of their headache. It's not always easy to tell the client that he really needs to have a tumor removed that another doctor put in.
Visit http://ringbreak.dnd.utwente.nl/~mrjb/growingbettersoftware to download your free copy of the book
Film at 11.
Top 10 Reasons to Upgrade to Visual Basic NETMicrosoft Visual Basic NET included in Microsoft Visual Studio NET Professional Enterprise Developer and Enterprise Architect editions is the latest version of Visual Basic built specifically for existing Visual Basic developers who want to get the most out of the software development experienceIn addition to more power productivity and application stability Visual Basic NET provides key enhancements that solve the most pressing challenges that Visual Basic developers face today From the new integrated development environment IDE to a modern streamlined Visual Basic language Visual Basic NET delivers the top requested features built for todays Visual Basic developerNumber 1Seamless DeploymentVisual Basic NET solves the most pressing issues around Windowsbased application deployment and makes DLL Hell and component versioning issues a thing of the past New XCOPY deployment enables developers to install a Windowsbased application simply by copying files to a directory With Visual Basic NET and new autodownload deployment Windowsbased applications can be installed and executed simply by pointing a Web browser to a URLNumber 2More Robust CodeVisual Basic NET delivers the feature most requested by existing Visual Basic developersfewer bugs in the code they write Features in the new Visual Studio NET IDE such as the realtime background compiler and the task list keep Visual Basic developers uptodate on any coding errors as they occur enabling quick and effective error resolution Enhancements to the Visual Basic language such as strict type checking and structured exception handling enable developers to write code that is more robust maintainable and less prone to runtime errorsNumber 3Powerful Windowsbased ApplicationsVisual Basic NET is the most productive tool for constructing powerful Microsoft Windowsbased applications The new Windows Forms Designer enables developers to get their desktop applications to market in less time New features include control anchoring and docking to eliminate the need for complex resize code the inplace menu editor to deliver WYSIWYG menu creation and the tab order editor to provide rapid application development RAD organization of controlsNumber 4Powerful Flexible Data AccessVisual Basic NET provides developers with both the ActiveX Data Objects ADO data access programming model that they know and love plus the new XMLbased Microsoft ADONET With ADONET developers gain access to more powerful components such as the DataSet control and a new strongly typed programming model that provides Microsoft IntelliSense statement completion within data access codeNumber 5Simplified Component CreationVisual Basic NET brings RAD to component development Developers can use nonvisual toolbox and server explorer components to easily incorporate resources such as message queues event logs and performance counters into their applications without writing a single line of codeNumber 6Enhanced Control CreationVisual Basic NET provides unprecedented flexibility in building customized user controls Developers can easily extend preexisting user controls and Windows Forms controls as well as design their own controls that generate custom user interfacesNumber 7Complete Direct Access to the PlatformVisual Basic NET provides complete direct access to the Microsoft NET Framework enabling Visual Basic developers to quickly access the registry event log performance counters and file system Visual Basic NET also eliminates the need for declares statements for access to the operating system In addition the new Windows service project template enables rapid application development of real Microsoft Windows NT ServicesNumber 8Integrated Reporting with Crystal ReportsUpgrading to Visual Studio NET Professional Edition or later provides Visual Basic developers with the power of Crystal Reports directly within the IDE Crystal Reports delivers the most productive integrated and RAD experience for creating highly graphical and interactive relational data reports These reports can be generated for the entire array of Visual Basic NET application types including Windows Web and mobile applicationsNumber 9Easy Webbased Application DevelopmentVisual Basic NET delivers Visual Basic for the Web Using new Web Forms you can easily build true thinclient Webbased applications that intelligently render on any browser and on any platform Web Forms deliver the RAD programming experience of Microsoft Visual Basic 60 forms with the full power of Visual Basic NET rather than limited scripting capacity The new HTML designer delivers IntelliSense statement completion for HTML tags and the separation of user interface UI and code enable more efficient teambased developmentNumber 10Existing Investments Carry ForwardVisual Basic NET enables developers to leverage their existing investments in code and skills Windows Forms provides a robust container for Microsoft ActiveX controls Component Object Model COM Interoperability provides bidirectional communication between existing Visual Basic applications and those written with Visual Basic NET The upgrade wizard enables developers to seamlessly migrate up to 95 percent of existing code to Visual Basic NETPut these top 10 features to work in the applications you are building today with Visual Studio NET and Visual Basic NET
-pwpbot
The only language I can think of that meets the requirments of, well defined strings, automatic memory management, and well-designed collection classes is Fortran 77.
I guess we should also switch back to Tektronics 4010 terminals to get rid of problems with video glitches, and regress back to DOS since there is no blue screen of death.
Anyway, the main advantage to writing in C, C++, or any other programing lanuguage with Powerful memory management and well developed libraries is that you don't have to use the basic functions. You can use "safe" functions from well known libraries or make calls to routines written in other languages. I'ld say that crappy programming is 50%, and the other 50% is a lack of Quality Assesment.
Galium Arsenide is the material of the future, and always will be.
There have been problems on Intel and AMD processors traced back to faulty microcode though.
--
Can't buy what I want because it's free.
How much does sloppy construction practices cost? How much does sloppy auto repair cost? Sloppy housekeeping? Sloppy dry cleaning? Sloppy food preparation? Sloppy medical service?
What about sloppy bookkeeping and auditing at major firms in the US?
Why has somene singled out the computer business for assessing the cost of shoddy work?
- Sig this!
BTW, the report seems interesting. I've just downloaded it. It seems that it's got /.'ted (this reassures me that most /. are checking facts before replying...)
Of course, this leads to the dreaded "Microsoft is entering the market!" syndrome.
Read the EFF's Fair Use FAQ
To be blatantly honest, I'm just repeating a statistic I can't cite the source because I've forgotten where I heard it. Surviving isn't all about the plane not crash landing. It's about living after you get out of the plane. There is an incredible engineering that could go into creating a "seat" that if a human was in it and hit the ground at 400MPH the would survive. If the black box can survive, more then likely a human can too. It just isn't cost effective to do that for 180 people on the plane.
I'm not saying testing is a bad idea, but testing has a cost. How does the cost of testing compare to the cost of not testing?
yup, 59,999,999,999.99$ is my fault. As for the other penny? I have no idea.
between the greater and lesser infinities sleep the dreams undreamt
...I don't care how well constructed the report is when it's premise is fundamentally flawed to begin with. What are they trying to accomplish by pointing out how much defective software costs us? Why *didn't* they point out the opportunity cost of not having the software in the first place? Why is no one able to state how much *benefit* there is in having that software, defective or not?
If you could weigh the benefits of the software against the costs of defects, development, etc. you might actually have something useful. For all I know, that may be what NIST intends, but somehow I doubt it.
Armchair philosophers are a researcher's best friend in finding out the questions that matter. NIST should have consulted a few before embarking upon a study which is essentially worthless to the industry or the general populace. (Note that such a report is good stuff for consultants who want to place QA resources. Hmmmm...)
Please mod this post only if you think others should/n't read this. I have enough ego^H^H^Hkarma. Thanks!
Dunno if it's because of the industries I've been working in (first a big document management system, then semiconductor CAD), but I have rarely seen where software prototypes have been very useful on a large scale. As long as your requirements fit _exactly_ what the prototype was built to handle, then you can use it - but the moment your problem space includes something that wasn't taken into account when the prototype was designed, in my experience the resultant system is often twice as complicated & hard-to-maintain as something which was built custom for that application.
On the other hand, I've found the "component" concept extremely useful & productive. I love small components with well-defined, well-behaved functionality.
The "broken window fallacy" is a fallacious argument, which goes something like this:
"Hurricane Andrew blew through here and created millions of dollars of business fixing broken windows. Why don't we break windows all the time to stimulate the economy, instead of waiting for a random act of Nature?"
The resolution of the fallacy is that we have used economic resources (the materials and labor of window-makers and window-replacers) to restore the status quo, when those same resources could have been used to make new windows, leaving us with more than we had before.
In the case of World War II, what "cured" the Depression was the increase in government spending, employing formerly idle labor to build tanks and ammunition, etc. That is a real increase in economic activity vs. people standing in bread lines, wasting their potentially productive labor. However, we could have alternatively used that labor to build automobiles, office buildings, modern sewer systems, power plants, or anything else, instead of blowing things up in Europe and Asia.
The stimulus to the U.S. economy would have been similar, but Germany and Japan would have been better off as well. Net gain to the world. [This is neglecting the economic losses caused by the system of wartime rationing, which were substantial.]
Of course, Germany and Japan had to be stopped, and the destruction of their homelands and conquered territories was the only practical way of doing so. That's a tragedy, though, not a happy ending.