Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming IT Technology

Why (Most) Software is so Bad 827

Rivard was one of several to point out that MSNBC says software sucks. My opinion is that in software fields where the monetary gap between market-leader and second-place is large, we should expect bad software. Good design, good execution, good debugging all take time, but users can't see under the hood -- and wherever information is scarce or not readily traded among consumers, the free market bogs down. (Note what the article says about McAfee VirusScan.) So companies that don't plan on releasing a crummy 1.0 and fixing it later go under. That's just the way some markets work; if you're a coder or engineer who doesn't like that, find yourself a job in a niche without that monetary gap. Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued. Update: 06/18 14:10 GMT by J : Readers point out the story is a reprint from Technology Review (one of the few good magazines I get -- but this issue hasn't arrived yet :).

Rivard continued his writeup with an interesting point of view, saying that while we all know software sucks, we just accept it:

"Even though 'plenty of reviewers, pundits, hackers and other outsiders' will point out problems, often intentionally left in the product, no one has brought a liability suit against the makers of the known-to-be-vitiated product -- because the software gestapo (the End User License Agreement) has been 'able to avoid product liability litigation partly because software licenses force customers into arbitration' of poorly designed pith.

"There is a light at the end of the tunnel, believe it or not, and it's Bill Gates. Microsoft suspended coding for two months to seminar on bugs and how to fix them. Gates told his employees he wanted to make 'reliable and secure' software Microsoft's 'highest priority.' If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."

This discussion has been archived. No new comments can be posted.

Why (Most) Software is so Bad

Comments Filter:
  • Micro$ofts problem is that they forget the "and fix it later" part.
    • Re:M$ (Score:3, Insightful)

      No, if you ever hit the Windows Update page, you see they fix a lot of stuff. Now, the fact that they HAVe to fix stuff is the problem. I develop software for a living, and we beat the living hell out of it before it goes to production. We have all kinds of tests, regression scripts... I realize we're not doing OS, but the principle's the same. Test it before you toss it out the door.
      • Re:M$ (Score:3, Insightful)

        by zangdesign ( 462534 )
        How does one test against every possible configuration of every possible computer that could conceivably run one's OS?

        Microsoft keeps finding bugs - that is true. Some of them are extraordinarily serious - that is also true. But it is impossible to find every bug the first time, or even the hundredth time out.

        Remember, they are up against people who are actively searching for exploits. This is not your average user we're talking about finding a hole in the system.

        On the whole, Microsoft does a somewhat overpriced, but erratically decent job of doing the tasks I use it for.
        • Re:M$ (Score:3, Interesting)

          by ishark ( 245915 )
          How does one test against every possible configuration of every possible computer that could conceivably run one's OS?

          How is it possible that on the same PC I have a 70 day uptime with linux?

          • Re:M$ (Score:3, Insightful)

            by eaolson ( 153849 )
            How is it possible that on the same PC I have a 70 day uptime with linux?

            Perhaps, because with linux you have a system designed by people not concerned with cost-effectiveness?

            No, I'm not trolling. There is a considerable difference between people who write code because they enjoy it, and people who code because they are attempting to market a profitable product. (Abusive monopoly-ness notwithstanding.)

            It takes an infinite amount of time (i.e. money) to make a product perfect. Therefore, any for-profit business must operate in a mode that allows them to release a product that is good enough to sell, but not so good it is perpetually in development.

            As an old boss of mine used to say, "The enemy of the good is the better."

            • Re:M$ (Score:3, Informative)

              by NanoGator ( 522640 )
              I have a Win2k box that's been up for about 60 days now. It's a home-brew PVR.

              I've watched an NT server box running IIS stay up for a good 90 days. The only reason it's not longer is that we had to shut it down to move it.

              I think it really depends on how ya build it. The biggest instability is caused by hardware. If your hardware has fatal drivers, don't expect it to run for very long.

              My main entertainment computer (also Win2k...) has an uptime of over a week. But I play the shit out of games like Quake. When I don't play those games, my uptime's seriously longer.

              Everybody knows that Windows has a lot more games than Linux. :P
          • Re:M$ (Score:3, Insightful)

            by borgboy ( 218060 )
            How is it possible that I have PC servers with better uptime statistics than production AS/400 boxes? How is it possible that RedHat raises a Signal 11 when I try to install it on the same workstation that has never blue-screened XP? Anecdotes are useless.
        • Re:M$ (Score:4, Insightful)

          by juliao ( 219156 ) on Tuesday June 18, 2002 @09:55AM (#3721943) Homepage
          Somehow, most of the bugs we've seen lately have very little to do with the congifuration of the computers on which the OS runs.

          In the case of IIS exploits, for instance, it has nothing to do with it whatsoever.

        • Re:M$ (Score:5, Insightful)

          by battjt ( 9342 ) on Tuesday June 18, 2002 @10:11AM (#3722071) Homepage
          How does one test against every possible configuration of every possible computer that could conceivably run one's OS?

          You design around it. 3rd party drivers are a constraint for MS. Drivers do not have to run in ring-0. Microsoft chose for drivers to run in ring-0 and we pay for it with crashes.

      • Re:M$ (Score:3, Insightful)

        But the industry has dooped people so well that they believe there is really nothing wrong when software fails. They believe that it is just the way it is, that they should hit the reset button and get on with life.

        Product testing costs money. The customer will buy it even if it is defective because 1. They don't know they have a choice, and 2. They don't really care that there's a problem. If a customer will buy it anyway why spend more money on testing? It reduces the bottom line and you can always fix the problems people actually complain about later.

        Many companies today care little about integrity or the satisfaction of their customers as long as it doesn't have an effect on profits. In the software industry the cost of producing a product with fewer defects is greater than that of having a possibly unhappy customer.

      • Re:M$ (Score:3, Interesting)

        by MrResistor ( 120588 )
        I hit the Windows Update page fairly regularly, and unfortunately Microsoft doesn't see fit to include such things as the IE6 security patches there. I have to know they exist, which I only know from reading /., and go searching for them. I thought IE was part of the OS? I can download IE6 Punjabi menu support from Windows Update, why can't I get a fscking security patch there? Perhaps I could just reinstall IE? No dice, Windows has detected that I already have IE6 installed.

        I'll believe that Microsoft is actually fixing stuff when they start including IE security patches on the main Windows Update download page. I'll believe that they have a commitment to trustworthy computing when they give me an update tool as simple to use as SuSE's YOU. That's right; when a company with $40 billion in the bank can keep up with a company that's had to lay off 90% of their US work force, I might start giving them some respect. Until then "trustworthy computing" is a bunch of marketing hot air.

  • MSNBC (Score:4, Insightful)

    by Jucius Maximus ( 229128 ) <m4encxb2sw@snkmail.OPENBSDcom minus bsd> on Tuesday June 18, 2002 @08:55AM (#3721542) Journal
    "Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued."

    If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not MSFT-criticisers. This is typical of them.

    • Re:MSNBC (Score:3, Interesting)

      by Peyna ( 14792 )
      It's not real uncommon for this sort of thing to happen. Our local newspaper was bought out by Gannette(sp?) a little bit ago, and the editors let them have it for a long time by publishing articles about how terrible they were and how they were going to ruin the newspaper. (IMHO they have ruined it. Story/Advertisement ratio on each page is about 1/6).
    • Re:MSNBC (Score:2, Informative)

      This is not an MSNBC written article. If you look closely, you will see Charles C. Mann of Technology Review credited. In fact, I have the article sitting on my desk. The article is on the front cover of the July/August 2002 issue.
    • Re:MSNBC (Score:3, Interesting)

      by lindsayt ( 210755 )
      MSNBC is in one of the best positions to criticize Micro$oft - since the US theoretically has a free press, M$ really can't censor their own (or perhaps I should say their 0wned) media outlet. If they did so, one of two things would happen: 1) A public outcry of monopolistic muscle, or 2) people would just slowly start recognizing other channels to have more unbiased news, and NBC, with or with the M$ attached, would fall from significance.

      The net result is, M$ doesn't want to gamble that. It makes them look good if M$NBC criticizes them because it shows they're not using their money and power to censor the press. So their journalists get to express their views openly.
      • Re:MSNBC (Score:5, Interesting)

        by thud2000 ( 249529 ) on Tuesday June 18, 2002 @09:22AM (#3721714)
        The key to the article is the last section, which talks about remedying the bad software situation, describing massive class-action lawsuits as "a bad idea whose time has come." MS knows that it could live through a class-action suit of this type. Would your favorite open-source project survive being sued back into the stone age? I think this article is an attempt to get public opinion stirred up to the point that UCITA laws - which include things like mandated warranties on software products -seem like a reasonable solution, and thus make life more difficult for MS's competition.
    • At the very bottom of the page:

      MSNBC is optimized for
      Microsoft Internet Explorer
      Windows Media Player

      Reminds me of the GPL bashing story that was hosted on a linux machine.

    • Re:MSNBC (Score:3, Interesting)

      by wdr1 ( 31310 )
      "Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued."

      If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not MSFT-criticisers. This is typical of them.

      MSNBC didn't really criticize them. They reprinted an article that in turns quotes a consultant talking about MS's poor judgement in making it easy to run applications via email (and thus paving the road for the I Love Your virus and it's ilk.) That's quite a few degrees of seperation from them running an editorial stating MS should be sued from their 8.75 billion screwup. (Which they should be. It'll be interesting to see if a class-action law suit is ever filed, as it's probably not too late.)

      It's an easy mistake to make, especially when Jamie, Timothy, or Michael post a story. (IMHO, they tend to use slashdot as a ranting board with ill-concieved ideas as they would otherwise find themselves rightly ignored or dismissed.[1] Witness that ~69.5% of the story Jamie posted was just drivel from someone who is neither a qualified economist, entrepreneur, or software engineer, yet important enough to justify *NOT* being a simple follow-up comment, but up there with the story.)

      Anyway, It's well worth clicking through the story though, to get the straight scoop. Sure, you may not be the first post, but any comments you do make will be better informed, and you'll make slash a better community for it.


      [1] I know, I know, anything negative about an editor is a troll of flamebait. Mod me down. *sigh*

  • now there's something i'd like to see. maybe it could enforce algorithms, understand design specs and anticipate customer mind-changes, too.

    i think the next version of C# is suppoed to do all of this, with some kind of XML voodoo scheisse.

    • Actually, Ada does a good job on enforcing good code, but many people ridicule it. It is those features of the language that support good coding pracitces (strong typing, etc.) that are the source of most of people's "issues" with the language. As the saying goes: "You can write FORTRAN in any language." It just takes more effort in some languages than others.
  • by joib ( 70841 ) on Tuesday June 18, 2002 @08:57AM (#3721555)

    If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code; going back to the days of intense peer-review, instead of relying on compilers; and intense planning, past the bungling paradigm of the bar napkin."

    "There's no silver bullet" -Fred Brooks, a long time ago.

    • > "There's no silver bullet" -Fred Brooks, a long time ago.

      Ah, yes -- the mantra of people whose favorite language is known to promote sloppy programming practices or otherwise correlates with buggy code.

      There's no silver bullet, in the sense that switching languages won't make all your problems go away, but that's hardly the same as saying that choice of language won't make a difference.

    • "There's no silver bullet" -Fred Brooks, a long time ago.

      No, but there are many many little normal ones ;)
      Seriously, "little" things like languages that espouse safety and clarity add up.
      • "little" things like languages that espouse safety and clarity add up

        These aren't little things - they're ways of fundamentally changing the way programming is done. I see highly trained C programmers spending days to write a program that parses a complex text file, when a high-school student who knows Perl (or just Awk) can do the same job in minutes. And without buffer overflows.

        Yes, I am being a bit unfair for blaming the tool when it is being misused. (After all, Perl itself is currently written in C.) But using the right tool for the job is incredibly important.

  • by Kombat ( 93720 ) <> on Tuesday June 18, 2002 @08:59AM (#3721569) Homepage
    My opinion is that in software fields where the monetary gap between market-leader and second-place is large, we should expect bad software.

    I disagree; take a look at other industries. Some of the highest-quality products are produced by the tiny, niche-market manufacturers. The best cigars in the world are not from Phillip-Morris. The finest cuisine on your block is not the mega-corporation with the giant yellow 'M'. The most accurate watches don't come from time-giant Timex. The finest literature on the bookshelf isn't necessarily from the biggest publisher.

    Software is hard to compare to other products. It's intangible. It's complex. There are a million different ways to get "Hello World" onto your screen. Maybe that's the problem?

    Software is also relatively young. Not just in the sense that it has only been around for 40/50 years, but in the sense that the tools evolve so quickly, that it almost seems like every few years, you're working in a completely different manner than before. And it takes time to become familiar and comfortable with the paradigms associated with your environment. Just when you've got a system worked out, everything changes again.

    Before, the customer wanted a library of CGI scripts to run their e-commerce website. Now that've got a handle on scripting design patterns, the customer wants EJBs. By the time you learn what to expect to go wrong with EJBs, the customer will want a cell-phone interface to their inventory.

    Sometimes, I'm amazed software works at all.

    • While the local cafe might make one hell of a sandwich, more people are going to eat at McDonald's even if they are side by side, because they are more familiar with it, and don't care if it is going to kill them because they know what they are getting.

      This is the case with a lot of software already. People know what to expect Microsoft, whether or good or bad, and are comfortable with that. You through something new at them, and a lot of people will jump, but not that many. We like what we are familiar with, and that's why people stick with Windows.

      It's the same reason Mac users stick with Macs, and why I think that Apple's latest marketing campaign isn't going to accomplish much. Although it would be great if it did.
    • to design you a house,
      then when he was almost done, said that the walls must be made from foam.
      ....except the one on thats in the swamp....
      ....and now that you've disigned one house, it shoudln't take you long to do a few more...
      ..and did i say there has to be a high speed rail link between them...It must travel faster than the speed of sound, but never hit any animals that happen to wander on to the track.
      ..and can you make that house bomb proof....
      whys that house got walls made out of foam?
    • Kombat's Law: (Score:5, Insightful)

      by Bastian ( 66383 ) on Tuesday June 18, 2002 @09:58AM (#3721969)
      Kombat's Law:
      Before, the customer wanted a library of CGI scripts to run their e-commerce website. Now that've got a handle on scripting design patterns, the customer wants EJBs. By the time you learn what to expect to go wrong with EJBs, the customer will want a cell-phone interface to their inventory.

      Observation on Kombat's Law:
      Technologies become fashionable soon after they are introduced, usually when the libraries are still version 1.0 or one-point-epsilon.

      Related observation on the software industry:
      It's standard practise to push a buggy pile of kludges still in need of major debugging out the door to meet overly optimistic deadlines and call it version 1.0.

      Sum conclusion of it all:
      We're all fucked.
      Those who like to use exciting new gizmos are even more fucked. Those with bosses who are attracted by shiny objects are the most fucked.
    • by reflective recursion ( 462464 ) on Tuesday June 18, 2002 @11:38AM (#3722711)
      Software is also relatively young. Not just in the sense that it has only been around for 40/50 years, but in the sense that the tools evolve so quickly
      It is very ironic, the tools and methods in use today and the data formats in use. There is a saying that goes something like this: "Those who do not know Lisp are doomed to reimplement it." What have we learned lately in new programming tools and languages? From Java and C# we learn that garbage collection is a Good Thing(tm). From Perl we learned that quick throwaway programs (prototypes) can be extremely useful. From SGML to HTML and finally XML we learned that having a simple representation is the best way to represent malleable data (away from documents, back to symbolic expressions, or S-expressions).

      Now if only we could pursuade people that parans aren't as evil as they first look...

      One thing many programmers haven't gotten which quite a few Lisp'ers have is this: data is data. How the data is contained is irrelevant. What is done or can be done with the data is the most important. What tools you use to move data to other forms of data doesn't matter. There is also a very fluid nature to Lisp (i.e. code is data), which is very eye-opening (especially for those asm/C/C++ coders out there).
  • as a developer (Score:2, Interesting)

    by dallask ( 320655 )
    Im working with 2 other developers and one source of fundage.... the client.

    I has been an enormus task to get the software: A) bug free B) functional C) better than the compitition in a year.

    There are problems, and there are alot of thing that I would like to do different.... but its just not possiable...

    I can only hope that it does well after release. but it makes me wonder what I could have done with more fundage...
  • by shren ( 134692 ) on Tuesday June 18, 2002 @09:00AM (#3721578) Homepage Journal

    Software's so bad because it's still handcrafted, and the interchangable parts don't. Cars sucked too when when they were done the same way. OSS isn't the solution. The solution is for Computer Engineering to someday become as rigorous as other areas of Engineering.

    • by RalphSlate ( 128202 ) on Tuesday June 18, 2002 @09:12AM (#3721658) Homepage
      It's also so bad because the technology (i.e. languages) keep changing rapidly and dramatically. This isn't the case of someone developing a better hammer, this is like someone developing a completely new toolbox full of tools every 2 years. People need 6 months to get completely up to speed on how to use these tools properly, but there's never enough time to actually train someone (i.e. not just a 1 day course) on how to use them.
    • by xtal ( 49134 ) on Tuesday June 18, 2002 @09:22AM (#3721718)
      This is one of the better comments on this thread. Until manufacturing figured out an assembly line that worked, understood proper tolerances and specifications, put in quality control - lots of other things sucked too, and sometimes sucked worse than software does today. It's a wonder some of the early internal combustion engines worked at all.

      People who write software should take a piece of learning from those who write the code that becomes digital integrated circuits. Engineering those designs is just that - engineering - because a bug here or there is usually a very serious matter. Tremendous amounts of time are spent verifying your design works correctly. The same thing is true with most embedded systems as well, although those lines are getting blurred with system-on-chip development.

      Anyone who calls what is passed off for the majority of commercial, "professional" software development an engineered product is kidding themselves.

      • "This is one of the better comments on this thread."

        To me, these comments seem utterly out of touch with reality. I find bugs and insufficiencies in open source software. But generally open source software impresses me as an attempt to do a good job.

        In contrast, Microsoft software seems just sloppy. For example, Microsoft's Internet Explorer has 18 unpatched security bugs [] (when this was written). These active security risks are different from the recent 15 that have already been fixed. This is sloppiness, not mistakes, and I don't find anything like it in the open source world.

        When I have a problem with open source software, I find that I can get help. When I call Microsoft, I find that, usually, no one with whom I am allowed to talk knows any answers. Right now, for example, no one seems to know how to repair a new, Intel Motherboard, Windows XP installation that won't create a virtual memory paging file. It's buggy, and nothing can be done other than re-install the OS and all the applications.

        If you find a big problem in open source software, chances are that you will communicate directly with the main authors. With Microsoft, I have not been able to get answers. This article says that the Psychic Friends Network is equally as good as Microsoft technical support: Microsoft Technical Support vs. The Psychic Friends Network [] The conclusion of the article seems reasonable considering my experience with Microsoft. Neither organization has useful answers, but The Psychic friends Network is more friendly and less expensive.
      • The Capability Maturity Model ( from the Carnegie Mellon Software Engineering Inst ( has been developed to aid this transition from a craft disipline (hacking) to an Software Engineering displine.

    • by MagikSlinger ( 259969 ) on Tuesday June 18, 2002 @11:35AM (#3722701) Homepage Journal
      Software's so bad because it's still handcrafted, and the interchangable parts don't. Cars sucked too when when they were done the same way. OSS isn't the solution. The solution is for Computer Engineering to someday become as rigorous as other areas of Engineering.

      You're half right. OSS isn't THE solution, but is part of a larger class of solutions. The reason mechanical and other forms of engineering could evolve into reliable disciplines is the ability to freely and openly communicate between the practitioners. With an industry wide peer review, everyone can analyze someone else's work, share their insights with everyone and everyone can benefit because that new technique or design can be incorporated by others into their work.

      Shortly after the WTC attack, the American Civil Engineers society put together a panel of engineers to analyze the failure, and provide a report to the entire civil engineering community. When was the last time any proprietary software company did that? In fact, we've seen how these companies use lawsuits to squelch any such activity.

      Openess, peer review and the ability to freely share information, lessons and strategies is what sets the other engineering disciplines apart from software engineering.

  • As the army boys (and gals) say...

    Keep It Simple Stupid

    Today's programs (and O/S's) are horrendously complex so this in it self is a problem. Sure there are other problems, but the more complex a system the more likely it is to fail.
  • Forcing good code? (Score:5, Insightful)

    by kafka93 ( 243640 ) on Tuesday June 18, 2002 @09:02AM (#3721586)
    "like creating a programming language that forces good code"? I doubt it. It's my impression that even where languages do enforce various checks - perl in taint mode, for example - there are always ways around it or issues that the code can't check. After all, a significant proportion of "bugs" aren't faulty code per se, but correct code that is based upon incomplete or incorect assumptions and design.

    The fact is, there are well-researched, well documented means of achieving quality control in development. They're simply not practiced by many because the implementation overheads are just too great. Many coders don't plan their code adequately, don't document their code adequately, and don't test their code adequately. However, this isn't necessarily a 'bad thing' -- frankly, in many circumstances it's just not that important if a few bugs sneak through which can be patched at a later date. As is always the case in such matters, security/stability are sacrificed for convenience and speed of development. And that's not necessarily a bad thing, especially in an industry where a product can be superseded or otherwise rendered obsolete even before its bugs become too much of a problem. (Although I'd admit that there are dangers in taking this for granted, as seen with the y2k issues..)

    We should expect bad code because we expect code that rolls out quickly and at a low budget. We should expect bad code because most coders don't want to spend their time testing and documenting, and because most companies don't want to spend money on dedicated testers or on implementing rigid development processes. And we should expect bad code because even bad code can work 'well enough' to keep most people happy most of the time.
    • by AVee ( 557523 ) <slashdot@[ ] ['ave' in gap]> on Tuesday June 18, 2002 @10:11AM (#3722069) Homepage
      While what you say is true, it's not only testing and documentation that is lacking. Good design is, IMHO, at least just as important and often overlooked. The actual coding of a program is a lot easier and less error prone if everything that has to be done is defined beforehand. It also makes the testing easier, because a good design will tell exactly what to expect under certain circumstances. But most programmers, myself included, tend to start writing code as soon as possible. This is often encouraged by management people that want to see results. But they don't understand a design and only believe you've made progress when they see something working, not when you show them a design wich makes it possible to implement everything within a week...
  • by ajp ( 192328 ) on Tuesday June 18, 2002 @09:03AM (#3721594)
    This article is out of the July/August MIT Technology Review. My copy of the magazine proves their point in an ironic fashion.

    The zip code I live in covers two cities, let's call them Appleville (tiny village) and Apricotland (large, sprawling concrete wasteland.) I live in Apricotland which is asciibetically second (based on the third letter.) Note that the first two letters are the same. MIT TR's mailing system lists me as living in Appleville. Why would it assume that zip code 12345 is the smaller village instead of the sprawling metropolis?

    Yup. Buggy software. I could--as anyone reading ./ probably could--isolate the bug in ten minutes given the source. Likely it assumes that either the first city is valid or that the likelihood of two cities beginning with the same two letters in the same zip code is too small to consider.

    The joke's on you, MIT.
    • Or, more likely still, the Postal Service has decided that, damitall, if your zip code is 12345 you live in Appleville.

      USPS place names don't map precisely to "real" place names, but they're valid for mail delivery purposes.

    • by analog_line ( 465182 ) on Tuesday June 18, 2002 @09:22AM (#3721717)
      Knowing a bit of how mass mailings work, specifically how you figure out who is where through zip codes, the actual city that gets printed on things mailed to you in that fasion is determined by checking the Post office database, usually through a program such as AccuZip.

      Lots of times, the city the post office has you in isn't the city you actually live in, but it will get to you all the same, because the Post Office can't assign multiple municipalities to a single zip code. They probably picked the small town because it didn't have any other zip code, or whatever criteria they have. Don't blame the software for something that isn't it's fault. It's just doing a query based on the official database.
  • It's Time (Score:4, Insightful)

    by elsegundo ( 316028 ) on Tuesday June 18, 2002 @09:03AM (#3721597) Journal
    To me the largest factor in determining whether the 1.0 release of something will be acceptable is time.

    Given enough time for proper design and testing, a 1.0 release could be acceptable, but companies hiring consultants do not want to pay for the time, and companies that produce software for the general public have to rush products to market to beat company X, whose competing product is due for release, and (more importantly?) they need to please their stockholders.

    Once in a while you get a Mozilla-type thing that takes forever, but puts out somthing worthwhile with 1.0.
    • Re:It's Time (Score:3, Interesting)

      by sphealey ( 2855 )
      To me the largest factor in determining whether the 1.0 release of something will be acceptable is time.

      Given enough time for proper design and testing, a 1.0 release could be acceptable, but companies hiring consultants do not want to pay for the time, and companies that produce software for the general public have to rush products to market to beat company X, whose competing product is due for release, and (more importantly?) they need to please their stockholders.
      Over the last 8 years I worked for 2 different companies. One was a 100 y.o., engineering-oriented organization. Whenever undertaking any significant new project, they did the kind of detailed, complete, time-consuming analysis that you describe, followed by a similarly thorough implementation. That company still exists and is doing OK, with a reasonable if not spectacular profit margin.

      The second company didn't do any of that. When a decision needed to be made, they spent about 10 minutes looking at it, then made a choice. Rather than doing detailed project plans, they would constantly reassess and make direction changes. Their belief was that it was far better to do something and start getting feedback than spend too much time in analysis. This company also does pretty well, with a higer profit margin than the first.

      Which approach is better? I don't know, but it was quite a culture shock going from one to the other! However, one thing is for sure and that is that people who are wedded to the "analyze-project manage" way of doing things (think PMI) are firmly convinced that the "fire - ready - fire - reaim" method is nothing but disaster waiting to happen. I am no longer so sure.


  • ...because of a bug in the JavaScript which prevented the menu selections from working. Clearly this wasn't tested properly.
  • by jchristo ( 472245 ) on Tuesday June 18, 2002 @09:05AM (#3721611)
    I believe that we are seeing the increasing development of issues that were first coming to light in the late 90's, when the Y2K problem was starting to be recognized as a problem for society at large. As the economy comes to rely more heavily on properly functioning software based systems, the push to make the designers and constructers of these systems responsible for them. Too often in the community the various proposed approaches to design and implementation (now being expressed as the battle between methodologists and agile methods proponents) obscure the basic need to build the right systems, in the best known fashion. This is, at heart, being willing to accept responsibility for what has been promised. If the community will not do this, then legal sanctions will be imposed which force the issue.
  • by mesozoic ( 134277 ) on Tuesday June 18, 2002 @09:05AM (#3721614)

    "If it doesn't spit out an error message, it must be done correctly, right?"

    Well, that IS how they teach people to do it in college...

    I'm disappointed that this article didn't mention open source even once. The process of writing an open source project is much different from that of a proprietary piece of software, and (as far as I'm concerned) the open source method is much better equipped to deal with things like sloppy code. But to the average computer idiot who reads MSNBC, this article makes it seem like all software systems are going to kill U.S. Marines and crash ambulances into each other.

  • by pointym5 ( 128908 ) on Tuesday June 18, 2002 @09:05AM (#3721616)
    1. Smart (or dumb) guys form startup around good idea. Version 1.0 gets written in a frenzy of caffeine and beer, riddled with bugs because it has to be delivered before the money runs out.

    2. Mistakes made in version 1 are sworn off as version 2 is designed. Version 2 is built by the swell of 2nd-generation coders, hired as fast as possible and sent to work unsupervised by the overworked 1st-generation engineers.

    3. Version 2 is delivered with all the good ideas on the surface, but implemented by less-than-excellent coders.

    4. Widespread adoption funds much additional hiring. Anything vaguely mammalian is hired to fix bugs and work on new features and new products. Most 1st-generation engineers leave with their money. Product design and development is run by people who don't know what they're doing.

    • You forgot 5 and 6 (Score:5, Interesting)

      by Art Tatum ( 6890 ) on Tuesday June 18, 2002 @09:38AM (#3721811)
      5. Fixing most of the problems requires fundamental architectural changes that would be expensive and would take two or three years (a la Mozilla). Being a for-profit corporation, you can't afford to wait that long or spend that much money.

      6. Fixing even the shallow defects would break backwards compatibility and the customers all swear they will go to your competitors.

  • by 4of12 ( 97621 ) on Tuesday June 18, 2002 @09:06AM (#3721618) Homepage Journal

    Just like cars, refrigerators and houses, the quality of what you purchase is not perfect. And you should not expect software quality to be perfect any more than you expect your car to be perfect. The more money you pay, the more quality you get. It's an asymptotic approach where increasing quality costs a lot more money.

    Just because of a long-standing close relationship with mathematics, people buy into the idea that software should be as ironclad as a theorem.

    It just ain't so.

    Real software becomes complicated, much in the same way that PDE's governing real physical phenomena become complicated. Small pieces of software can be verified for correctness pretty easily, but complicated interacting pieces of software rapidly will exceed your resources to check for behavior under all circumstances.

    There are so many ways for it to behave and misbehave that closure is a process of endurance, enumerating and testing as many options as possible under as many likely and important conditions that you can think of.

    At some point, you decide that you've reached an acceptable level of quality (does our regression tests and stays up and running for 99.99% of the time for the sample of typical users) and release the product.

    [Bill Gates is another matter altogether. I think he's responsible for some distortion of the software marketplace and, thereby, responsible for software not needing to be up to higher standards. That said, however, even without his influence, software will never be up to perfect standards.]

    • by sphealey ( 2855 ) on Tuesday June 18, 2002 @09:15AM (#3721680)
      Just like cars, refrigerators and houses, the quality of what you purchase is not perfect. And you should not expect software quality to be perfect any more than you expect your car to be perfect.
      Get a refrigerator from 1950, another one from 1970, and one from 2001, and set them side-by-side. Make sure each one is the basic model, with no fancy gee-gaws or "futuristic controls".

      I submit to you that the 2001 refrigerator is approaching perfection. Thermodynamic efficiency is approaching theoretical maximum, reliability is approaching 99.99999%, sound is down to essentially nothing, and the price in real dollars is about 1/10 that of the 1950 model.

      Why? Because refrigerator makers (like auto makers) made a committment to improving, and attempting to perfect, their product.

      Now, you can say that software hasn't been around as long as refrigerators, which is probably true (although it has been around since 1940, and the quality of what was done in the 1970s is often better than today's). However, the profit margin on software is also tremendously higher than that of white goods, and the rewards for management much greater. Yet the software industry refuses to clean itself up.

      Oh well.


      • by catfood ( 40112 ) on Tuesday June 18, 2002 @09:27AM (#3721745) Homepage

        But the refrigerator does exactly one thing, and the interfaces are perfectly standardized. It's not programmable, and it's nearly impossible to use incorrectly. The perfect refrigerator is not a moving target. And the money you put into design and quality control in 1970 is still paying off now.

        Hell, if software just had to do what it was doing in 1970, it would be more perfect than refrigerators.

    • First of all, Microsoft software does stay up for 99.99% of the time for a sample of typical users -- typical users who don't aggressively look for remote exploits.

      Anyway, I am wondering how complex a car would be considered vs. an operating system. For example is an OS roughly as complex (therefore as hard to get right) as a car...or is it more like 10 times as complex...or maybe 100 times as complex? I would say it is more like 100 or 1000 times as complex.

      Remember cars aren't perfect either. Almost every car Consumer Reports tests has a few "sample defects" in it (something they could have worked out in the manufacturing process with more time/money/care/design), plus they have "bad design" (unclear controls, etc), and some of them have real "bugs" (occasional stalls, hunting for a gear), and then some have real major bugs that result in recalls.

      - adam

  • I believe commercial software is bad because the companies and programmers have no real incentive not to make it so. I believe part of the problem is not the gap between the market leader but the gap in the corporate org chart where the techies meet the technots.

    The level of people that SHOULD care about high quality don't understand enough. Not only to they not push for high quality code, but the push the other direction entirly.

    Scale of big vs. small means nothing. I have seen some fairly high quality open source projects with a programming team smaller the their commercial competitors secretarial pool.

  • by gelfling ( 6534 ) on Tuesday June 18, 2002 @09:10AM (#3721641) Homepage Journal
    Software likes to think of itself as 'engineering' but it's not. It's not structured, it's not methodical, it's not repeatable, it's not quanitatively quality controlled, it's not maintainable, it's not documented correctly, it's not impervious to new flaws after it's finished, it's never finished.

    Project managers don't, requirements assessments can't, cost estimates are from Mistress Cleo. Nobody understands what success is supposed look like and no one can tell the difference between success and failure.

    It's neither mass produced art nor is it artistic engineering nor is it special or inciteful. It's an ordinary product made by people who have to be extraordinary simply to overcome all of it's other failures. It's the dancing bear - interesting not because it dances so well but because it dances at all. It is a controlled crash.
    • by sphealey ( 2855 ) on Tuesday June 18, 2002 @09:24AM (#3721727)
      Software likes to think of itself as 'engineering' but it's not. It's not structured, it's not methodical, it's not repeatable, it's not quanitatively quality controlled, it's not maintainable, it's not documented correctly, it's not impervious to new flaws after it's finished, it's never finished.
      Project managers don't [...]
      Well, it can be (think aircraft control systems). It just generally isn't. Which tells us that there is some reason(s) buyers don't want well-engineered software.

      Those reasons probably are (a) first cost of purchase (b) competitive advantage to be gained by using something "good enough" sooner rather than something perfect later.

      Which doesn't excuse the behaviour of software suppliers, but the question is more complex than it appears.


  • TV is critical?? (Score:2, Interesting)

    Unbelievable that we should take seriously the complaints of TV, which drowns us in commercials, covers us with misinformation and biased reporting and is soft on corporate abuses until they reach the Enron-like level that can't be ignored.
    While all software contains bugs, and it may be impossible to root out all bugs in adequately complex programs, most software does it job almost all of the time. My word processor processes words, my spread sheet spreads sheets of numbers and my browser allows me to browse. These are MUCH more reliable than TV!!
  • by ThomasMis ( 316423 ) on Tuesday June 18, 2002 @09:10AM (#3721645) Homepage
    I'm against this notion that people want good software. As a software consultant, who has been involved one way or another in a varienty of fields, I can say with authority that companies want software *cheap* not *reliable*. When companies want reliable and secure they pay for reliable and secure. Companies have an absolutely unrealistic expectations of what can be done in a short and cheap development cycle, yet that's what they demand from their consultants. I have an client (a rather large health care provider) that still hasn't changed the default password to the publically available administration section of their system... which is more common than one would care to think. This is a testiment to how high companies consider security important.
  • by AdamBa ( 64128 ) on Tuesday June 18, 2002 @09:11AM (#3721650) Homepage
    It's a good overview of current gripes about software, but the article is mish-moshing a lot of things together. For software, it talks about embedded control systems, operating systems, compilers, medical machines, and web servers. For what constitures a bug, it talks about bloated code, ugly code, inefficient code, badly designed code, buffer overflows, bad algorithm implementation, incorrect handling of badly entered data, and of course the ultimate in cataclysmic chaos -- an app that generates unnecessary Windows messages. For how to fix things, it mentions component-based design, exhaustive review of source code before compiling, better initial planning, better programming tools, highly-typed languages like C#, better measuring tools, and never deferring bugs. For the goals that should be aimed for, it talks about usability, reliability, cost effectiveness, and maintainability.

    So that's all fine and dandy, but it's not like you can just take one from each column and have something that makes sense. For example, were bugs in an operating system due to inefficient code that would be fixed by component-based design with an eye towards cost effectiveness? Well, uhhh, maybe, I think.

    It didn't help that so many of the people quoted had no idea what they were talking about, and the ones who did had their quotes taken so far out of context that they made no sense. It seems a lot of people who never worked at Microsoft know how Microsoft develops software. Oh well.

    It would make more sense to talk about a particular class of software and bug and then discuss why it is there. E.g. why do Microsoft systems products have buffer overflows. Even then you would get a bunch of different answers.

    - adam

    P.S. Comment first posted by me on Techdirt [].

  • Software engineers know that their code is often riddled with lacunae, and they have long been searching for new technologies to prevent them.

    From []:

    lacuna lacunae
    1. An empty space or a missing part; a gap: "self-centered in opinion, with curious lacunae of astounding ignorance" (Frank Norris).
    2. Anatomy. A cavity, space, or depression, especially in a bone, containing cartilage or bone cells.

  • In the spirit of "the glass is half full", Steinberg recently released a new version of their music software "Cubase" and, on the very day it was available, released the "x.1" patch. Yes, some of you "the glass is half empty" people will say they should have waited on the major release, but I say this is a step in the right direction.

    And until we're all running the exact same hardware I think we're going to have to settle for "less than perfect" from the software industry. When there's a bug with every sound card on the planet I fault the software company's lack of testing/research. When it doesn't work with a sound card only 116 people on the planet own, it's still listed as a "bug" and, lumped together with the other statistically insignificant "bugs" looks awful when reported together.

    Finally, to all these estimates of how much $$$ "bad" software is costing....How much would it cost WITHOUT the software? Do you really want to jump in the WayBack machine and return to the glory days of a totally manual world where every problem was described as, "It's somewhere in the secreatarial pool?"

    • by EvlG ( 24576 )
      Patches like this come out because the company does QA after signing off on the master copy sent for duplication.

      Its like this. You sit down a few months before release and determine what bugs MUST be fixed before you can go into duplication. Then you also determine what bugs you will fix in the first patch, which will be available within the first week or two of release. These are less critical fixes. Then you also determine what to work on after that.

      Its a matter of priority - if they delay the release to fix all the bugs, users get unhappy, and eventually go to competing products.
  • exactly! (Score:2, Informative)

    "At Microsoft, he says, corporate customers often demanded that the company simultaneously add new features and stop adding new features. "Literally, I've heard it in a single breath, a single sentence. 'We're not sure why we should upgrade to this new release -- it has all this stuff we don't want -- and when are you going to put in these three things?' And you say, 'Whaaat?'" Myhrvold's sardonic summary: "Software sucks because users demand it to.""

    This sums up the state of ICQ. I stuck to 99b for a very long time, then tried 2000a to alleviate the connection problems and then dumped it for trillian []. If they had developed from 99b into what LICQ has instead of their AOLised crap, maybe I would have kept with the official client.

  • the "code now and fix any bugs latter" mentality is what CS students in their first 2-3 years in a CS program are taught... do you know how hard it is to get a group of people to break out of that mentality. Where I work, you see a lot of lets "code now (with perl) and glue it together and pray that it works, and if there's bugs, apply a quick fix" Which is fine, until you have a complex program such as a data pipeline...
    Also, we have end-users screaming at us for software... they don't care if there are bugs, becuase they assume we can fix them over-night. End-users like software released often and perfect.
  • is like creating a car that doesn't crash.

    Oh wait, you can do that; it just means it won't run.

    So I think it explains itself.
  • Having worked in a few software companies, my experience has shown me one main reason why software is so bad is the release schedules proposed by most managers is a complete joke.

    Not enough time are put in requirements, developers have no time to finish/do/think through their code, and QA is left with little time to properly test. If QA even gets it...

    Then you have marketing infusing their "must have features" that are sometimes outrageous to implement, yet they demand it saying it's consumer driven, it MUST go in or the customer won't buy it.

  • by JediTrainer ( 314273 ) on Tuesday June 18, 2002 @09:22AM (#3721721)
    What about software that breaks because of buggy hardware?

    It's not uncommon to have buggy processors (the article seems to think they don't exist), cheap and buggy motherboards, bad memory that needs to be replaced, crappy video cards and knockoff sound cards that don't work.

    If the software crashes under these conditions, from the user's perspective it's a software bug. But how can the software be expected to compensate for every single thing that can go wrong if that includes calls to hardware which itself might create the error?

    Also, you can also have perfectly-written Java code which could cause the JVM to crash. I've had users call me to complain about that, but there's nothing I could do - my application didn't crash, but the VM cored.

    So many times I'm encouraged to try it in client mode, try it in server mode, try it in interpreted mode if something crashes. A Java application can theoretically behave quite differently under each.

    The Java VM is like hardware to me - I have no control over it yet my code depends on it, and a bug in it could break everything. User perception is that it's MY fault. Sun has fixed in their new release of JDK1.4.0_01 recently.
  • "Literally, I've heard it in a single breath, a single sentence. 'We're not sure why we should upgrade to this new release -- it has all this stuff we don't want -- and when are you going to put in these three things?' And you say, 'Whaaat?'" Myhrvold's sardonic summary: "Software sucks because users demand it to."

    Users are saying "When are you going to make this *work*?" And it ain't just Microsoft's software either.
  • by SirSlud ( 67381 ) on Tuesday June 18, 2002 @09:25AM (#3721732) Homepage
    In my experience, a poor process for 'agreeing' on requirements in code and requirements in design is responsible for programmers going about problems in a half assed way. No programmer likes to write specific, bug safe, optimized code, only to have the marketing team call a meeting one day and announce a new 'direction' that will need lots more 'features' in the app or service. So, programmers write extensible, maintainable, but ultimately 'loose' code that is suspecible to data input and use case errors.

    Programmers are experts, but I've met very few manager-type people in non-niche markets who drive requirements and design committments in such a way that it makes programmers really wanna get down and spend their time writing bullet proof code. Often, they end up just having to mangle it because of the 'moving target' syndrom of requirements and features, hack it, or rip it out before the final version ships, which is mucho demotivating and does not really encourage programmers to write bullet proof code.
  • by Cereal Box ( 4286 ) on Tuesday June 18, 2002 @09:29AM (#3721753)
    In other engineering disciplines, there is little room for error and your mistakes are readily apparent -- you screw up, and you'll probably wreck a few million dollars worth of equipment during testing or kill someone when the product ships. Software engineering, on the other hand, allows the mediocre on the team to hide behind truly talented individuals.

    Code doesn't work? No big deal, just fiddle around and recompile. Still doesn't work? The other guy will probably fix it. Product's shipping and the problem still isn't fixed? Eh, who cares? It's not going to kill anyone, and nobody will notice.

    It is precisely because no one can "see" the shoddy workmanship of programs that such behavior exists (and I'm not saying open source programs are immune to this -- patching a crappy open source program is akin to patching up a crappy car engine with duct tape and staples). All those slackers who couldn't code a binary tree to save their life and were generally mediocre college students are writing the software you'll be using. Their mediocrity is hidden by the anonymity and zero-accountability inherent in large software projects. Essentially, they're doing the same thing in the real world as they did in college -- slack off and hope nobody notices.

    This, folks, is why colleges need to implement tougher CS curriculums. This is why you need to be able to write code on paper. This is why colleges insist that you don't collaborate on projects in lower-level CS classes. This is why there shouldn't be curves that allow mediocre students to graduate with a CS degree when they should have been weeded out during their freshmen or sophomore year.

    I'm almost finished with my CS degree, and it's depressing, even at this level, how few students there are who really have an understanding of and interest in computer science. Most of the students enrolled in CS at my school have never coded before college. The most popular reason for choosing CS? "I used to make webpages, and I figured it would be easy." No joke. Of course, this sort of behavior isn't strictly limited to CS -- I've met more than a few EE students (freshmen, admittedly) who couldn't identify basic electrical components, didn't know Ohm's Law, and chose EE because "I used to take apart telephones and put them back together, so I think electronics is fun." Inevitably though, these clueless students who enroll in other engineering disciplines tend to migrate over to CS since it's not as "balls-to-the-wall" difficult as say, EE or ME.

    In short, software "sucks" because our colleges are allowing mediocre students to slip through the cracks into the professional world. Personally, I feel that the CS curriculums should tighten up a bit and put more emphasis on solo projects (and moderately challenging ones, at that) and writing code on paper at the lower levels. A message has to be sent to those students who want to be engineers but don't really have what it takes that CS is NOT an "easy major". Perhaps then it might not be the haven for slackers that it has become.
    • In other engineering disciplines, there is little room for error and your mistakes are readily apparent -- you screw up, and you'll probably wreck a few million dollars worth of equipment during testing or kill someone when the product ships. Software engineering, on the other hand, allows the mediocre on the team to hide behind truly talented individuals.

      What a bunch of self-congratulatory, arrogant bullshit. Only a student can come up with this kind of geocentric philosophy on programming. You are not a unique snow flake. You are part of the same rotting, organic, compost heap that makes up the rest of nature. Can I get you a cup of hot cocoa to make it feel better?

      If you think the intellectual pyramid of programming is bottom heavy in college, wait until you cash your first paycheck. One of two things will happen at that point in your life: 1) You have an epiphany that no matter how skilled you are, other people, far too deep into the fog to know what a binary tree is, will determine how well your work actually turns out, or 2) You will cast yourself as an agent of change, lay down stringent guidelines for how things should be done, and everyone else will ignore you in order to meet deadlines.

      Either way, you will be miserable and burn out in no less than 2 years after graduation.

      This, folks, is why colleges need to implement tougher CS curriculums. This is why you need to be able to write code on paper.

      If you want to spend time trying to out do Dijkstra or develop the better finite state machine, stay where you are. Academia is for you, more than you know. If, however, you want to create solutions to problems, other people's problems, their business problems, then sit down at the table and have some humble pie.

  • by Zamfir ( 585994 ) on Tuesday June 18, 2002 @09:31AM (#3721771)
    While there is plenty of truth to the problems of lack design, poor coding practices, etc. there are other factors - just as important - that contribute to the state of software today. many companies have product plans that are put together a year(s) or more in advance, and there is tremendous pressure to meet those dates. rush your time to market and quality is going to suffer every time. thus, buggy commercial software is often the responsibility of executives as much as developers.
  • by RailGunner ( 554645 ) on Tuesday June 18, 2002 @09:37AM (#3721801) Journal
    It's not just 1.0 versions of software that suck, in at least one case (because I worked there) it's later versions.

    As a developer, I've seen this happen first hand, but in most cases to blame the engineer is incorrect. In my case, pointy-haired boss types pull a deadline out of their asses and expect the Engineering team to hit the deadline. What happens then? Well here's one quick anecdote.

    The company I used to work for decided in February of last year that we would ship version X.2 (where X is greater then 4) of our software package at the end of June. Only problem was, there were still approximately 10,000 known bugs, and the only reason to ship in June was to announce the release at the company sponsored trade show. That, and there wasn't a single engineer asked for an esitmate, unless you count the moron owner who thought he was a developer and was notorious for being way too aggressive in estimates (among other bad habits, like not even building his code before checking it in to the source control system).

    Clearly, there was no chance in hell we were going to hit the deadline. Management's solution? Mandatory unpaid overtime. 15 hours a week. All requests for vacation were denied until the product shipped.

    To make a long story short, 2 developers quit (myself being one of them), 2 were laid off because they didn't have a new version to sell because X.0 was such a piece of garbage for a lot of the same reasons.. and the company finally trotted out version X.2 to very little fanfare with 3000 known serious defects still not addressed.

    And, like X.0 before it, it's a POS - a piece of shit. Engineers get burned out when they are overworked just like anyone else, and are forced under threat of termination to make poor decisions to keep their jobs. Management then oversees the creation of a poor product and then are completely oblivious that they are the root cause of the problem. Instead, the development department gets blamed and in this case the director got canned. (When really all he did was take his marching orders from the owner. No authority to make decisions, and yet they held him accountable.)

    The truly sad thing is, all this can be avoided if management would just back off and let developers do their job without micromanaging and shoving their nose to the grindstone, spending the investment capital to pay your employees overtime when appropriate, staffing up your Quality Assurance department (5 Analysts testing code put out by 10 engineers is not enough by a long shot) and not releasing it until it's ready.

    One excellent software release can make your company very rich. One poor software release can kill your company. (And in the case of the company I used to work for, I must admit I hope that happens. The world would be a better place without that third rate company run by a fourth rate pompous jack-ass developer who thinks he's above you just because he went to an Ivy League school, and you just went to the local University.)

    And don't even ask me to name the company or the product, I won't, I still have close friends that work there. Even if I do wish they'd quit drinking the Kool-Aid..

    • Sounds way too familiar. My company made the plunge into .NET last fall for a product that is shipping this week. I was brought on to lead the development; however, was given absolutely no control over the design of the application. The project was lead by a group of people who have never done web design a day in their life and they were making the design decisions. When something goes wrong or we hit a roadblock, the developers get blamed but management doesn't realize that the fact that they won't let their developers spend 5 minutes on design or planning is the main cause for all the problems.

      In my opinion, the reasons there is bad software is 99% management's fault.
      1. They think they can make decisions on how to write software when they don't know anything about it. I even know a manager that has a secretary read/write his email because he can't use a computer. He has a monitor on his desk with a color printout of a web browser taped to his screen as a joke (no kidding).
      2. Requirements gathering needs a lot of improvement. How many times are the requirements written by the same managers I just described above? The managers don't understand how or why these requirements are even necessary and when you ask them to elaborate or get more information from the customer, they don't think it is necessary. They just make something up, tell you some BS, and never ask the customer. In the end, the developers have to go back and change everything and management gets pissed when it takes twice as long to make a huge functional change than it did to put it in in the first place. They don't understand why and once again, the developer gets blamed.
      3. Management thinks developers are stupid. They don't look at their developers as experts in the field, they look at them as grunts just implementing their product. When a grunt asks a question or makes a suggestion, management turns their back and sticks their nose in the air. What could a developer possibly have to say that means anything to their bottomline?
      4. Management never asks their developers for an opinion. They consistently make estimates based on buzzwords instead of asking their development team for input. How could a manager with no development experience possibly make an estimate without knowing what has to be done?

      IMO, there needs to be a layer between management and the development team or management needs a degree in computer science. If a manager doesn't understand what it means to develop software, how can they expect to support their team and manage the project?

      In the end, management thinks their development team is incompentant because the project didn't go smoothly and thd developers get burned out because they aren't allowed to use their skills and are forced to brute force a piece of shit product.

      Has anyone successfully overcome these obstacles with management? What is the course of action to make management realize what they are doing wrong?
  • by Otter ( 3800 ) on Tuesday June 18, 2002 @10:00AM (#3721986) Journal
    Developers make what users want. When was the last time you saw a bug in the code running your microwave oven? In some contexts, desktop computer use being a primary one, users value new features over small changes in stability and consistency. And that's what they get. A couple of weeks ago, Microsoft came out with a new version of Office.X, fixing a lot of bugs in the original version. Do I wish they had held off on releasing it until all those fixes had been made, leaving me without a native OS X word processor and spreadsheet for a year?

    On the other hand, in applications where stability and predictability are far more important than new features, software quality is excellent.

    Automotive metaphors for computing are almost always useless but since the article relies on one -- cars may run reliably, but the AM/FM radios they put into them are frequently useless. Does anyone complain that the automotive industry included them for decades, instead of waiting until cassette/CD players were available?

  • by BigTom ( 38321 ) on Tuesday June 18, 2002 @10:06AM (#3722037) Homepage
    Will people stop spouting off about needing production line reliability in software development.

    The software equivalent of car manufacturing is stamping a CD. It's very reliable. What software developers do is design, not manufacture.

    The problem is that they ship half baked and unfinished designs (that they call products) without really thorough testing and refinement.

    Have a look at the concept cars from an automobile design shop. How reliable and safe do you think they are? Its only after a couple of years of prototyping and testing that they have a design that they would risk manufacturing.

    The problems with software stem from manufacture being too easy, not too hard.
  • by MountainLogic ( 92466 ) on Tuesday June 18, 2002 @10:07AM (#3722040) Homepage
    The auto industry could build a car for under $3000 , but it would not sell. Who in the western world is going to buy a tin box on a lawn mower for a car. These same companies could build large, long lasting, quality, safe 150 MPG cars that we would all love to own, but who is going to pay $500K for a SUV made from graphite and titanium?

    Software companies could build a rock solid word processor or PIM , even MS, but no one will pay for it. We all scream that the retail price of MS Office is far too much. The corporate world looks at the per seat cost of MS and say, "I wish we could switch to something less expensive." Every product has a price point and software has a very low price point.

    The odd part of the problem is the marginal cost of production. As we all know, once the development is done it cost next to nothing to produce. Once a producer has a product that the market will pay for there is little incentive to keep droping millions into making it much better. We would all love to use perfect" software. If "perfect" software can only be done using "traditional" engineering approachs such as is used in aircraft design that means putting massive teams on a word processor. Each team does one function including the code, hand checking the machine output from the compilier, checking it's performance againsta massive design document. We all know the story of how this kind of effort almost sunk IBM. Computer science has progressed to the point where massive effort should be able to be implimented, but no one would be willing to pay for it.

  • by weave ( 48069 ) on Tuesday June 18, 2002 @10:09AM (#3722048) Journal
    How can we be surprised, when Microsoft has been heavy pusher of the LACK of need for a formal university degree. Why spend 4 years in a Computer Science program when you can spend a few grand, take a crash course, and get your MCD or MCSE certificate in a few weeks?

    In fact, I remember Gates several years ago bragging about how he prefers not to hire CS grads because they come out of school with too many limitations programmed into their brains.

    Yeah, limitations, like how to write good code, how one should avoid side effects in functions, write black box functions, learn how to develop testing functions to push a full range of possible inputs to functions to test them, how to document properly, etc, etc.. You know, all that stuff that cuts down on the number of lines of code per day a programmer pumps out...

  • by Sloppy ( 14984 ) on Tuesday June 18, 2002 @10:22AM (#3722151) Homepage Journal

    Popular software isn't reliable, because reliability isn't the highest value. Compatability with a legacy is (e.g. you want to run this application under MS Windows?). Or cheapness (e.g. Do you want to be billed 2 hours of my time (very little testing) or 6 hours (more testing)?). Or having lots of features (Would you like a flight simulator with that spreadsheet?). Or something else.

    When reliability is important, you can have it. But it will cost you. Most people consider the cost to be too high. That's why more people run bleeding-edge Linux, Windows, or MacOS, than OpenBSD.

    And there's nothing wrong with that. You just have to accept/enjoy the power/responsible that goes with the choice that you made, instead of whining that someone else should have chosen for you.

    Irresponsible XP users whining about XP, ispartcularly pathetic. Yeah right, you didn't know what you were getting into. You never heard of this "Microsoft" company before, so you just assumed that they valued reliability over other considerations. Discovering that it was crap primarily intended to play video games and keep MCSEs' jobs secure, was like a cold knife in the back -- such unexpected treachery!

  • I love subtle ads (Score:3, Insightful)

    by drew_kime ( 303965 ) on Tuesday June 18, 2002 @10:36AM (#3722249) Journal
    Some software companies are responding to these criticisms by revamping their procedures; Microsoft, stung by charges that its products are buggy,
    is publicly leading the way.

    But I thought they were asking us where we wanted to go today.

  • I'll tell you why! (Score:3, Informative)

    by newerbob ( 577746 ) on Tuesday June 18, 2002 @10:46AM (#3722315) Homepage
    1. The standards for what constitutes a "software engineer" have been lowered because of the Web.

    2. Companies don't want to pay enough $$$ to hire what really counts---EXPERIENCE---so they hire low-cost H1B programmers instead.

    3. There's rampant AGE DISCRIMINATION so older experinced software engineers stop prorgamming and become managers, or go into other fields.

    I joined an R&D group when I turned 40, after spending years managing software products that have earned billions of $$ in revenue cumulatively over the years. Why? Because I didn't want to be forced into managing products staffed with inexperienced and inexepensive programmers, or be involved with shipping non-glamouous tasks (device drivers, etc) to India.

  • by Kefaa ( 76147 ) on Tuesday June 18, 2002 @11:03AM (#3722475)
    Quality is important, but how we use software is more important in our buying decision. They made a good point that given the plus side of the equation, most software is worth what you pay for it. Otherwise, people would not buy it.

    Quality however is not free and the consumer must, in almost all business equations pay for it. In the case of dropping a Space Shuttle on Atlanta, our willingness to pay for additional quality controls is going to be much higher than testing a text editor.

    Using the automotive analogy, I want my car to go 250,000 miles without any upkeep (oil changes, filters, etc.) The diffence in the engineering is that no one considers the auto example reasonable but they do with software for which they are paying 1/20th the price.
  • by Junks Jerzey ( 54586 ) on Tuesday June 18, 2002 @11:11AM (#3722536)
    I'm seeing lots of comments about how software isn't "engineering" or a "science." Well, I hate to break it to you guys but engineering is just as much hackery as anything else. Yes, there is some science to figuring out how much stress a material can take, but it's not like you can mathematically prove that an airplane is safe. Products are recalled all the time because of oversights and design errors. And planes do crash because of mechanical failures. Aerospace engineers are more afraid of flying than the general populace.

    I see two big problems with modern software. The first is that computer systems are much, much, much too complicated, to where people accept lines like "no sofware can be bug free." Sure it can! How depressing it is that we let that be spood fed to us! But not when you have a huge operating system and huge language libraries and huge OS libraries and huge hardware drivers and so on. Heck, there's more code in one of Nvidia's drivers than in OSes from the 1970s. You see many fewer bugs on less complicated platforms, like game consoles and PDAs. PCs are pretty much a lost cause in that respect, and that's not going to change. One day I hope that we can return to more reliable systems, even at the expense of expandability (who cares about expandability any more?).

    The second problem is simply that most developers don't give any importance to producing reliable software. In the telecom business, there's no way you could getting away without writing comprensive test suites and a huge amount of work from a dedicated testing group. But you hardly see automated testing for any software these days, outside of embedded systems. And you'll see silly newbie developers argue that they need to use C++ to write some silly app because "it is faster," when they actually should be using Python or Lisp instead.
  • Sorry... (Score:3, Funny)

    by Art_XIV ( 249990 ) on Tuesday June 18, 2002 @11:15AM (#3722555) Journal

    I don't have the time for an intelligent comment on this...

    One of our sales people promised that we'd have this project done for the end of June.

  • by bons ( 119581 ) on Tuesday June 18, 2002 @12:17PM (#3722983) Homepage Journal
    Let's start off by getting through the obvious. I'm a developer, a purchaser, and a beta tester.

    The first truth of software development is that customers demand software immediately. They are not willing to wait for bug free versions to come out, or more accurately, those willing to wait are not nearly as vocal as the ones who want it now.

    And the beta test, well, that's just a nightmare in itself. Between the number of beta testers who break NDA agreements, the ones who give their friends a copy of the beta test, and the ones who couldn't write down how to duplicate a problem if their life depended on it, it's amazing any progress is made at all during the beta test.

    And all of this hinges on those peices of closed source software that the new software has to interface with. Finding out that Windows doesn't like you code is one thing, but chasing down some driver is much worse. And the people who write drivers and Operating systems have it just as bad, testing with released closed source products and hoping they work.

    Yes, there is no silver bullet, but there is a large clip of small bullets that we need to learn how to start firing. We need test cases, documentation, standard interfaces, a complete removal of "hidden features" (unofficial functions that software developers rely on), and most importantly, a customer base that can all agree on a balance between "now" and "right".
  • by pyrrho ( 167252 ) on Tuesday June 18, 2002 @02:44PM (#3723990) Journal
    If you don't buy Gates' ad-hocking promises of redemption there are other solutions, like creating a programming language that forces good code;

    Or a better bet would to just find the Fountain of Youth so you can drink it's water, stay forever young, and then you'll have plenty of time to fix the bugs in the real languages.
  • The problems associated with software production are unique in the world of engineering, and are mostly due to the compression of time we used to call "Internet Time." Consider the difference between software engineering and, say, civil engineering, i.e. bridge building.

    1) The basic way bridges work have not changed in some time. Suspension bridges all work on the same basic principle. Software, on the other hand, is constantly changing from a theoretical standpoint. In the four years I've worked as a programmer, I've moved from procedural programming to client-server programming to web programming back to procedural (only this time with an object oriented tip) and the outlook is to move into a new paradigm. That's like designing a bridge for six months, then working on a tunnel, then moving up to a tressle.

    2) Hardware is constantly changing -- meaning that APIs are constantly changing to add features and products that use those APIs have to change as well to keep "up to date." A bug in the hardware would cause a bug in the api which would cause a bug in products that use it and so on. In the bridge building world, there are only a few materials and it's easy to see if there's a flaw in them. If you've got a hunk of frayed steel cable, you don't try and wrap it with something to offset the throw away the cable and the vendor eats the cost.

    3) In the world of software engineering, the only engineering that occurs in most companies is low level, under the hood stuff. Basic usability design is often provided by non engineers -- marketers and well meaning product managers. This is a bit like relying on the guy who tells you what color to paint the bridge to make structural decisions. Marketers may know what sells, but they don't know what makes good software. And this is one of the main reasons for the dot com bust.

    Now, nobody's proved that Time to Market is a factor in product success. In fact, waiting to do something right often proves much better. Apple dropped the ball on usability with the first rev of the Newton, and three years later a more mature Palm destroyed the proposed market for PDAs. Windows based PDAs are finally reaching the point of stability, speed and robustness that they will take the ball and run with it -- after nearly 4 years on the market.

    Good software takes time and elegant design. Nuff said.
  • by magi ( 91730 ) on Tuesday June 18, 2002 @03:30PM (#3724350) Homepage Journal
    One reason that I've very often seen lead to failed projects is assigning them to people who simply can't do them. Not necessarily because they don't know anything about programming, but because they don't know the tools they have to use.

    Years ago I was assigned a UNIX - MS Access integration project where I had to translate EDI messages to Access tables. I had never worked with Access before. I told my boss that I can't do it in reasonable time, but there wasn't anyone else free at the moment, so I was forced to do it. The result was that after three months of coding, $100/hour from the customer, I had learned to program with MS Access - by learning how not to do it. I burned out and quit. The horrible software was probably rewritten from scratch.

    I have seen many really horrible examples of similar situations with other programmers, often with people dabbling with C++, lately with people who simply don't know how to program with C. Oh, what incredible examples I could give you! The result has been indescribable garbage. The garbage often works in the planned test cases, barely, but bleeds memory like a pierced pig and crashes from a slightest variation.

    Many of these catastrophies occur because the programmers do not honestly admit: "I can't do this." And even if the programmers would admit, their managers won't when dealing with the customers.

    All tools require learning. Some have a soft learning curve, some steep as a mountain. It doesn't matter much how professional one is, when it comes to learning new, conceptionally very different tools. Managers don't often understand this.

    Just as often, programmers are assigned to projects of which they do not have a clear vision, usually because of too superficial specifications. Without proper vision, they can't find the right attitude to write beautiful, perfectionist code. They need inspiration, and finding it often takes time.

While money doesn't buy love, it puts you in a great bargaining position.