Slashdot Mirror
Why (Most) Software is so Bad
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."
It's not real uncommon for this sort of thing to happen. Our local newspaper was bought out by Gannette(sp?) a little bit ago, and the editors let them have it for a long time by publishing articles about how terrible they were and how they were going to ruin the newspaper. (IMHO they have ruined it. Story/Advertisement ratio on each page is about 1/6).
What?
This article is out of the July/August MIT Technology Review. My copy of the magazine proves their point in an ironic fashion.
./ probably could--isolate the bug in ten minutes given the source. Likely it assumes that either the first city is valid or that the likelihood of two cities beginning with the same two letters in the same zip code is too small to consider.
The 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.
"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.
1. Smart (or dumb) guys form startup around good idea. Version 1.0 gets written in a frenzy of caffeine and beer, riddled with bugs because it has to be delivered before the money runs out.
2. Mistakes made in version 1 are sworn off as version 2 is designed. Version 2 is built by the swell of 2nd-generation coders, hired as fast as possible and sent to work unsupervised by the overworked 1st-generation engineers.
3. Version 2 is delivered with all the good ideas on the surface, but implemented by less-than-excellent coders.
4. Widespread adoption funds much additional hiring. Anything vaguely mammalian is hired to fix bugs and work on new features and new products. Most 1st-generation engineers leave with their money. Product design and development is run by people who don't know what they're doing.
MSNBC is in one of the best positions to criticize Micro$oft - since the US theoretically has a free press, M$ really can't censor their own (or perhaps I should say their 0wned) media outlet. If they did so, one of two things would happen: 1) A public outcry of monopolistic muscle, or 2) people would just slowly start recognizing other channels to have more unbiased news, and NBC, with or with the M$ attached, would fall from significance.
The net result is, M$ doesn't want to gamble that. It makes them look good if M$NBC criticizes them because it shows they're not using their money and power to censor the press. So their journalists get to express their views openly.
I did not design this game/I did not name the stakes/I just happen to like apples/And I am not afraid of snakes-AniD
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.
How does one test against every possible configuration of every possible computer that could conceivably run one's OS?
How is it possible that on the same PC I have a 70 day uptime with linux?
The key to the article is the last section, which talks about remedying the bad software situation, describing massive class-action lawsuits as "a bad idea whose time has come." MS knows that it could live through a class-action suit of this type. Would your favorite open-source project survive being sued back into the stone age? I think this article is an attempt to get public opinion stirred up to the point that UCITA laws - which include things like mandated warranties on software products -seem like a reasonable solution, and thus make life more difficult for MS's competition.
Knowing a bit of how mass mailings work, specifically how you figure out who is where through zip codes, the actual city that gets printed on things mailed to you in that fasion is determined by checking the Post office database, usually through a program such as AccuZip.
Lots of times, the city the post office has you in isn't the city you actually live in, but it will get to you all the same, because the Post Office can't assign multiple municipalities to a single zip code. They probably picked the small town because it didn't have any other zip code, or whatever criteria they have. Don't blame the software for something that isn't it's fault. It's just doing a query based on the official database.
6. Fixing even the shallow defects would break backwards compatibility and the customers all swear they will go to your competitors.
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
But it's hard to convince someone trying to make money that their programmers, regardless of previous experience, will not be productive from the first day at work because they need to be coached into the company's own standards.
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.
Freedom is the freedom to say 2+2=4, everything else follows...
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!
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I hit the Windows Update page fairly regularly, and unfortunately Microsoft doesn't see fit to include such things as the IE6 security patches there. I have to know they exist, which I only know from reading /., and go searching for them. I thought IE was part of the OS? I can download IE6 Punjabi menu support from Windows Update, why can't I get a fscking security patch there? Perhaps I could just reinstall IE? No dice, Windows has detected that I already have IE6 installed.
I'll believe that Microsoft is actually fixing stuff when they start including IE security patches on the main Windows Update download page. I'll believe that they have a commitment to trustworthy computing when they give me an update tool as simple to use as SuSE's YOU. That's right; when a company with $40 billion in the bank can keep up with a company that's had to lay off 90% of their US work force, I might start giving them some respect. Until then "trustworthy computing" is a bunch of marketing hot air.
Under capitalism man exploits man. Under communism it's the other way around.
"This is one of the better comments on this thread."
To me, these comments seem utterly out of touch with reality. I find bugs and insufficiencies in open source software. But generally open source software impresses me as an attempt to do a good job.
In contrast, Microsoft software seems just sloppy. For example, Microsoft's Internet Explorer has 18 unpatched security bugs (when this was written). These active security risks are different from the recent 15 that have already been fixed. This is sloppiness, not mistakes, and I don't find anything like it in the open source world.
When I have a problem with open source software, I find that I can get help. When I call Microsoft, I find that, usually, no one with whom I am allowed to talk knows any answers. Right now, for example, no one seems to know how to repair a new, Intel Motherboard, Windows XP installation that won't create a virtual memory paging file. It's buggy, and nothing can be done other than re-install the OS and all the applications.
If you find a big problem in open source software, chances are that you will communicate directly with the main authors. With Microsoft, I have not been able to get answers. This article says that the Psychic Friends Network is equally as good as Microsoft technical support: Microsoft Technical Support vs. The Psychic Friends Network The conclusion of the article seems reasonable considering my experience with Microsoft. Neither organization has useful answers, but The Psychic friends Network is more friendly and less expensive.
I'm seeing lots of comments about how software isn't "engineering" or a "science." Well, I hate to break it to you guys but engineering is just as much hackery as anything else. Yes, there is some science to figuring out how much stress a material can take, but it's not like you can mathematically prove that an airplane is safe. Products are recalled all the time because of oversights and design errors. And planes do crash because of mechanical failures. Aerospace engineers are more afraid of flying than the general populace.
I see two big problems with modern software. The first is that computer systems are much, much, much too complicated, to where people accept lines like "no sofware can be bug free." Sure it can! How depressing it is that we let that be spood fed to us! But not when you have a huge operating system and huge language libraries and huge OS libraries and huge hardware drivers and so on. Heck, there's more code in one of Nvidia's drivers than in OSes from the 1970s. You see many fewer bugs on less complicated platforms, like game consoles and PDAs. PCs are pretty much a lost cause in that respect, and that's not going to change. One day I hope that we can return to more reliable systems, even at the expense of expandability (who cares about expandability any more?).
The second problem is simply that most developers don't give any importance to producing reliable software. In the telecom business, there's no way you could getting away without writing comprensive test suites and a huge amount of work from a dedicated testing group. But you hardly see automated testing for any software these days, outside of embedded systems. And you'll see silly newbie developers argue that they need to use C++ to write some silly app because "it is faster," when they actually should be using Python or Lisp instead.
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.
The bitter lessons of a veteran coder: http://bitterprogrammer.blogspot.com
"Anyway, the really stunning thing is that, of all the media outlets, MSNBC points out that just one of Microsoft's poor design decisions has cost consumers $8.75 billion, and wonders why nobody has sued."
If you look through the Slashdot archives, MSNBC has historically been one of the loudest mainstream (read: not 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*
SlashSig Karma: Excellent (mostly affected by moderatio
One reason that I've very often seen lead to failed projects is assigning them to people who simply can't do them. Not necessarily because they don't know anything about programming, but because they don't know the tools they have to use.
Years ago I was assigned a UNIX - MS Access integration project where I had to translate EDI messages to Access tables. I had never worked with Access before. I told my boss that I can't do it in reasonable time, but there wasn't anyone else free at the moment, so I was forced to do it. The result was that after three months of coding, $100/hour from the customer, I had learned to program with MS Access - by learning how not to do it. I burned out and quit. The horrible software was probably rewritten from scratch.
I have seen many really horrible examples of similar situations with other programmers, often with people dabbling with C++, lately with people who simply don't know how to program with C. Oh, what incredible examples I could give you! The result has been indescribable garbage. The garbage often works in the planned test cases, barely, but bleeds memory like a pierced pig and crashes from a slightest variation.
Many of these catastrophies occur because the programmers do not honestly admit: "I can't do this." And even if the programmers would admit, their managers won't when dealing with the customers.
All tools require learning. Some have a soft learning curve, some steep as a mountain. It doesn't matter much how professional one is, when it comes to learning new, conceptionally very different tools. Managers don't often understand this.
Just as often, programmers are assigned to projects of which they do not have a clear vision, usually because of too superficial specifications. Without proper vision, they can't find the right attitude to write beautiful, perfectionist code. They need inspiration, and finding it often takes time.