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."
M$ (Score:2, Funny)
Re:M$ (Score:3, Insightful)
Re:M$ (Score:3, Insightful)
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)
How is it possible that on the same PC I have a 70 day uptime with linux?
Re:M$ (Score:3, Insightful)
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)
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.
Re:M$ (Score:3, Insightful)
Re:M$ (Score:4, Insightful)
In the case of IIS exploits, for instance, it has nothing to do with it whatsoever.
Re:M$ (Score:5, Insightful)
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.
Joe
Re:M$ (Score:3, Insightful)
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)
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)
If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not theregister.co.uk) MSFT-criticisers. This is typical of them.
Re:MSNBC (Score:3, Interesting)
Re:MSNBC (Score:2, Informative)
Re:MSNBC (Score:3, Interesting)
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)
why this kind of article is great. Re:MSNBC (Score:2)
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)
If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not theregister.co.uk) 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.
-Bill
[1] I know, I know, anything negative about an editor is a troll of flamebait. Mod me down. *sigh*
a language that forces good code? (Score:2, Funny)
i think the next version of C# is suppoed to do all of this, with some kind of XML voodoo scheisse.
-c
Re:a language that forces good code? (Score:2, Insightful)
Remember Fred Brooks? (Score:4, Insightful)
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.
Re: Remember Fred Brooks? (Score:3, Insightful)
> "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.
Re:Remember Fred Brooks? (Score:3, Insightful)
No, but there are many many little normal ones
Seriously, "little" things like languages that espouse safety and clarity add up.
Re:Remember Fred Brooks? (Score:3, Insightful)
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.
Money gap is irrelevant (Score:4, Insightful)
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.
Re:Money gap is irrelevant (Score:2)
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.
If you asked an arhietect..... (Score:2)
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)
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.
Re:Money gap is irrelevant (Score:4, Insightful)
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).
How to put any OS product on a "mature" timeline (Score:3, Funny)
while (OPEN_SOURCE_PRODUCT_VER >= COMMERCIAL_PRODUCT_VER)
{
OPEN_SOURCE_PRODUCT_VER
}
printf("We're only at version %d, Just wait 'till we get to version %d", OPEN_SOURCE_PRODUCT_VER, COMMERCIAL_PRODUCT_VER);
as a developer (Score:2, Interesting)
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...
Software's so bad... (Score:5, Insightful)
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.
Re:Software's so bad... (Score:4, Insightful)
Re:Software's so bad... (Score:5, Insightful)
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.
Out of touch with reality (Score:4, Interesting)
"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 [jscript.dk] (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 [bmug.org] 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.
Software Capability Maturity Model (Score:3, Informative)
Re:Software's so bad... (Score:4, Interesting)
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.
And companies should encourage that too... (Score:3, Interesting)
They would prefer to have them producing code that works, as soon as possible, even if it means bringin into the code repository their own habits, good and bad, picked from their previous jobs, school or their intestinal tract.
If a manager at a construction company is building a bridge, it is likely he will not be satisfied JUST because the bridge seems solid. If the bridge looks unlike anything he has ever seen, its structure defies comprehension, and he's not entirely sure the thing stands by anything more than chance or will survive the touch of a maintenance crew, there will be hell to pay.
On the other hand, if the software works, the manager is probably satisfied.
This may not have as much to do with the programmers' or managers' discipline, but with two other simple facts:
a) Everyone knows how a bridge should look, and if it looks any different (new design), they will be extra-paranoid about it. Soon the new design will join the ranks of ways a bridge should look, and there are not that many.
b) Most of the bridge's features can be seen at first glance, without a peek at the designs.
On the other hand, concerning software:
a) No one knows how software should look. There are a million gurus who think they do, with a million different versions. Given a piece of code and an expert, he will be unlike to tell you if it looks solid or not at first glance, so a non-expert will judge by whether it executes or not.
b) Most of the software's structure is hidden from view in the final product because software is not physical. It's all design. Judging the quality of software, even if you knew what to look for, will depend on a through review of the designs (code) which is as likely to happen as a voluntary visit to the dentist.
K.I.S.S. (Score:2)
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)
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.
Re:Forcing good code? (Score:5, Insightful)
The joke's on MIT Technology Review (Score:5, Interesting)
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
The joke's on you, MIT.
Re:The joke's on MIT Technology Review (Score:2)
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.
The joke is probably on the Post Office (Score:5, Interesting)
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)
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)
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.
sPh
I couldn't read some paragraphs of the article... (Score:2, Funny)
Responsibility and liability (Score:4, Insightful)
They left out an important issue -- open source. (Score:3, Interesting)
"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.
How software gets bad (Score:5, Interesting)
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)
6. Fixing even the shallow defects would break backwards compatibility and the customers all swear they will go to your competitors.
Software NOT Different (Score:4, Insightful)
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.]
Re:Software NOT Different (Score:4, Insightful)
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.
sPh
Re:Software NOT Different (Score:5, Insightful)
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.
how complex are cars vs. operating systems (Score:2)
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
Why Software is Bad (Score:2)
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.
-Pete
Software is bad because it's not a science (Score:3, Insightful)
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.
Re:Software is bad because it's not a science (Score:4, Insightful)
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.
sPh
TV is critical?? (Score:2, Interesting)
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!!
People don't want good software.... (Score:4, Insightful)
an interesting article, but... (Score:4, Interesting)
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 [techdirt.com].
Your Word For The Day... (Score:2, Funny)
From Dictionary.com [dictionary.com]:
lacuna n.pl. lacunae
How Easy To Criticize (Score:2, Interesting)
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?"
Re:How Easy To Criticize (Score:3, Informative)
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)
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 [trillian.cc]. If they had developed from 99b into what LICQ has instead of their AOLised crap, maybe I would have kept with the official client.
Look at how programmers are taught... (Score:2, Insightful)
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.
Creating a language that forces good code (Score:2)
Oh wait, you can do that; it just means it won't run.
So I think it explains itself.
My experience has shown... (Score:2, Interesting)
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.
They forgot something (Score:4, Insightful)
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.
No.... users are not saying that (Score:2)
Users are saying "When are you going to make this *work*?" And it ain't just Microsoft's software either.
Requirements and design committments (Score:5, Insightful)
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.
Well, what do you expect? (Score:5, Insightful)
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.
Re:Well, what do you expect? (Score:3, Insightful)
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.
Re:Well, what do you expect? (Score:3, Insightful)
Naturally, the demand for CS graduates would become greater than it already is, leading to more students pursuing CS, leading to more very capable graduates filling said demand, leading to higher quality software. What's the problem here?
Okay, screw the socratic stuff. I'll just lay it out.
What would happen is that businesses would be unable to get enough CS grads to do what they need done. Also, salaries for programmers would continue to rise, making much software too expensive to build with degreed CS people.
So, businesses would turn to other sources. Overseas, if necessary, but since that is often impractical, they would mostly turn to vocational schools. You know, the "You too can lose that dead end job and become a programmer in only 18 months" kind of programs.
You see, you're confusing cause and effect. The low standards are the effect. The cause is that developing good software properly with well-qualified people is just too danged expensive. There's too much software that has to be written. Business has pushed the schools to turn out more software engineers because they need them. Schools have responded, that's all.
I'm massively oversimplifying here, of course. I'm ignoring the fact that there's not much incentive to be a CS professor, and the fact that a top CS grad is still far from being a good engineer and that good project leads are even harder to find than good programmers (since they have to be good, experienced programmers *and* understand the business world *and* be able to communicate), and that good software project managers are really tough to come by and a whole host of other issues.
The key, though, is to understand that the schools' attempts to pump out ever larger volumes of CS grads is the effect of the high demand, and that reducing the supply will only force that demand to be supplied elsewhere.
Fundamentally, the software industry is faced with a nearly insoluble problem. We're trying to build more, faster, better, with less and less because we're in the process of rapidly computerizing our whole society. There's just too danged much work, no magic bullets to be found, and much of our software, frankly, doesn't *have* to be all that good.
Developers are only half to blame (Score:3, Insightful)
It's not just 1.0 versions.. (Score:5, Insightful)
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..
Re:It's not just 1.0 versions.. (Score:3, Insightful)
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?
Seems obvious enough to me... (Score:3, Insightful)
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?
Software development is not manufacturing (Score:3, Insightful)
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.
People get what they pay for (Score:5, Insightful)
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.
Not surprising considering... (Score:4, Insightful)
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...
Merely a conflict of values (Score:4, Interesting)
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)
But I thought they were asking us where we wanted to go today.
I'll tell you why! (Score:3, Informative)
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.
Quality is not free (Score:4, Insightful)
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.
Enough with the "not a science" angle! (Score:3, Interesting)
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)
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.
I don't mean to go off on a rant here but. (Score:3, Insightful)
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".
Magic Languages (Score:3, Funny)
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.
Time compression, decision making... (Score:3, Insightful)
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 error...you 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.
Wrong people, wrong tools (Score:3, Interesting)
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.
Re:Alright... (Score:2, Funny)
Hmmm.. Ain't MSNBC owned by Microsoft? Talk about the left hand not knowing what the right is doing...
(Anyhow, I'm sure Windows has cost consumers a lot more than $8.75 million...)
Re:Alright... (Score:5, Insightful)
How about some basic economics:
Value = Benefit - Cost.
If, indeed, Code Red cost $8.75billion (and I'd like to see the analysis that arrived at that figure), that cost was incurred in the process of using Outlook. Presumably, the consumer derived some benefit from using Outlook, at least in their judgement they did.
In any product liability lawsuit that does not result in human death or injury, one would have to account for all aspects of the economic equation.
Re:Alright... (Score:5, Insightful)
The irony is that most people, the average Joe and Jane out there, have shown that quality of software is very low on their list of purchasing criteria (which is how software like "ICQ" has never been non-beta...why bother ever calling it production code when millions of people will download it anyways). Given the choice, the market has stated time and time again that features will always trump quality, and that time to market often beats quality.
Sidenote: My own philosophy is that I spend about 90% of QA time code auditing and refactoring, and about 10% of the time doing runtime testing. I find that this is exactly the opposite of many organizations which push runtime testing as the method of evaluating code. To me runtime testing is no different than doing a compiler syntax check: It's an incredibly weak, time intensive, limited case way to assure the quality of your code, and should at most be used to evaluate tha the compiler and dependant third party code is of a good quality.
Re:Alright... (Score:3, Insightful)
It isn't surprizing to see the "sue em!" claims from many of those who already have forsook Microsoft software: These are the type of authoritarian people who believe that because it's not right for them, therefore it shouldn't be right for anyone else.
That is only partially true. The problem is externalities. For example, Joe admin and his friends decide that security is not a high priority for them. Now, when code red and the many DDOS slave programs end up running on thgeir box, Jane admin who chose quality is still bombarded with Code red attempts, or DOSed off the net.
In other words, as long as it's not on the public net where it can become my problem, I don't care what other people want to run. However, If I am going to have to deal with the consequences (DDOS, gobs of code red attempts, dozens of emails from various outlook viruses flooding mailing lists, etc), I expect some minimum standard to be met.
Think of it like FCC regulations. Radio emissions aren't regulated for the sake of the device's owner, but for everyone who lives near the owner who didn't get any input into the choice of brands.
Re:Alright... (Score:3, Insightful)
The "little incentive to offer new features" is ridiculous. There are dozens of extremely large auto companies, all dying to eat into each other's business.
what poor design decision? (Score:2, Funny)
- adam
Hmmm....; (Score:3, Insightful)
Here is something more to consider:
From the article:
The potential risks of bad software were grimly illustrated between 1985 and 1987, when a computer-controlled radiation therapy machine manufactured by the government-backed Atomic Energy of Canada massively overdosed patients in the United States and Canada, killing at least three. In an exhaustive examination, Nancy Leveson, now an MIT computer scientist, assigned much of the blame to the manufacturer's inadequate software-engineering practices. Because the program used to set radiation intensity was not designed or tested carefully, simple typing errors triggered lethal blasts.
Despite this tragic experience, similar machines running software made by Multidata Systems International, of St. Louis, massively overdosed patients in Panama in 2000 and 2001, leading to eight more deaths. A team from the International Atomic Energy Agency attributed the deaths to "the entering of data" in a way programmers had not anticipated. As Leveson notes, simple data-entry errors should not have lethal consequences.
No shit.... Since when should such a machine not have safety mechanisms in place to keep this from happening? Doesn't it seem obvious that one should do SOME sanity checking on the final result when someone's life is at risk?
Would a mechanical or electrical engineer allow this sort of thing to happen? Why should a software engineer?
Re:Don't use software that sucks. (Score:3, Insightful)
While this is true, I doubt that the Navy ship that was coerced by faulty software to shoot down a civilian aircraft was running Microsoft software. And the operating system still wouldn't be at fault here. This type of thing would be due to faulty design and coding on the part of the weapons targetting systems. This software that probably runs on some sort of Unix system--Software that is most likely unique and proprietary to this ship.
While Microsoft is undoubtedly the most highly publicized proprietor of poorly written bloatware, there are many others to be held acountable here. This isn't just about operating systems, or office applications. This is a fundamental problem that I'm beginning to see in all software created recently. From game publishers, to shareware, to P2P clients, to proprietary data systems there is a lot of poorly written, and even more dangerous, poorly planned out code.
Game developers are frequently rushed to the point of putting out a sub-par error-riddled game because the publisher wants the game out on schedule, not when it's ready. We've all seen numerous stories about how the majority of the P2P file-sharing clients are filled up with bloat and spyware. A lot of us have worked for companies that have their own IS department that writes proprietary code for many of the business's apps, and I think a good chunk of us can agree that many of those apps are poorly written and not very well designed.
I don't know what the solution is myself to this problem, and I don't think Bill Gates's plan to create a programming language and compiler that will resolve all these errors will work either. I think that this will only lend towards more reliance on the compiler to do the coding for you. Only a good Software Engineer is going to know which search routine to use in different instances, or how to write a proper algorithm for the proper circumstance. Software compilers, until they develop intelligence on par with humans, will not be able to do this for us.
I think the only solution is to go back to our roots and examine the way we teach and train the upcomming batch of computer science students. Teach them not to rely on the compiler to fix their mistakes for them, but instead to thoroughly plan out the code they're about to write (on more than a napkin preferably), use the fundamentals of programming to pick the proper routines, use modular design to produce a better product, and also to write code correctly the first time. Think of it like this (if any of you hunt that is), when aproaching your prey in the wild with a bow and arrow as your weapon of choice you must be sure of your shot, and be sure that your first shot counts or you may not get a second one. I think software designers need work towards making sure their first shot counts. Do it right the first time, and don't rely on the equipment to do it for you as only skill will prevail.
Re:CS, not SE (Score:4, Insightful)
You are right though, once I got a job in the real world I found that these virtues were lost in most companies, and the importiance of the training we received in CS classes were dismissed as academic jargon and a waste of time. I saw a lot of people developing software without even an engineering degree of any kind! And the notion that as long as your code isn't in a position to harm a person's life, so what if it has bugs, is rampent...
So I think the problem is not in the teaching, but that a lot (surely not all) of the employers dismiss the talents that their employees learned in school simply because they think the "real world" works differently and that their experience is more importiant that formal teaching.