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."
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.
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.
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.
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.
Employees. No, really. You get paid for the time wasted using buggy software. The money from your salary ends up in your pocket either way. It's profit for you. That number isn't the true cost anyway. Everybody knows that in a given week we only do about 15 minutes of actual work. :) It's likely that the software bugs are interrupting officeplace recreation at least 75% of the time.
Instead of putting out a 300 page study on this crap, they should go do something useful. Put the same type of number on what speed traps cost the US economy, perhaps. Or stay home and stop charging us for rediculously obvious data.
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?"
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.
Comment removed based on user account deletion
But what choice do they have? You can't buy the older, more stable versions of ANYTHING anymore. As soon as the "New! Improved! Now Shaves Your Cat!" version of QuickPr0n Plus hits the shelves, the older, patched, and reasonably stabalized version of QuickPr0n Plus has been yanked and is no longer for sale.
How many people who got computers with WinME on them really wanted ME and hiow many simply had no choice?
This even holds true with Linux and other Oopen Source/Free software. Many times only the newest versions are available without hunting high and low for a forgotten mirror that has last year's model on it.
Boobies never hurt anyone. - Sherry Glaser.
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....
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
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
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?
So, the money went from the economy, to the...
To....
You see this kind of headline everywhere!
Well all I know is some of it went to me, because I either help people with buggy software, or help them with its alternative that would never have caught on unless the first stuff was crap.
I think crappy software generates $60 billion a year in business.
If computers worked, I would starve.
Comment removed based on user account deletion
Comment removed based on user account deletion
Some of it may be in terms of lost productivity (e.g. lost work when a program crashes, stuff like that).
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
He was worth over a hundred bil back when the stock market was flying high with dotcom hysteria...
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
Hey, so long as they dont turn a profit on that waste, waste away.
People with faults are tolerable, so long as they arnt getting richer off me while they are doing it.
"Old man yells at systemd"
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
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.
So you don't think Open Source code can be sloppy? You've never looked at the gcc sources, for example. Ugh.
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.
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
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
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.
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
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?
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.
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...
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.
US Population: approx 0.25Bn
Cost of Windows XP: $200
Total cost: $50Bn
Yeah sounds about right
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
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
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.
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
Not necessarily true. The most recent startup I worked for (and got laid off from) had a policy of "ship it at soon as it has a heartbeat, and we'll clean it up during customization."
Get this: 18 developers, one QA person. 6 months development, 3 weeks QA. Some stuff didn't even make it into QA. Yes, I opposed that schedule and spoke out against it but was overruled by The Man.
So, perhaps it's not "more testing" that's required, but rather "more integrity" on the part of management of software companies. I think we all know the valuation games executives play these days, often sacrificing quality or glossing over deficiencies.
He looked at me and said, "Kid, we don't like your kind, and we're gonna send your fingerprints off to Washington."
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.
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.
The money doesn't end up in our pocket actually. Nuf nuf employers expect you work 10 hour days to deliver "on time, on budget". Just look as all the people who post on here bragging that they aren't paid by the hour, but rather "to do a job".
In the case of those employees, there is no cost then, right?
Most employees are laborors, and punch a clock every morning to be paid hourly.
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."
OK, the bugs cost 60 billion in whatever kind of disruption. What would it cost to produce software without bugs?
You can't produce software without bugs. But how much would it cost to fix say one third of the bugs?
If we have a free market
We don't have a free market. The copyright holder has a government granted monopoly on fixing bugs in the software.
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.
Actually, according to Taco, that's a feature.
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.
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]
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
Naw, this comes from the same people who estimate the cost of hacker break-ins. You know, the ones who decide that since someone accessed an electronic copy of a $25 book, it cost the company $6 million.
Of course, this leads to the dreaded "Microsoft is entering the market!" syndrome.
Read the EFF's Fair Use FAQ
...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.