Slashdot Mirror

← Back to Stories (view on slashdot.org)

Yet Another Software Sucks Article

Posted by Hemos on from the it-all-sux0rs dept.

Narril Duskwalker writes "This one's from cNet.
`There's only one problem with software development these days, according to security analyst and author Gary McGraw: It isn't any good.'"

9 of 32 comments (clear)

  1. Wrong Problem. by Snowfox · · Score: 2, Interesting
    The problem is that consumers are willing to put up with crap because they buy marketing promises instead of software.

    The problem is that software vendors get away with using the laughable disclaimer that "this product isn't warranted for any suitability or purpose."

    I'm not even sure that the kind of disclaimer above should be legal without a more concise "NOT GUARANTEED TO WORK" stamped across the splash screen.

    If a company isn't willing to guarantee that a program fucking does something, why do they keep coming back to it? Because it's got a Madonna song and fluffy clouds in the commercial?

    If a company consistently provides unstable software, why do people run to upgrade instead of demanding more comprehensive patches for what they've already paid for? Is rushing toward flashy new features more important than stabilizing what you've already got?

    1. Re:Wrong Problem. by Arandir · · Score: 2

      I hear your cry, and I have shouted it myself before. All commercial software should have a warranty, even open source commercial software. My toaster has a warranty. My coffee pot has a warranty. My car, stereo and carpet have warranties. Even my RAM has a warranty. Why not my software?

      I don't expect hobbyist, academic or non-profit software to have warranties (such as Linux), but I do expect all software that I purchase to have one (like the Redhat distribution of Linux). It doesn't have to be a fancy warranty, but it should be more than "we disclaim all merchantability even though we put a price sticker on it like it was". Don't claim that your software is usable then disclaim fitness for use. That's borderline fraud.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    2. Re:Wrong Problem. by ameoba · · Score: 3, Interesting

      Not quite... more like features that aren't needed keep getting added so that, instead of fixing the current version, the version number can be incremented and customers can be charged for upgrading to a newer version.

      We can blame Microsoft for this sick state of affairs. Until they came along, it was SOP for software licenses to essentially rent the software to the user, giving the author a stable revenue stream. Then Microsoft comes along, and realizes that to sell software for microcomputers, for a number of reasons (lack of hardware support, lack of user interest, non-commercial nature of licencees) a different licencing paradigm was called for, so they went with something more like books.

      The catch is, books are generally heavily proofread, but once they've been printed, your stuck. Normally this isn't so bad, since most books work just fine w/ a few typos. Not so with computer programs, a single typo going unnoticed durring testing could be a fatal flaw for software.

      Unfortunately, the book model provides no significant incentive to fix released software. Sure, the major showstopper bugs will get patched if they escape testing, but most of the minor glitches and irritations will be left in until the next release, when the product can again be sold for a profit.

      The real kicker is that the market for new systems is slowing, and with it the market for new softwar, and consumers are tiring of having to pay to upgrade to properly working software, but the last 20yr of paying once for software has lead them away from acceptance of subscription-style payments, putting software houses in quite a bind...

      So, if the consumer was able to accept a payment model that didn't reward the perpetual ignore-bugs/add-features/realease-new-version cycle, we might have non-bloated, functional software.

      Personally, I give it another 20yr, before the general populace has enough common sense about computers to force vendors to do the Right Thing.

      --
      my sig's at the bottom of the page.
    3. Re:Wrong Problem. by Snowfox · · Score: 2
      All products made by all companies have a defect rate. 1 in 1000 cars breaks down within a month (or whatever). Software fails for 1 in 1000 of real-life use cases. Same difference. In both cases the vendor should make a reasonable effort to deliver on their commitment if there is a defect, but nobody _guarentees_ anything.

      Yes, but what other industry is allowed to include a blanket disclaimer for all effects of using a product? And what other industry can refuse to let you return your product when it doesn't work for you?

      I reiterate that the current software warranties and disclaimers should be illegal.

  2. Re:Get off your soap box ... by rjamestaylor · · Score: 2, Funny
    comuters run on electricity

    Listen, pal, very, very few commuters run on electricty. Oh, yeah, you'll see a few GM EV1's or Honda Insights (which is only a hybrid, anyway) during your morning commute, but the vast majority of drivers still rely on the internal combustion engine.

    Get your facts straight before you post, buddy!

    --
    -- @rjamestaylor on Ello
  3. Try DeMarco's take on it... by MeerCat · · Score: 3, Interesting

    OK, so the article is about coding for security, but it's worth considering Tom DeMarco's line in his excellent book Why Does Software Cost So Much ? where, he says, the correct answer is "Compared to what ??".

    Kicking those who manage complexity is always going to be easy - but until you can do better then you're not really helping.

    The book is well worth a read... if only to shut up all those metrics freaks...

    T

    --
    I spent a lot of money on booze, birds and fast cars. The rest I just squandered. - George Best
  4. Re:Some insight. by Detritus · · Score: 2
    How about system architecture/design?

    Even if the software is bug-free, a bad system design can make the system insecure.

    --
    Mea navis aericumbens anguillis abundat
  5. Reactions kind of funny... by pdqlamb · · Score: 2
    and kind of sad, too. Seems almost nobody on slashdot wants software that is secure. We'd rather have it complex, with lots of bells and whistles. Really???

    Let's face it, the guy is, unfortunately, right. C and C++ ARE crappy languages, in that they rely on the programmer to ensure there are no buffer overflows. Other languages do offer such protection. OK, they may be different from what you are used to working with, but too many programmers (me included) don't check for overflows. As a result, we get bugs. Some merely crash the program or the system, some can be used to crack the whole box.

    Who's to blame? Designers, programmers, consumers? It's tough work to retrofit security into an insecure design -- look at all the work sendmail has required in the last five years. In general, only those programmers who have been bitten by a security bug take the time to put in the extra checks -- it slows down the programming and the program. As for consumers, we'd all rather have the latest and greatest."features." (Like Clippy!) Until you've been bitten, of course; mine came when somebody hijacked my 14.4k dial-up connection to relay spam.

    Why don't we return all the software that crashes, like everybody's talking about doing with the new copy-protected CDs? What do you need with the new Office XP that wasn't in Office 95, for example? The new, improved, crash-resistance? ;)

  6. determining number of bugs... by dreamquick · · Score: 2, Interesting

    "And the best way to determine how many problems are going to be in a piece of software is to count how many lines of code it has. The simple metric goes like this: More lines, more bugs."

    No the best method also factors in competancy of management, competancy of engineers, and the cost of failure.

    Lets take as example nuclear power plants than have operation control code behind them - how many lines of code do they have? I'd suggest 10's of millions.

    Why don't we see crashes of these systems widely reported?

    1) They are safety critical, if an error occurs anywhere the surrounding code must fail closed meaning that it should not result in false results being produced.

    2) If you screw up you can't just say "hey we'll fix it in the next version" - if you are lucky you'll simply get your day in court for negligence and you will no longer have a place in the safety critical market. If you are unlucky that still happens but you then get the ass sued off you by the relatives of anyone injured, maimed or killed by your software bug.

    You have to admit the second point really is one hell of an incentive not to screw up!