Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Bug

NIST Estimates Sloppy Coding Costs $60 Billion/Year 340

Posted by timothy from the numerical-imperative dept.
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."
This discussion has been archived. No new comments can be posted.

NIST Estimates Sloppy Coding Costs $60 Billion/Year More

NIST Estimates Sloppy Coding Costs $60 Billion/Year

Comments Filter:

  • Obvious joke (Score:5, Funny)

    by Violet Null ( 452694 ) on Tuesday June 25, 2002 @04:32PM (#3765239)
    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...

  • Costing the U.S. economy? (Score:3, Interesting)

    by anthony_dipierro ( 543308 ) on Tuesday June 25, 2002 @04:32PM (#3765241) Journal
    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.
    • Some of what you're saying is true. However, not even half of the $60B is going towards fixing it. You have realize that the figure we're looking at likely includes the cost of lost productivity for the poor sole who found the bug, and now has to re-type their entire report, re-enter their entire manufacturing design, etc..

      • You have realize that the figure we're looking at likely includes the cost of lost productivity for the poor sole who found the bug, and now has to re-type their entire report, re-enter their entire manufacturing design, etc..

        As opposed to sitting at his/her desk doing nothing? I'm not so sure that should be counted as a loss. Or would s/he be doing something else, in which case someone new has to fill in, causing increased employment and ultimately increasing the economy tenfold when you consider the trickle-down effect.


    • Fixing mailbox bugs in Outlook alone cover my car payments.

    • Re:Costing the U.S. economy? (Score:5, Insightful)

      by ryants ( 310088 ) on Tuesday June 25, 2002 @04:43PM (#3765337)
      This is called the broken window fallacy [progress.org].

      Money payed to programmers to fix bugs is money that isn't being used more productively somewhere else.

      Ce qu'on voit et ce qu'on ne voit pas

    • "So actually software bugs increase the GDP by $59.5 billion each year."

      Why stop with software? Why not require every worker to do every task over two or three times? Just think what _that_ would do for the economy!
    • Wouldn't bugs tend to increase the U.S. economy? Yes, someone has to pay, but that means someone is getting paid.

      Well, sure, in the same sence that cleaning up after preventable forest fires and industrial accidents `increase the economy'. Stuff gets paid for; money flows.

      The difference is that this money is spent to no productive end. In the case of buggy software, people are being paid to wait for their computers to reboot or to repair trashed database tables when their salary could have been paying for them to do stuff which is productive in itself -- helping their buisness produce more widgets, which consumers would buy, or other buisnesses would buy to help *them* produce gizmos. Thus, there's a net loss to the economy.

      • The difference is that this money is spent to no productive end.

        I wonder how many billion slashdot costs the economy, then :).

        I dunno, it's just playing games with numbers as far as I'm concerned. We could easily have a 10 hour work week if we stopped spending time working to no productive end. But of course our competitive nature would make that into 75% unemployment instead.

  • 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.

  • Microsoft is posting a $59.5 billion increase in revenue for last year.

  • Duh (Score:2, Insightful)

    by Dr. Bent ( 533421 )
    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.

    • Re: (Score:3, Insightful)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
    • Umm... time to market makes a big difference. If you get a project and don't have enough time to do it then yes quality will suffer. This is true in any industry. I realize there is a shared fault with some programmers and some managers, but not all programmers nor all managers.

      JOhn
    • I hope you're not serious. If I sold my software on a console like a game system that could not be modified or have anything else plugged into it then maybe I'd be more liable if the thing crashed. But I'd also have a warranty period just like car manufacturers do. They know how long their materials are going to last and make sure that they guarantee them for less than that.

      Besides, software is not physical, it really doesn't "exist". There is no guarantee that those bits will be interpretted in the exact same way and order every single time.
    • Otherwise there is simply no economic incentive to hire competent programmers and do rigourous testing.

      Unless you've illegally established a monopoly, hiring competent programmers and doing rigorous testing is absolutely essential to the completion of a software project within reasonable time and having it become an economical success. Good software doesn't write itself. Period.
    • . Otherwise there is simply no economic incentive to hire competent programmers and do rigourous testing.

      Yeah, other than the fact that if your code is a bug ridden piece of crap no one will buy it.

    • This is not going to change until software companies become liable for damages when their software fails.

      At which point there will be no more software bugs, because there will be no more software.

      Otherwise there is simply no economic incentive to hire competent programmers and do rigourous testing.

      What about competitive advantage?

    • Before you go and suggest companies be liable when software fails think about how that would impact the availability free software.

      Microsoft isn't the only entity that produces non-defect free code.

  • Not just "sloppy coding" (Score:5, Insightful)

    by shoppa ( 464619 ) on Tuesday June 25, 2002 @04:36PM (#3765270)
    If anyone believes that the greatest costs are due to "sloppy coding", they're wrong.

    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:

    1. Poor requirements specification (e.g. specifying the platform and/or the language in the requirements - a big mistake, especially when the language they specify results in code riddled with buffer overflows)
    2. Poor requirements confirmation (e.g. Everything anyone asked for goes into the requirements with no review at all to determine if it's needed, technically possible, or self-contradictory)

    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.

    • This is why software, by law, should explode like an atom bomb when a sigfault occurrs. ;)

      .. if we were developing bridges, etc, you'd see alot more caution and listening on the part of management and achitects (nevermind that for *some* reason, more managers in the engineering biz are .. gasp, actually engineers!) if there were physical costs to buggy software, rather than (mostly) economic costs.

      Anyhow, I'm glibly musing, but for the record, I totally agree with you.

    • Always blame the low man on the totem pole. Managers could not possibly be responsible for a poorly-defined project that is shipped behind schedule. CYA, fellow coders!
    • I agree, but it's more than just requirements. It's unreasonable schedules, a lack- in many cases- of release management or even version control, and a consumer environment that allows, even encourages, software companies to focus on new features instead of getting the features they already have to work right.
    • If one adds up the cost incurred by employees who do unnecessary work that could be done more efficiently, managers who assign unnecessary or counterproductive work because they don't truly understand what they're trying to achieve, etc., it would easily come to ten times the quoted figure.

      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...

    • 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."


    • 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.

    • 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.
  • 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.

  • Ohh say 1/3... (Score:3, Insightful)

    by delphin42 ( 556929 ) on Tuesday June 25, 2002 @04:37PM (#3765279) Homepage
    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.

  • Missing figure? (Score:3, Interesting)

    by scott1853 ( 194884 ) on Tuesday June 25, 2002 @04:37PM (#3765282)
    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.
    • 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.
      • 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.

        Yes, but what if the cost of fixing the bug is more, even in agregate than the cost lost to it? Then having the bug is a net savings to the economy over fixing it. People don't want bug free software, if they did every project would look like a NASA software development project, and even those have errors!
      • Well, unless a software package specifically declares it will save you 2 hours per day without any fine print at the bottom saying the user must know how to use the software then it can't really be a cost.

        If you buy a system and find out the first week it takes 2 hours less to do payroll than it used to, and you expect that figure to remain constant that's fairly unrealistic. Software is really a tool in the business sense. A carpenter wouldn't expect a hammer to last forever. So businesses should expect some downtime for tool maintenance. They do so with servers. Just because the bits and bytes don't change within the EXE file doesn't mean the bits and bytes in RAM remain constant.

    • Maybe that's because you skimmed it (Score:5, Insightful)

      by GuyMannDude ( 574364 ) on Tuesday June 25, 2002 @05:25PM (#3765600) Journal

      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

    • Hmmmm, almost every study I've seen shows that doing things right (proper requirements, design, testing, etc.) actually saves time. It's certainly been my own experience that projects following a good methodology have been cheaper than projects that didn't, interestingly enough the projects that didn't follow a methodology were always initially estimated to be inexpensive.

      How many fewer versions of Office and Windows would there be if Microsoft was designing their software for reliability and usability instead finding a way to hack the browser into the OS to screw Netscape or modifying libraries to cause Lotus 123 and Wordperfect to misfunction? And would developing those versions be cheaper or more expensive?

  • So let me get this straight (Score:3, Insightful)

    by b0z ( 191086 ) on Tuesday June 25, 2002 @04:39PM (#3765296) Homepage Journal
    When presidents of companies that have ties to most of the politicians in the federal government horde money and rip off the people that work for them, costing billions, it's look at as an unfortunate mistake.



    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.

  • OMG (Score:5, Insightful)

    by Zen Mastuh ( 456254 ) on Tuesday June 25, 2002 @04:39PM (#3765299)

    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.

    • Wow. They have said the same thing about illegal drug usage and goofing off at work.

      I'd love to see all these amounts totalled up. I wonder if it would be greater than the GNP of the place the "statistics" are reputed to apply to.

      --
      Evan

    • Re:OMG (Score:2)

      by Spyky ( 58290 )
      shouting "You with the undocumented line of code! Hands off the KB or I shoot!"
      ...
      This world of perfection exists only in the minds of the pencil pushers at NIST

      I am currently working with some public code released by NIST. Very humourosly every line of code is commented. So at least they aren't hypocrites :-)

      Spyky

    • Hands off the KB!

      that's awesome

      -l

    • Who are you trashing? (Score:4, Informative)

      by GuyMannDude ( 574364 ) on Tuesday June 25, 2002 @06:05PM (#3765783) Journal

      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

  • Unfairly harsh (Score:5, Insightful)

    by mactari ( 220786 ) <rufwork AT gmail DOT com> on Tuesday June 25, 2002 @04:40PM (#3765314) Homepage
    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.
    • The automotive analogy is pretty good, as aside from software it is the only complex system that most people interact with day in and day out. It is however still flawed, in that a car, even with its thousands of parts is still orders of magnitude simpler than anything but DOS.
  • That's why I support linux -- where sloppy coding is free (and Free).
  • While NIST may claim that sloppy coding costs the economy $59.5 billion per year, Microsoft would contend that its "innovative" code boosts its profits by $50 billion each year (the other $9.5 billion goes in the cookie jar).

    I would argue that most of that $50 billion goes back into the economy in the form of MS employee grocery bills, corporate jet purchases and Xbox advertising. There's really nothing unusual about this -- Microsoft just happens to be better than everyone else at getting people to pay them exorbitant amounts of money on a regular basis.

  • Not real money (Score:2, Insightful)

    by moorg ( 537751 )
    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*

    • Re:Not real money (Score:2, Insightful)

      by T3chnomonk ( 301162 )
      Amen brother. Most programmers would produce good code given a set of requirements that don't change daily and given a reasonable amount of time to complete the given task.

      I place much of the blame on the management level individual that is supposed to direct and management development - this individual is the interface to the rest of the company and its his/her responsiblity to inform and educate his peers and superiors.

      Developers implementing insanity can't help but let a little chaos loose.

  • I wonder if its just a coincidence that sloppy coding costs 60B/yr and MS total revenue fora year is the same figure....

  • Just wait for the followups (Score:3, Interesting)

    by drew_kime ( 303965 ) on Tuesday June 25, 2002 @04:46PM (#3765359) Journal
    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.

  • OTOH (Score:2, Funny)

    by Lucas Membrane ( 524640 )
    Other costs that America finds affordable:

    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

  • Offset Piracy? (Score:5, Funny)

    by cloudscout ( 104011 ) on Tuesday June 25, 2002 @04:51PM (#3765397) Homepage
    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?

    • Sloppy code costs $60 billion a year. Viruses cost billions a year. Piracy costs billions (and hundreds of thousands of jobs) a year. Unauthorized loafing (i.e. surfing the web and photocopying your butt) costs billions a year. Lost productivity due to slashdot reading/posting costs billions a year.

      I've always been curious: Who pays these costs, and even more important... how do I get to be one of the ones collecting all these billions every year?

  • Costs the Economy??? (Score:2, Interesting)

    by rMortyH ( 40227 )
    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.

  • "Sloppy code" vs. market realities (Score:4, Informative)

    by Infonaut ( 96956 ) <infonaut@gmail.com> on Tuesday June 25, 2002 @05:01PM (#3765460) Homepage Journal
    It's rather obvious that the dominant paradigm in software development today is that of Microsoft. Their mantra has always been:

    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 [amazon.com]. 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?

    • Re:"Sloppy code" vs. market realities (Score:5, Informative)

      by Katravax ( 21568 ) on Tuesday June 25, 2002 @06:45PM (#3765947)

      Their mantra has always been:
      1) Get to market first, at all costs
      You're kidding, right? Did you just get into computers a year or two ago or something? Microsoft is hardly a first-to-market company:
      NT? (OS/2 and Netware)
      Word? (WordPerfect and Wordstar)
      Excel? (Lotus 1,2,3)
      FrontPage? (bought it from Vermeer, or bought Vermeer, I forget)
      IE? (used pd code in first few revs)
      PowerPoint? (Harvard Graphics)
      Access? (wrote some, bought some)

      For just about every MS product you can think of, they were second or third to market, not first. They have no need to be first to market.

      2) Continue to add features, based on customer feedback
      MS roadmaps out massive feature lists in advance, and implements and releases in cycles. It's not like they wait to see what customers are going to ask for. I attended a MS hoo-rah prior to the release of Office 95. Many of the features they listed like voice control and mapping, weren't included until much later releases. I'm not saying they don't implement based on customer feedback, but it's not like they don't think something through before an initial release.

      3) When the product gets good enough (after 4 or 5 major revisions) tout its reliability and stability
      No argument here. You're absolutely wrong on your first point, though.

  • As a game developer... (Score:5, Funny)

    by Dixie_Flatline ( 5077 ) <vincent@jan@goh.gmail@com> on Tuesday June 25, 2002 @05:05PM (#3765486) Homepage
    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?

  • Before people go blasting MS (Score:4, Insightful)

    by rutledjw ( 447990 ) on Tuesday June 25, 2002 @05:06PM (#3765490) Homepage
    let's not forget that the vast majority of coding is for customer-specific business apps. (Source: Cathedral and the Bazzarr) The vast majority of bad code is produced by you and me. Although MS may contribute...

    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...

    /rant. But it feels good to get that out

    • 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.

      What, you think that Sun developed Java because they are interested in moving software ?
  • 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."
  • For instance, how much money is actually spent on software development and acquisition per year right now? If it's, say, $120 billion, then that $60 billion figure is a very high number, an additional 50% that's spent on top of the acquisition and development costs. But if $6 trillion per year is spent on software (not likely, of course), then that $60 billion per year represents only 1% of the money actually spent on software.

    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.

  • 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

  • whatever (Score:3, Interesting)

    by cr@ckwhore ( 165454 ) on Tuesday June 25, 2002 @05:19PM (#3765558) Homepage
    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.
  • And, what, $59 billion in sloppy code is from Microsoft?

  • Irrational Project Constraints (Score:4, Insightful)

    by Syncerus ( 213609 ) on Tuesday June 25, 2002 @05:20PM (#3765570)
    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.

  • 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...>
  • 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.
  • 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'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...
  • Sloppy coding earns me approx. $31.75/hr!

  • Not everyone loses. (Score:3, Insightful)

    by erroneus ( 253617 ) on Tuesday June 25, 2002 @05:39PM (#3765662) Homepage
    **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.

  • Back of the envelope calculation (Score:5, Funny)

    by washirv ( 130045 ) on Tuesday June 25, 2002 @05:39PM (#3765666)
    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? :)

  • Sloppy Coding, Gaming, and OSes (Score:4, Insightful)

    by TibbonZero ( 571809 ) <Tibbon&gmail,com> on Tuesday June 25, 2002 @05:49PM (#3765710) Homepage Journal
    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...

  • 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.

  • Software is complex. Most software products consist, at minimum, of many thousands of lines of code, which each constitute discrete units that fit together to achieve a very intricate set of desired results. Most products have defects or problems in them of some sort or another - but very few products are as complex as software. Now, a lot of consumer hardware shares a lot in common with software - large number of third party components, lots of discrete elements, all fit together to create a complex system with many functional behaviors. But these systems don't face the sheer number of variables in usage and environment, i.e. they don't have anywhere near the number of possible inputs as even a relatively straightforward piece of enterprise or desktop software.


    So software suffers from immense complexity. Also, the software business tends to have VERY short product lifecycles. Because operating systems, feature expectations and everything else about the business change fast, the first company with a decent product out the door often wins. Thus it makes business sense to release software that is _good enough_ for most users, even if it's not bug free. And if you are graced with a monopoly, hell, it doesn't even have to be good enough.


    Mind you, producing nearly bug free software is possible. NASA, avionics software, etc. The cost per line of code (and thus per feature or capability) is IMMENSE. If all software were built this way, we wouldn't have 90% of the tools we have today, and the cost of software would be prohibitive (simple economics tells you this - either sales volume would have to be much higher or price per unit would have to be much higher to achieve normal returns with the massively increased cost of development).


    We all know that management at a lot of software companies needs to get a grip on the fact that there's a trade-off between quality, featurization and development schedules. If you push a schedule beyond a certain point, and refuse to cut down the feature list, the level and quality of testing will decrease, and the number of bugs in the shipped product will increase, and this may or may not hurt sales or your reputation, depending on the nature of your particular market segment and how many substitutes for your product there are on the market. Any halfway competent technology executive knows this.

  • so the BSA owes us? (Score:3, Funny)

    by fermion ( 181285 ) on Tuesday June 25, 2002 @06:39PM (#3765922) Homepage Journal
    1. This article implies that bugs cost the end user around 30 Billion.

    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?

  • Maybe better techniques could be explored. (Score:4, Insightful)

    by rice_burners_suck ( 243660 ) on Tuesday June 25, 2002 @06:52PM (#3765982)
    Better testing could allegedly cut that by one-third.

    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 a Silver Bullet: Signal-Based Software (Score:3, Interesting)

    by Louis Savain ( 65843 ) on Tuesday June 25, 2002 @06:55PM (#3765990) Homepage
    There is silver bullet. We must emulate the parallelism of hardware ICs in our software ICs. In a 1995 article [virtualschool.edu] 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.

Slashdot Top Deals

My sister opened a computer store in Hawaii. She sells C shells down by the seashore.

Close