Slashdot Mirror
Calling Software Reliability Into Question
phillymjs writes "CNN is running a story on software reliability, and how the lack of it may cost more and more lives as technology creeps further into everyday products. It appears a debate is finally starting amongst everyday (read: non-geek) people about vendor liability for buggy software. Some opponents of the liability push are unsurprising: Says the story, 'Microsoft contends that setting [reliability] standards could stifle innovation, and the cost of litigation and damages could mean more expensive software.' The article also says, however, that consumers' favortism of flashy products over reliable ones is partly to blame for the current state of software."
I agree. Users want cutting edge, not reliability.
Hence Debian is less popular than you might expect.
Well, based on all the software I've ever seen, pretty damn hard.
TODO: Something witty here...
IMO if a company is unwilling to supply you with the source code (under whatever license) to let you see and fix problems that exist they should have no possible exemption from litigation, no matter what POS EULA they persuade you to sign.
They are asking you to place your trust in them that their code is good enough to bet your business on. If their software is not all it's cracked up to be and you had no chance to check their claims (but instead had to take their word for it) then they clearly are responsible for breaking their word.
Unless they told you that it was a buggy product that you couldn't rely on in the first place... now that would make for amusing adverts.
(Can you imagine Windows boxes with cigarette-health-warning style labels on them saying "The Computer-General warns that this product may be bad for your business.")
Beep beep.
And yet those IT staffs who run mainframes are quite willing to install NT servers running IIS or SQL-server and put up with Microsoft's poor security and stability. Where's the sense in that?
Isn't the trend towards "flashy products" rather than reliable ones the same reason why current marketing pushes sex rather than product qualities (Pepsi, A&F, etc), movies flaunt big-name actors and actresses, and people won't go see a movie unless it has a high PG-13 or R rating (PG? It's got to be boring). This is the same reason why Legos now has 3-piece dumptrucks and 8-piece Hogwarts castles. Why is this? Dumbed-down education? Why is it that people have just started to gobble up whatever the media tells them rather than understanding what they need for themselves. *sigh* What's society coming to?
I hate liberals. If you are a liberal, do not reply.
I'd say that most non-geek users are completely ignorant of software reliability. A computer just has errors. They have grown to accept that. To them that's why they have a warranty and that's why tech support exists. The typical windows 9x users believes that a restart is the natural second step to every click or change they make. I knew a girl that thought an illegal operation meant she could go to jail (for what she did not know.) So the first step in making software companies more reliable and more accountable is educating the common users. If people know what they are getting is bad their excuse wont be that Dell sold them a shitty computer, it will be that Software Maker X sold them buggy crappy software. Until then companies like Microsoft will run-amuck.
This is part of the reason that much commercial software has so many problems. The consumer wants their programs cheap and they want their programs released two weeks ago. Sacrifices in the development and testing cycles are constantly being made in order to bring the product in at a lower cost and in a shorter timeframe.
I hate liberals. If you are a liberal, do not reply.
"However, the day that cities decide to have a central server run the traffic lights so they can...say, control traffic around accident areas...things will go wrong. "
Actually I wouldn't be surprised if traffic lights aren't already centrally controlled in some urban areas.
Traffic lights have a human safety factor, in the event of bad instructions they can fail over to flashing red in all 4 directions. Humans are trained to understand that flashing red means stop. So the worst case, that the lights are signalled green in all four directions at once can be mitigated by throwing an exception and falling into the flashing red mode.
"I don't see this so much as software causing problems as much as the tendency we have to make what used to be simple things really complicated."
KISS should always be applied. The simpler a system, the more reliable it will be.
However, as technology improves over the years the barrier which defines simplicity increases. Traffic Lights 100 years ago were manually operated, today they are controlled by sensors monitoring traffice flow.
"The idea that we depend on something that's inherently untrustworthy is very frightening," he says.
This is such crap. Software is not inherrently untrustworthy. The fatal incidents cited all appear more due to human error rather than software bugs, as has happened since man started building machines.
If software was so inherrently buggy no one would get on a plane or dare trust a traffic control signal.
As for making manufacturers liable, you can but I would expect a negatibe response rather than an improvement. I am in favour of anything that improves software quality but I think what is most overlooked when people talk about 'buggy' software is logic errors, and misinterpretation/misexplanation of user requirements. If the developers/manufactures are to be held liable should we not then turn around and litigate against the subject experts who helped build the use case's?. What about the users who misuse/abuse their software causing unexpected results or loss?
If developers/manufactures do become liable then the insurance and testing costs will probably drive the price of software beyond the reach of the individual.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
This is what Microsoft is, quite rightly, afraid of. If I can sue Microsoft for $100k because IE crashed, MS isn't going to have time to do anything except fix bugs. This isn't even entirely their own fault, since the nature of programming makes it impossible to write any large program without bugs. And unless you grandfather all of MS's products, they'd be screwed.
But this is even worse. Unless the laws are written to special-case free software, we might see Linus sued because Linux crashed one day. RMS might end up $15m in debt because Emacs ate somebody's email. How's that for stifling innovation? If I (personally) might get sued for some bug I missed, there's no way I'm going to give away my programs.
The guy in the article advocates only a limited sort of liability: you're liable only up to a point, or only if you don't divulge the bugs you know about. But does anyone out there really think the politicians, who are more in the pocket of trial lawyers than of anyone else, are going to make it hard to sue?
"Adding new features like embedding full-length motion pictures into Word documents (apologies to Neal Stephenson) is one kind of 'innovation,' but it comes at the cost of gains in stability."
So if you mounted a rocket on your car to help with acceleration but you knew that one out of every ten uses it would completely fail and likely destroy your car are you innovating or are you being stupid? Innovating is when you add a feature and it just works. When Microsoft or any other company adds a feature to their software the end users expect it to work. They use it assuming it does. If it's still an un-reliably "beta" feature than what the companies is really doing is passing off all the testing costs onto the user.
About the only group of people out there that do accept new features at the cost of stability is the Open Source community. But even then, take 99% of the OSS community and put them in a business situation where real cash rides on software stability and they'll opt to not have that "cool new" feature.
It is certainly true that users place reliability very low on their list of priorities when buying products, but that does not necessarily means that they don't value reliability. It merely means that they take reliability for granted.
:-).
For example, the last time I filled in a car survey, I didn't put "does not explode when ignition key turned" anywhere on the form.
The problem is a fundamental one. There are way, way, way too many possible parties to blame. The only logical reaction for MS if such a law was enacted would be to immediately cease running any software that wasn't authorized by MS (with approriate fees, bars for competing programs, etc.), a situation that I imagine they see only in their fondest dreams. Legislation like this would be the perfect excuse. To be honest, even I would barely question their right to secure their system if they are going to be held responsible for its flaws.
As for the idea that open source software should be exempt - I doubt that you'd accept the idea that cars should be exempt from safety standard if they provided you with the blueprints
No, the Open Source zealots have an answer for that...
Their software will be exempted.
Of course that right there guarantees Open Source software will never be used in government or business climates.
Most regulations are in place to protect the existing companies from competition by raising the barrier to entry even higher. So I'm actually surprised Microsoft is against this, although maybe it's a Brer Rabbit defense.
Why should liability be software or hardwar based?
If i design a system to move some gears via an operator pressing big electronic buttons as a mechanical engineery, why should an electronic engineer who designs a program to operate the gears be exempt?
We are both designing a system to do a job. As an electronic engineer, I make my system based on some OS, so either I or the OS manufacturer (which, I add, licences an OS, if it is used against the license terms, it is my liability) has the liability.
Don't be lazy allocating responsibility.
Because some IT staffs have a higher-up who went to the most recent Microsoft seminar ($25.000,- for entry & attendance, $750,- for the hotel, $2.250,- on the flight) and got amazed by MS. After budget-cutting away the drinks dispenser and replacing it with an old coffee maker (Hey, that $28.000m- is more important then employee satisfaction! *sarcasm*) hte higher up has a great idea, replacing all server with Windows 2003 Enterprise Server! All the crying and complaining from the IT staff wont convince the higher-up, because a shifty, 40b USD company that can throw a flashy seminar is far more trustworthy in his opinion then his IT staff, who worked with the company before he got there. Several budget-cuts later to accomodate the win2k3 licensing costs, the entire department switches to Win2k3. Several more budget-cuts later, mainly used on MS support, the entire company goes to hell. IT staff gets fired, along with the rest of the company while management gets scattered among several other companies, ready to ruin them anew.
Welcome to the modern economic system.
Hate me!
Boy what fucking useful advice.
And if someone asked you how to play a flute you'd say, "oh, just blow in here and move your fingers."
DrLunch.com The site that tells you what's for lunch!
are all those cases programs written originally for win32?
I've seen it work both ways, usually the original is more stable than the port...
I think that there is one large distinction here. In the case of Microsoft and other vendors, people are buying the software. If you are BUYING a product, you SHOULD expect that the vendor is subject to a degree of liability. If you are using a product that you have not "bought", such as OSS, you should NOT expect a degree of liability on the developer. Sure this may stifle the acceptance of OSS, but I hope that lawmakers keep this in mind. On the other hand, I believe that if you have paid for a modification to that software then that is a different story.
This post shouldn't be modded down that badly. I mean, this guy is giving his truthful opinion, albeit a wrong one... ;)
-------
"In times of universal deceit, telling the truth becomes a revolutionary act."
-- George Orwell
troll? *mumbles something about OpenBSD
I touch computers in naughty places
The real right answer is to move that 50% to testing, double project timelines, add diagnostics and plan for quality from the very beginning.
Where life-critical systems are put in place, there will be an insurance policy. The insurance company should require a guarantee from the software vendor. Therefore, in life-critical systems, the software vendor should always be able to be held accountable. Yes, this will be expensive, but not as expensive as all those lawsuits.
Most software does not fall into this category. Virtually every business is heavily dependant upon software though, so it is mission-critical. The nature of closed-source software is a massive imbalance between vendor and customer though. The vendor is the only one who can fix bugs; it's the ultimate form of vendor lock-in. Those vendors with monopolies (for example Microsoft) should therefore be regulated in some way, as they can literally hold a majority of businesses to ransom.
Suppose a defect that only affected a small number of businesses was found in Windows? Microsoft has little economic incentive to fix the issue. The businesses are heavily dependent on the software, yet nobody can help them - the only thing they can do is work around the issue somehow, which may not be possible, or an expensive migration to another platform (expensive in terms of resources; even if the software is free, the downtime is not).
What can be done to fix this situation? Obviously, if you run a business, you take appropriate notice of this business risk, and plan accordingly. But this doesn't escape the fact that sometimes you have to resort to using software you cannot rely on. I'm a web developer; I have no choice but to test in Internet Explorer. If a bug prevents me from running it, it's a major setback.
I believe a solution to this is to loosen the grip the vendors have on the software. Copyright is an artificial monopoly on creating copies; it shouldn't be an artifical monopoly on fixing bugs. If you are a software vendor, you should have three options:
This, I feel, is the balance between protecting businesses from having no control over their software, and protecting the rights of the software vendor. Have I missed anything?
Medical devices controlled by software have stringent FDA approval cycles. Basically you establish the quality of the engineering process, document the heck out of it, and then show clinical effectiveness in random control trials.
What I find fascinating is that legal basis for this is Food and Drug Act -- for the protection of the public as the reason. But the more important side benefit for the approval process is to protect physicians from liability. It's frightfully expensive. And, BTW, physicians *don't have to do this* if they are involved in active oversight when using an experimental device.
Conclusion: Most software products should be viewed as experimental devices which are being used by competent individuals and which therefore all liability is absorbed by the user. Check your EULA and GPL.
Overall this article is regrettably superficial and quite predictable given the history of the quotees, which in the case of Peter Neumann goes back at least 25 years. Not much has changed. Even the examples have the same kind of air about them.
Don't expect progress any time soon. Usually we need some kind of highly visible public disaster (e.g., like the recent nightclub fires) to motivate action.
You want verified design? Cool, you can get it. You can get a design that is gaurenteed to have no bugs and to never crash. This exists today, however you need to be prepared to PAY for it, in many ways.
First, say goodbye to the concept of being able to load your own apps or run it on your own hardware. If the company is going to certify that everything will be bug free, they need to know that a 3rd party isn't going to fuck that up. Your system will be verified to run on a certian hardware and using certian software. You will not change any of that without consulting the company first to do a verification of the proposed changes, or you'll invalidate the gaurentee and service contract. After all, you can have 100% stable code, but if a peice of hardware has a dodgy kernel mode driver it doesn't matter, that can being the system down.
Second, you will have the access restricted. You won't be able to just put this system on teh Internet to be accessed in any way you like, it will be accessed only through verified channels. You cannot potentially have the integrity compramised by clients sending unforseen data to it so all access must be controlled.
Finally, you will pay in terms of price. IF you want a system of this level you are not getting it for under a thousand dollars. Think 6 or 7 figures, plus a yearly matenence contract since you yourself aren't allowed to maintain it.
We have systems of this level in the real world. Like the AT&T/Lucent phone switches that run most of your phone network. We have one at the university and know what? IT never goes down, it didn't even go down when they upgraded it from a 5ESS to a 7R/E. It is 100% reliable. However, it is totally inflexable. We can't mess arnound with new technologies with it, it does phones and it does them only one way. We don't even work on it directly, it came with two technicians as part of the service contract. Oh, and it cost nearly 20 million dollars.
Look, if you want to have a computer market where anyone is free to build hardware and assemble it how they like, and you can freely use whatever software you want, you have to accept that there WILL be problems and you won't get verified design. The big part of a verified design is just that, verification. You check EVERY part of the design and make sure it works properly with the other parts and has no errors. Well the problem is that hardware, software, and user interaction are all a part of that and all have to be restricted. Once a design has been tested and verified, it can't be changed without reverfying.
So, if you really want 100% reliability, and can afford it in terms of monetary cost and teh sacrafices you have to make, then don't whine, go and get it. Talk to IBM, EMC, Dell or the like. They'll design you a system to do what you need that will never crash ever. However you'll need to decide what it needs to do and be happy with that, because you won't be able to change it, and you'll have to pay a real cash premium for it.
I disagree about the article's assertion that there is no liability for defects in software.
I deal with embeddeded controls in industrial control equipment all of the time. I just had to change my insurance company last year and my rates went up because companies are being held accountable and insurance companies are paying out when people screw up. Many companies don't want to insure programmers anymore. Sounds like the hammer is coming down to me.
You may not be able to sue MS the next time Excel craps out on you but I assure you that you could sue a programmer because the system that he programmed dumped 1000 gallons of a toxic substance into your containment area or because you just released a toxic cloud of ammonia from your plant.
When the stakes are high, programmers tend to have to test a lot more. You still have to remain economically viable though. Three lines of code a day may work for NASA but the rest of us can't afford to be that inefficient. Of course the stuff that I can blow up is at most worth 10's of millions of $, not billions.
When it comes to embedded control apps, I don't think that things are much worse than they are for our physical counterparts. Yeah a plane crashed because of a bug in an altitude control system but they also crash because of other design problems in the mechanical, electrical, and materials engineering areas. I don't think that programmers are any less aware that lives depend on their work than any other type of engineer.
If you are doing number crunching types of applications, you also tend to run the code through a battery of tests. You can definitely be sued for screwing that stuff up.
Now little controllers in your dishwasher and your run of the mill desktop apps are held to a lower standard, I agree. You are rewarded by the market for getting new stuff out the door cheaply and quickly. You can certainly argue that it shouldn't be that way but the masses have spoken. If your stuff gets too far out of hand then the market will let you know. MS is definitely feeling the pressure from OSS and rightly so. I can bet you that they are atleast trying to respond. I can definitely see a big improvement between the Windows XP that I run on my notebook and desktop and the NT 4 that I ran a few years ago. I can also see that Windows 2000 is much better than NT 4 was on the server, but it isn't good enough yet and that is why a lot of people are moving to Linux for things like web servers, DB machines, etc. The market is speaking.
I would say that programmers are ultimately held accountable. I would hate to see things swing too far out of hand as I do think that it would ultimate stiffle innovation.
On the other hand, when I was managing physics reconstruction software, that software, when I started, would crash once every couple of days. Those were repeatable so you track them down and fix them. When that process was done, we could run for months on 60+ machines without an application crash.
It all depends on how easy it is to track down the problem and what the costs of not doing it are.
It's unavoidable. Home washing machines had nifty arm crushers for decades until consumer litigation removed the design from the market. The novelty wore off, people became accustomed to having a washer at home and no longer accepted dangerous design in a ubiquitous product. Software is still in the novelty phase, consumers haven't yet asked why a single e-mail can cause billions in damages or who's responsible when a bug results in a medical tragedy. Given today's manic technology curve, I'll wager their kids will pose te question.
Software liability is coming, OSS needs to start working on a strategy now.
Sort of like the RedHat/IBM model for making money from OSS/FOSS - sell the services, give away the software. In this case the service is managing the risk.
What about free (as in beer) software? In this case, the best solution would be for the user of the software to assume the liability. The software user could either accept the liability for free software, or pay someone else to assume that liability (meaning buy the software from the middlemen).
The point is we need the ability of software users and producers to rationally cost the risks of software malfunction, then assign these risks to the party that makes most sense. What we have now is a unilateral non-negotiable assignment of ALL risks to the purchaser.
Why should software companies face multi-million lawsuits for software errors? The same reason that software users ALREADY assume multi-million dollar costs of flawed software. Allowing tort liability does not change the fact that there are real costs to bad software - it only allows a mechanism for allocating these costs (versus the current unilateral buyer-takes-all-the-risks).
"dope will get you through times of no money better than money will get you through times of no dope"
Of course, EULAs make further restrictions intended to keep consumers uninformed -- barring benchmarking, sometimes barring other criticism (does Frontpage still have that clause?), not allowing security flaws to be published, etc.
Even with source, false advertising is quite possible, and should be punishable if we are to have a free market. It is now, but not done with great vigor.
Anyway, I guess my point is that this isn't a free market, and that the free market cannot be achieved with laissez faire policies.
Price, features, speed and reliability. Pick some but you can't have all.
To write almost bugfree software, like DoD / NASA (just be sure to check the specs for metric or not), the price is astronomical. Despite the obscene profit margin, Windows would be *much* more expensive if written by the same standards.
Also, adding features is another reason for instability. Not only commercial software, but also OSS software has been accused on focusing too much on adding features. In the commercial world because features sells, and OSS I think mainly because adding features is more fun than debugging an elusive bug that only happens on friday 13th under a full moon.
Another thing is speed. Particularly games are running the latest beta drivers on a tweaked and retweaked engine for speed. This is happening both in the high-end (pushing eyecandy) and in the low-end (pushing playability for low power machines). Don't expect perfect stability from that.
In short, I think the market would normally work this one out by itself. When delivering appliances I feel you should have the same liability as for the rest of the car. I mean whether the brakes fail because of a mechanical or electronic (software) design flaw, is not very relevant. However, for a typical software program that operates only on your computer processing information, I don't see this as very useful. Requiring some kind of standard would not change the basic trade-off, and it's not the producers' fault that the consumers aren't valuing reliability and security. They aren't willing to pay the price in form of money (How many complain about the price of Windows already), features (Go Linux. More stable, less features though) or speed (How many complain about the speed of Java that tries to abstract away from bugs related to not properly terminated strings, pointers arithmetic and array indexes out of bound?). So what did you expect?
Kjella
Live today, because you never know what tomorrow brings
This isn't really a huge issue, it's just illustrating the need for another certification program. Look at the semiconductor market: There's semiconductors that you can use in everything, then there's semiconductors rated MILSPEC and Hospital grade, which have been tested and are approved in critical situations. Same damn semiconductor more or less, just has been exhaustively tested. They usually cost many times that of the other part, but you KNOW it will work, 'cause whoever made it is going to stand behind it.
We need the same thing for software. Someone to set up some guidelines, and provide certification to software that is going to be used in a critical application. Hell, maybe even the UL could open a division and do it. It is plain stupid to assume authors have liability over all software written, especially in the open source world. However, if I buy a product, and its software has been certified by a trustworthy organization, I'd feel better about myself.
I agree, if I fork over lots of $ to MS, I expect a reasonable amount of reliability of their product (they are after all, selling software to enable me to do something reliably). I microsoft can't produce reliable software, then they should find another venu to make money, perhaps selling music cd's..microsoft is a very rich monopoly that should be sued for inept performance in reliable products..they could have spent money years ago developing good software reliablilty systems to debug their code (but they didn't want to do any R&D for years..too much money, not enough lawsuits I guess)
If something is inherently unreliable then you don't need to fix it: you find ways to live with it. A perfect example of this is the internet itself. TCP is a reliable transport provided over IP, an unreliable internetworking layer.
Make no mistake: IP is explicitly and deliberately unreliable. This keeps it simple, and allows upper layers to choose appropriate quality of service parameters for their application.
How this relates to the issue of unreliable application software is fuzzy: but its pretty obvious that humans have adapted to the reality of the situation: the power-cycling protocol is just one example of the ways in which we cope.
If a situation is life-critical, then I'd be happier knowing that the system is designed to cope with glitches then if the system assumes these glitches have been tested out of existance. Cosmic Rays really do exist, so some level of unreliability is guarenteed!
Opinions my own, statements of fact may contain errors
In most places, free-as-in-beer stuff is already fundamentally a special case, because unless something of value changes hands in both directions, you don't have a contract.
Of course, free-as-in-speech software neither deserves nor should get any special privileges. If you make money by selling me an OS that happens to be GPL'd, open source, or otherwise "free", that's still something you're selling me. "Oh, you should have looked at all the source code for Linux and spotted the critical bug for yourself" isn't much of an excuse at that point; I'm paying you to have done that for me.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Yah windows NT/2k/XP *looked* secure out of the box also. Then the exploits came.
75% of all statistics are made up!
Since you ask...
1. Provide the software in a form that allows the customer to fix bugs and rebuild. In other words, provide the source and everything needed to compile it.
You as a programmer may benefit from this, but most customers will not. Rarely do "customers" know better than the developers. It is most often the case they just have more time. Furthermore, I would say most web developers would benefit little from IE coming with source code. A) they won't know how to fix anything, B) even if they did, microsoft would have to agree to incorporate the fix for it to be worth anything... A fork for every bug is not going to improve any software.
2. License the buildable source code to third parties for free. These third parties should pay the original vendor the retail price + 10% for any copies they sell. Any third party should be able to license the code in this way.
The vendor gets 110% for writing buggy software that others need to fix? Or do you mean anyone who calls themselves a vendor can get the software for free?
3. Be unable to disclaim liability for the software.
Unfortunately for most developers/vendors, this will read, "Be unable to distribute software". That is, I believe to be, the legal truth.
reliability. further, we expect more and more features and expect it at a low price. People who design software, do so on language that is backwards compatible with ones 20 years ago, namely C++, which carries some of the many failures on many levels into living applications. Now the language is not wrong, but how many people really considered writing their applications, say in Lisp, Scheme or Forth. Each language has its advantages, yet economics of software development demand that people should use most widespread language, so that it would not be as hard to hire decent software developers. What most managers do not realize is that by choosing a language they meddle in the affairs of those who know the field much better... The is whole stigma with using software tools, languages being the core. And often it is decided by managers who do not carry responsibility for development and manintenace of the software. And even if they do common fallacies used to justify imposition of specific tools onto software teams. ... except games! So what do you expect? Incomplete requirements, unfit tools ... list goes on and on. Very few people are able to cut through the bullshit, and crap in general to get a very good software package out. Nevermind treat their employees right. Bugs is corporate software are just some of the sysmptoms corporate world bearing off, core of the problem being, is sheer miscommunication in way public companies are handled - which is what most of software companies are.
However sometimes teams are fortunate enought to have choice in matter of tools, yet they never really have the way to verify that something they have created is exactly what a customer needs. Scrutiny by expert users is often absent from software development
In the end it is all about compromises and vision. Software bugs are just side effects, that will exaterbate any main problems a software company has. (that is bugs in tested and released software).
Plus something that was not tested for and does not have fatal outcome on the program is not a bug, i'd rather qualify it as a glitch...
my 2c.
This is an absurdly narrow view of computer programming. While appropriate to some types of software projects it would be entirely wrong for others.
Much of what computer science has accomplished in the last 50 years has been to hide the hardware behind abstractions more suited to the tasks at hand. If I'm running a team bulding a web application I'm going to be looking for folks who really understand user interfaces, HTTP, TCP/IP, and security issues. Experience in assembly is not necessiarily going to shed a lot of light on their knowlege in these areas. One of the sharpest guys I ever worked with was a trade school graduate and an absolute wizard with SQL. He had no knowlege of processor architechture. I had to explain floating point number representation to him. However, he had totally internalized the relational database model, and he could crank out efficient queries in minutes that it took me days to understand.
If I was writing a database engine I would want people who really understood the low-level hardware envirnoment. But if I writing an applications that uses a database engine I'll happily trade that low level knowledge for someone who really understands the abstractions of the engine.
Choosing high level languages does NOT remove potential faults. It simply delegates those faults elsewhere. In some cases thats a reasonable tradeoff for the performance hit of a VM, in some cases it isn't.
Doesn't matter, as soon as you click through that EULA you've already accepted that the software is not necessarily reliable. ...could reliability standards stifle innovation? How hard is it to design something that works well and is extremely robust, yet, be creative and innovative in its design?
Have you ever designed/written software? It's not as easy as it may sound! We try. I try. I do my best at all the design and coding work I do, but sometimes still fall short. I find many of my bugs, I'm entirely sure that there are some I don't find.
Software is *MUCH MORE* complex than a bridge or many "real" devices. It is likely that it will never be perfect.
On the practical side though, if people demand "perfect" software the price for software will sky rocket. No one can afford 100% bug free software. Therefore there will always be that chance of unreliability.
I have to agree with Microsoft here as much as I hate to admit it.
-Craig.
It really depends what you're writing, how critical speed is, and how much the application needs to be optimized. I'm developing 3D graphics software development toolkit, where you REALLY have to know where every little bottleneck could appear. Something as seemingly harmless as simply having a constructor in your 3D vector class can kill your apps. (Obviously not having a constructor is dangerous, so we provide a version with a constructor and one without, and the programmers need to make sure they know what they are doing). You need to look very carefully at all sorts of aspects, such as possible speed hits of pass-by-copy to functions, where all your inline functions are etc (not having inline functions in crucial spots can also kill your 3D apps), caching aspects etc.
3D graphics is obviously a relatively "extreme" case, where you simply cannot just rely on a good optimising compiler, but there are others. For example, you might be required to write a text 'search' function for a very large database (e.g. the Oxford English Dictionary 2nd Ed software has a search system that allows text searches on over 600 MB of text data to be completed in under a second or so .. probably not unlike Google's I would guess). So for these systems, you also really need to know what you are doing, you cannot just "throw some code at the compiler" and "hope for the best", that just wouldn't be good enough.
However, it is still questionable whether closed source -- as it is typically sold -- really leads to informed consumers, even without restrictions Software is not particularly transparent, and its flaws may not be readily apparent. Buyer Beware is not the free market.
Wanna know ho gets the blame? That same IT staff, that didn't want win2k3 in the first place.
"It is not because no one sees the truth that it becomes a mistake" (Mahatma Gandhi)