Slashdot Mirror
Why Most Software Sucks
gregbaker writes "Shift Magazine has an interesting article on bugs. They look at why commercial software has so many bugs and attempt to figure out why the software industry doesn't seem to have the same quality standards as other industries." Every Slashdot reader who manages commercial software projects should print this 8-page article out and glue it to his or her bathroom mirror and reread it every morning. But that's just my opinion - which is probably shared by another 100 million+ disgusted computer users worldwide who the commercial software industry seems to think should happily eat whatever garbage they want to throw at us.
You'll have to admit that no piece of software is ever free from bugs, they'll always be there because it's impossible to predict conflicts between certain pieces of hardware etc.
The real problem is that many major manufacturers aim for a shipping date rather than a quality product.
I'll prolly get flaim-baited for this but 'That's the way things work these days' I just hope OSS makes a big enough impact
To err is human,
To really screw up, you need a computer!
Is it the testers? no, they do what they can to get bugs fixed - they can't control when the program goes to market.
is it the management who rushes the software out the door? Maybe. But what's their motivation to rush incomplete projects? The almighty stock price. Companies set targets for when software will be available, and then get slammed for inevitable delays. And I'm not talking about vaporware, like NT 5. I'm talking about real projects that are getting delayed for legitimate reasons. However, the big stockholders put tremendous pressure on the company to get products out there fast, because otherwise their shares go down. The board of directors, whose interests are those of the stockholders, put pressure on management to rush products out the door. "What? Windows 98 is exactly the same as Win95? Ship it anyway - 98 is a bigger number than 95, so it must be better!" And from this we get the bug-infested software that we see so much of these days.
So what's the solution? The public needs to realize that the software industry is very dynamic, and delays are inevitable in most cases. If the stockholders don't push projects out the door when they're not ready to go, the projects end up being better. And _that_ is good for the company, and for the end users.
Just my $0.02
Is that the bill recently proposed by Senator McCain, or the older thing? Yeah, I know, I'm clueless on this point, but hey, whatever. =P I don't keep up with U.S. law anymore.. heh.
~ Kish
That crappy software ships is, of course, no suprise. What I never can figure out is that in every article I see about this phenomenon, you see a line like this one:
"Management hadn't given the programmers nearly enough time to do a decent job, and it showed."
EVERY project I have worked on that turned into a disaster had this happen. 3 different companys, too. And every project that worked and was on time--happend because we did that old boring junk that no one likes to do:
1) Write Specs
2) Follow the spec.
3) When the marketing department trys to add stuff, you say "Is it in the spec?"--"Sure we can add it, but it is going to take X additional weeks".
4) Test.
Writing good software is not brain surgery. But you cant take shortcuts and expect everything to work fine.
And while it is fun to slam managment/marketing, programmers have to take blame too: lots of time we say "Yeah, it *WOULD* take a year for someone else to do it, but I am a programming genuis. I can have it done in a month!".
I really believe some of the problem with both software development and all tech-work in general is our need for paper. At my office, productivity, efficiency, and reliabilty is harmed by the fact that everyone has their own method of dealing with stuff, a lot of it being the constant print-out of web-pages and other computer docs, because there's no one set-up that's good enough. I know it makes QA a nightmare, because you can't find the specs, or problems aren't reported in a standard way, etc. etc.
Let's face it: the promise of HTML won't be realized until the whole Web is Slashdotized (not Slashdotted!). By that I mean that every page can be personalized--for that, effectively, is what these comment forums allow us to do. By the time this thread is fully played out and moderated, the this thread will be more useful than the original article, because it will allow access to the article, and have insightful and useful comments and links highlighted. Can't really do that with paper.
If you think about it, Slashdot is analagous to a QA system. Speaking about that, it might be cool to make a Slashdot-style interface to Bugzilla. Why shouldn't the whole Web, and by extension, the whole world, have a QA system? (I suspect some might argue that's the idea behind Everything.)
The Web has a ways to go before I can really feel it's cool. Which is why Mozilla could be the most important app ever.
--
Make mine methylphenidate.
I was talking to my sister recently (not a master computer user by any means) and she asked me why Windows crashes so often. I tried to explain about the bugs and conflicts between the various pieces of software she has, but she could not grasp the idea that a flawed product would be released intentionally.
Why? Because it what other industry is it done? None. The fact is that consumers at large have just accepted the necessity of software bugs. Because of this, the software companies have little or no incentive to release a clean product.
It would take much more money and man hours to realease a clean product and that is time that it is simply not worth it to spend. This is capitalism at its high point. Often it works to bring a higher standard about, but in the case where the buggier product makes more money, it can do the reverse as well.
A solution? I don't know if there really is one... perhaps make it so that a bug causes a computer explosion. Then, just the chips in our airplanes, companies would have to release quality software. Just a thought.
14 digits of Pi are all we need.
It seems a shame that most people in the industry have not read it and that most managers have little or no idea of how managing a software project differs from general management.
--
Gregory J. Barlow
fight bloat. use blackbox.
Gregory J. Barlow
fight bloat. use blackbox.
- 33% design
- 33% implementation
- 33% testing
And, there are important constratints around this. For example, *no* features are to be added after the design phase, unless it is- absolutely critical
- the requestors understand the implications to the schedule (ie, more features = more implementation = more testing)
In the real world, however, the PHBs financing the operation can't get this concept through their thick skulls. When this happens to me, I tell then my recommendations; it's their dime, they can ignore it if they want to, but the reason they pay me (I hope) is that I know what I'm talking about. I've seen this happen before, and if something goes wrong, it's NMFP.They can feel free to buy more of my time to fix the problems they brought upon themselves.
One of the main factors that has led to the current state of the software market, I would propose, is that is is, in fact, NOT a munufacturing-based industry, as it is modelled after. Think about it: when a company sells you a piece of software, IP laws and shrinkwrap liscences and the hefty price you pay all lead you to believe that you are purchasing one "item". You have one "item" and cannot make more, or use that "item" in any manner for which is was not intended. If you wish to make this "item" available for others, you will be charged as if you now had several "items" (per-seat liscensing fees).
But that is not what software (is,should be, must become). It is a service, and needs to become modelled more appropriately after a service-based industry. I retain the services of a software company to help me do a certain task. They give me a piece of media worth 15 cents, but I am not paying for a thing. I am paying for the services of a company.
Think about the difference in current markets set up like this: shouldn't software be more like a getting a doctor or a plumber, instead of like buying a car or a hammer? Information, that which makes up this "thing" that they want to sell me, it is not a "thing". It is just a service they provide, to help me serve web documents or print a document. If I do not like their service, I find some other, better provider.
Check my Go-related blog for beginners: DGD
Humans program computers. Computers want perfection. Humans are not perfect. Within a software project, there is so many uncertain elements - skill of projects, dead lines, learning curves of new technologies. Unfortunately, software is not like building a house - you know the design of the house, you know now to put up a house - because you've done it before - what can happen, it falls down, or cracks in walls or other defects. UNFORTUNATELY, every software project is different, and is more complex than building a house, or other engineering industries. there are always different problems, different complexities involved with each project. If a dead line is approaching, more often than not corners will be cut, ie, a part of a project not tested properly, software cut down in complexity, which can lead to bugs in code. Until machines program computers, (which will be possible, sooner rather than later), software will be bugged. However, there are ways that code can be made less buggier, ie, automatic testing tools - so humans don't have to do the same boring process of testing functionality which can lead to cut corners, or functionality not tested correctly, or because the tester doesn't understand the application. Of course, such tools are only as good as they are implemented by the tester - poor automatic testing - poor application testing - probablility of more bugs. However, testing tools cannot test for "odd behaviour" of users, so manuyal testing will still need to be done. Setting up of auto testing tools take lots of time. There are programming languages of course, that make coding easier. But, in the end, its the human that has to program, test, and debug, and the problem is, we are not perfect, but computers want perfection. You can't compare software to other industries, its very much more complex.
But as I have got older, I have had two experiences which have changed that.
The first was Linux/*nix. Here was an OS that was stable and didn't crash or need multiple reboots after every software installation.
The second was working for the largest Telco in my country. When we had a software release, it had better be bug free, for if we had an outage for a couple of hours, it would cost the telco several hundred thousand as the application was used nation wide with thousands of users 24 hours a day, 7 days a week. The Telco demanded that the software was stable and were happy to allow extensions of delivery dates to ensure that happened.
How did these experiences affect me?
First, Linux/*nix showed that it is possible to create stable software. Second, that if the customer wants a quality product, software developers will produce the goods.
So IMHO, it's not the shareholders that I would blame, but the customers. If the customers kicked up a big enough stink and looked for alternatives, M$ share price would drop which would hurt it where it really hurts.
But customers don't really have many alternatives, nor do many of them know that software can be stable. Maybe we are forever doomed to have buggy software?
When I was in high school, two alumni came to speak before the student body. The two students worked for Microsoft, and one of them was (at the time) the head of the Internet Explorer development team. He was talking about their upcoming release of IE5, and noted that they still had to fix some bugs before releasing, but that IE5 would ship with approximately 2,500 KNOWN bugs. He also said that this was a relatively low number of bugs, and that he was proud of his team for achieving such a high efficiency level.
Isn't anyone else a little bothered by the fact that Microsoft, and presumably other Big Software companies, have convinced themselves that this is okay? They spend so much coding time adding bloated features with lots of bugs, rather than fixing the ones that are already there. Shameful.
Intercarve Networks, LLC
Despite having the source code, the amount of time and effort required to understand a large amount of code is overwhelming. How many programmers would volunteer to fix Windows bugs?
Consider the lesson of the WWIV BBS software, which was an experiment in Open Source commercial software. The program was written by a C instructor, who distributed the code (although you had to pay). People would "learn to program" by changing the source code, and once the code worked, distributing it.
The sad fact is, most people can't program. The classes don't really teach anything other than the syntax of the language, which they can then put on their resume and get the fast money.
What I'd like to see is: First, quality standards for software. Software is the only form of engineering in which there is not some sort of standard of how many or what sort of bugs are acceptable.
It's possible that C/C++ are not the best languages for Application development. Research has gone into developing new languages, such as Eiffel.
Lastly, software quality ends at the programmer. Think before you vomit unmentionable code at the feet of the rest of us.
Could be any. It was just a generic example, I believe. Lots of games are rushed like that.
Gates' Law: Every 18 months, the speed of software halves.
On (most versions, methinks; I don't remember 3.1, for instance) Windows, the three-finger salute is supposed to bring up a Windows dialog which will allow you to close an arbitrary program, or reboot the entire machine.
Only the dead have seen the end of war.
this article ignores what is clearly the worst part of USCITA: legitimisation of prohibhiting reverse engineering of a product.
h tml#discontent
The whole lack-of-a-warranty thing is nothing new in software, and i seriously doubt any company would try the PR disaster of setting up their program so that they can kill it remotely. But we should really be worried about anything that gives a company the power to prevent someone from using cleanroomed reverse engineering on their product.
The big defense of software lisenses is that hey, if you don't like it, you can take it back to the store. But in a world without reverse engineering, you have to face the possibility that at some point you'll wind up with a program where switching to a different program isn't an option because the new program is prohibhited from communicating with the old one, or prohibhited from using the old one's files, and you'll be left with a large amount of data or work rendered useless..
(A question: could USCITA apply to hardware as well as software, such that, say, Nintendo could put a no-reverse-engineering software liscensing requirement on the N64, and then use that to prosecute anyone who exersizes their right under the patent laws to cleanroomed reverse engineering? What if you didn't actually buy or open the product yourself, but just found it laying on the street or something? Do you still violate the liscense?)
anyway, this article is completely right. software makers, especially those that make web browsers, pay a little too much attention to "features" and not quite enough to stability..
-mcc
why web browsers suck: http://home.earthlink.net/~mcclure111/cyberleary.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
I'm going to kill whoever thought it was a good idea to have the ads reload every 10-15 seconds on the site that article is on. Grr.
Hmm. Well, most glaringly, this kind of assumes that all programmers are found in the commercial sector. In simpler times, I would not have found this incorrect assumption to be all that surprising. In light of the recent thrust of GNU/Linux into the spotlight, it appears to be more of a gross oversight.
On the other hand, does anyone here really think that every proprietary software product is a horrible piece of.. whatever? And no, Microsoft does not make all known proprietary software products, contrary to the belief of many conspiracy theorists who have spent too much time on board alien space ships.. ;) I would imagine that a greal deal of commercial stuff is actually good and relatively bug free. Not all of it, but just because all of it doesn't kick ass doesn't mean that all of it sucks, either.
Oh wait.. No wonder. The writer has obviously spent too much time around script kiddies and other lower network life. ;)
Actually, I know a lot of idiots with electric razors that don't shave a person's face (or elsewhere) very well. I consider that to be "unreliable".
"We, the suckers who don't know any better.." But seriously, who doesn't complain? I'd like to meet the person who isn't at least mildly ticked upon being visited by a BSOD.
Encapsulation and modularization are your friends ..
..too bad the people from Redmond don't make nice to these two potential buddies..
GPL your drivers!!
I don't know.. After reading this entire article, I was first surprised that the writer even knows the correct term for a BSOD, and also I just have to ask: Can anyone come up with any reason why free software would not be considered a Very Good Thing to inject into the software industry, as far as the average end-user is concerned? Obviously it's not quite so helpful to big business. ;)
~ Kish
So you would have us go back to ...shudder... COBOL? Excuse me while I go into spasms.
Seriously though, OOP doesn't mysteriously generate bugs. It's poor programming practice that does it. Go take a look at Eiffel, a OOPL that forces you to program well. It even has a GNU compiler.
So far the commercial offerings are pretty even with open source offerings. Everything crashes. Having a source tree to compile makes no difference if you can't navigate the 100,000 lines of code that make it up. If you're dealing with a niche market of users who are less interested in CS than they are in playing guitar you won't get any feedback from the users. You're the only one who knows that source code well enough to hack it.
If you're dealing with a niche market made up of CS majors you'll get cleaner Makefiles and configure scripts but that doesn't make the software any more reliable. Only when you deal with one or two fundamental, basic necessities of computer operation does the source code become useful.
In 4 years of producing source code, the lion's share of complaints were from users who can't compile the source code while binary releases were merely a matter of resetting LD_LIBRARY_PATH. It's a lot easier to give them a binary than start an endless discussion on compiler flags.
If the software industry had the same stringent standards as other industries, 99% of software would not exist
Ah, but the 1% that did would be quality stuff. The interesting question is, would we be better off with a smaller quantity of software, with higher quality?
I think so. I know I don't need 1e6 features in my word processor, or web browser, or [insert application here]. Most people don't, and I'm sure a lot of people would trade unused features for stability.
I also think that if some companies would start creating software with stringent quality control, avoiding feature-bloat and the accompanying bugs, they could make a name for themselves (with the appropriate marketing, of course). Thinking of buying M$ Bloatware 3000? Buy our app instead. It has all the features you actually use in the MS product, but ours actually works!
A) Never publicly announce release dates until the product is in the final stages of testing. Even so, don't be specific until FedEx comes to pick up your GM.
B) Internally, keep target dates for different stages of the project, and update them weekly to reflect your progress. Try to make them accurate estimations for your marketers to plan by, rather than deadlines for your developers to meet. Make sure your marketers understand that there may be unforseen delays, so that they don't start hyping a product too soon.
Gates' Law: Every 18 months, the speed of software halves.
The grand majority of your project time should be spent in the design phases. The less time you spend on design, the more likely you're going to fuck up during implementation, and thus the more time you're going to spend doing testing. Design should consume about 50% to 70% of a project's time (or at least closer to those figures than 33%). After you have a full, working design down on paper, implementation shouldn't be all that hard to nail down quick unless your programmers really are quite clueless. The reason you should spend so much time on design is so that before you even write a single line of code, you know everything that the program is supposed to do. You figure out the best way to implement each feature, and whoosh! You're off. A lot of bugs are solved this way before you even go to your favorite text editor. Moral of this story? If you don't implement something incorrectly in the first place, you won't have to fix it later. It's a Good Thing. And most of your bugs will be typos and other assorted weirdness rather than critical design flaws. A change in design during implementation is much harder, and quite time consuming. You'll be much better off if you have an extremely clear view of the design beforehand. How much testing you do shouldn't really be set down as any predesignated percentage, AFAIC.. You test it until it's done being tested. Besides, how much time that will require depends entirely on your licensing and how you plan to test it. ;)
~ Kish
I like the paperclip. It saves me time. I can show a user how to use it to find the answers to their questions without asking me. Being able to type "How do I change the margins?" and get an answer is very useful if you need that sort of help. Think of it as a cute/annoying first-person graphical front-end to searcheable help files.
Believe it or not, Microsoft actually does spend some time researching UI intuitivity.
Gates' Law: Every 18 months, the speed of software halves.
In the 1950s through the 1970s, people bought cars based on features and looks, not based on reliability and quality. There were a few cars that were well built and lasted, but for the most part, they rotted on the lots, while their flashy but unreliable competition sold.
People used to line up to see the new models. People with money lined up to BUY the new models. Knowing full well it probably didn't start any better than the old one.
It wasn't that Detroit was incapable of BUYING a quality product. It was that the consumer was unwilling to buy the boring but solid product. It wasn't until the late 70s and early 80s that consumers suddenly demanded QUALITY over LOOKS from Detroit, and Detroit responded (in the auto industry, the problem was the speed at which the change in consumer attitude took place. You can't change the manufacturing criteria from flash to quality overnight..and no one was sure if this was a passing fad or a real trend)
The facts are, if the consumer demands something with their money, they will get it. Complaints don't mean a thing.
Another example: Airlines. People complain about late flights, they complain about lousy service, but they book the cheapest flight. Duh! Leaving on time costs money! Great service costs money! If the consumer buys the cheapest product, they can complain until they are blue in the face, nothing will change, at least not for the better.
It is simple economics. There is great demand for flashy software. There is little demand for quality software. While that is the case, that's what the consumer gets. The software industry better hope consumers don't change their mind on flash vs. quality overnight, like happened with the auto industry.
I've been supporting bad software for many years now. I'm starting to detect a change in attitudes towards business people (although, I am probably guilty of contaminating the sample!). I think this is good.
Consumer complaints don't enter into economic decisions. Dollars do.
Nick.
It's used to kill a program that has crashed. Or for an example, if you went here, you would have to use CAD to regain control of your desktop.
some programs all that matters is whether they get the task done, and not whether they do the task well. But not all. the perfect example of something that works the other way is a web browser: stabilty really _is_ more important than features there. Because it isn't simply performing a certain task and then leaving; it's omnipresent, always there running in the background, never being quit since ther'es no way of knowing when it will be needed again.
as someone on an OS with no memory protection (macintosh) i wind up with this problem amplified-- since any one program crashing automatically means i have to reboot. And MSIE causes more crashes than any other app for me, almost always while i'm just kinda checking on something on the web as i do something in another program. (and stability is one of the main reasons i switched from netscape to begin with.)
which brings me to the most important thing: the ship-first-fix-later philosophy doesn't work unless you actually fix later. Meanwhile the web browser companies _never_ go back and do the fix-later part; they just ship, over and over, constantly adding new features and never considering he validity or stability of old ones. The proverbial feature freeze doesn't even happen _after_ the product is shipped.
The point is, even if features are more important than stability, at some point stability should be at least a _consideration_.
-mcch tml#discontent
why web browsers suck: http://home.earthlink.net/~mcclure111/cyberleary.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
There are many different factors that weigh in on software quality. The article mentioned some of them:
1. Complexity: For many projects it isn't possible for a single person to understand the details of how every single part of the system works. This leaves the project with a number of possible sources for bugs.
2. Testing: It's impossible to test the entire range of possible inputs and compare to outputs. Many real-world stimuli can't be predicted in testing, and often can't be dealt with.
There's another factor, which the article didn't mention:
3. Unlike other industries, there's no leeway. Either a product WORKS, or it doesn't. There's no such thing as kind-of-works. Take the automotive industry for example: Cars still have showstopper bugs (cars have been recalled, as have most consumer products), but there are fewer possible causes of a showstopper bug. Automotive showstoppers are almost always safety related. But if it turns out that the car has a part that is prone to leaking, the manufacturer waits until the consumer notices it and brings it in to be fixed, because even while leaking, or while the engine is knocking, or there is hesitation before acceleration, the car will continue to work acceptably. Consumers work around these bugs EVERY DAY. Just like I work around the fact that my toaster's timer isn't quite exact, often pushing it down for a second run cause the toast didn't get as brown as it usually does.
However, with a software product, every piece of the product is in such a delicate balance, it takes only one thing to go wrong for the error to propogate through the rest of the system, causing a crash. And often, the error propogation is completely unpredictable. This means that every part of the system has to work exactly as defined, (with no allowance for random fluctuation or acceptable levels of correctness), when the slightest variation can through every other piece of the system out of whack. In essence, every error can potentially destroy the entire system, no matter how trivial that error might be.
This is why software companies release products with licenses that disclaim responsibility. They know they can't predict every possible usage situation. In places where such predictability is absolutely crucial (air-traffic control being the canonical example) products are written for a specifically defined environment, with a specific set of interactions. The focus is entirely on reliability in a single environment, resulting in a loss of flexibility and features. In that situation, flexibility and features aren't necessary.
But in the consumer market, the story is quite different. Users want the utmost reliability, with flexible usage environments and all the features (yeah, everyone would accept a stripped down product, but only if it were stripped down to what they use). The bug situation is only exacerbated when the programmer has to worry about the actions of yet another software program affecting the operation of his or her own product, something which is not as bothersome in a well-defined environment.
Not even automotive companies will warranty a car which has been used in a way not predicted by the manufacturer, nor will any other company if they don't consider the product's day to day use to be normal. It's just much harder to define what normal use is going to be in the software world. Ideally, it would be "Used in exactly the same way, on the exact same machine, w/ the exact same setup as the developer's machine." But in the real world, that's never going to happen. That's one of the reasons big, single purpose servers tend to be more stable than my machine at home. The usage environments are far more well-defined than that of the average PC user.
I have developed on both NT and Windows98 (for either) and can tell you the OS can stop software development cold.
ActiveX controls and DLL's... I can't tell you how many times a bug is introduced in a new version of Comctl32.dll but is then fixed in a later version. It is often extremely difficult to determine whether the bug lies in your code, the development environment you are using, or in the operating system. The more time you have to spend tracking down OS bugs, the more of your own bugs get through.
There is also an extremely annoying bug in Windows 9X which causes the tab button to switch between programs rather than (seems the taskbar has grabbed the focus). If you use the tab key to autocomplete or to indent your code, it makes the system unuseable. The only solution I've found to date is to reboot.
So with NT/98 I waste my time debugging and rebooting when I should be coding and bugfixing.
Doug
Venn ist das nurnstuck git und Slotermeyer? Ya! Beigerhund das oder die Flipperwaldt gersput!
And I owe it all to you!
If you honestly thought that I meant that the entire bulk of Windows was compiled from a single source file, I don't think you have any right whatsoever to call anyone ignorant.. except, perhaps, for yourself.
Anyway, I'd say something more useful, but you're obviously trying to craft a troll. I kind of got the feeling right off the bat, but I thought this post was a complete riot. Sorry, you'll have to do better than that to sucker me in. ;)
~ Kish
The opensource movement doesn't have enough control to be fully recognized by the article. Aside from that, OpenSource software is STILL plagged by these problems.
Redhat can't go a week without having a security problem found. It rescently IPO'd. I only expect this to get worse.
Both KDE and Gnome have some serious problems. Partially due to the small number of developers on the projects trying to do a big job.
The Linux kernel (ugh..) also has some very serious problems. Albeit not as bad as the more popular windows, not as good as it could be.
In my conclusion, GPLing doesn't make for a better product. Just makes people feel better about themselves. As linux becomes more commercialized, these problems will only get worse.
I still fully believe that the best Linux kernel & library set was around the 1.2 kernel releases. I don't see this changing for quite a while.
OS/2 was quick at fixing bugs, but it shipped with alot of them. Microsoft obviously has bugs (notice how it performs better if everything on the machine is M$ though?). Macs die too.. Don't forget that. Linux takes a little longer to kill, but just give it a load over about 25 and watch it plummit.
BeOS will be my next try... I hear its great for multimedia stuff, but not to expect much in the office suit department.
Yes, yes... Linux is still more stable than some of the others. I just wish the hardware that was reported as being supported, was truely (stably) supported. SBLive anyone?
Rod Taylor
It's the worst kind of bug....an API that invites errors. Wher it takes a dozen lines of code just for the equivilant of if(pid = fork()), the chances of an error are quite high.
Undocumented APIs that MS uses in it's software makes matters worse. In order to offer comperable features, the competition must also use the undocumented API, only it has to reverse engineer it first, and never knows which ones will disappear and when.
Windows also has a lot of leaks (otherwise, how could one app crashing take the whole system out). That not only maximises the damage, but also complicates testing. If software cores, you know it's got a bug (and often, where it is). If software renders the system fragile so that it will crash hours later, who knows?
Windows could be blamed for not handling 3rd software on a tighter leesh, but not be blamed for the fault itself.
When a worker falls from a catwalk with no railing, the employer that failed to have a railing is the one that gets the blame. Software should work the same way.
The only time I have ever managed to crash any *nix system during development was driver development. Otherwise, coredump, load the debugger.
Compare Microsoft's resources with those of the Linux hackers: M$ has a thousand times more money, M$ has access to every piece of hardware on the market plus early access to all the new designs still under development, for every Linux hacker there are ten M$ programmers and two dozen support staff. According to traditional capitalist theory, a programmer at M$, with his potential to become a millionaire from stock options, should be vastly more motivated than a Linux hacker working for free.
So why doesn't Linux suck half as bad as those products described in that article? Could it be that capitalism ruins everything? When a Linux hacker, or even a tenth-rate amateur hacker like me, produces a piece of code, we do it because we want a working program. When M$ does whatever you'd call what it does, it couldn't care less about how well the program itself works; the one and only consideration is, "how much money will this thing bring us?"
And it isn't just software. It's the pesticide-laden, hormone-laced food you eat and the polluted air you breathe; it's the way you waste five or ten hours of your lives each week sitting in traffic jams, because "the system" requires everyone to be at their work station at 8:00 AM sharp; and when you drag yourself home from work, it's the idiocy you're offered as "entertainment" on TV. See, food, water and air don't count for anything; the hours of your life are valueless; art is nothing but another commodity - the only fundamentally important thing, the one criterion by which all human effort is planned and judged in this society, is money, money, money.
The lust for money, accurately described in the Gospel as "the root of all evil," dictates every facet of American life, including even immaterial things like religion - nowadays, seemingly, a wholly owned subsidiary of the more pro-business of America's two pro-business political parties. Life in the U.S.A. is primarily controlled by the very rich and by corporations, and every day that goes by sees the corporate stranglehold over your life and mine, even down to the most insanely minute detail (e.g. what files do you have on your hard drive? the NSA has got to know! what did you smoke last weekend? piss in this cup so the boss man can check!) only tighten.
Karl Marx spelled out a potential solution a century and a half ago. But ninety percent of the people reading this post, having had their brains marinated in anti-socialist, pro-capitalist propaganda their whole lives, will be so spooked by the recital of that dread name, that they won't ever bother to even consider the possibilities of a different form of government than the absolute, unlimited reign of capital.
No! instead of that, we all must have faith in the all-beneficent "invisible hand" of capital! Everything will come out for the best in the end! Sure it will.
Yours WDK - WKiernan@concentric.net
The principles of The Mythical Man-Month also apply to open source, however. Obviously as you add people to an open source project, the per person productivity decreases. (Which is much of what Brooks says in MMM) The reason open source projects are successful are good organizational structures, which Brooks emphasized.
--
Gregory J. Barlow
fight bloat. use blackbox.
Gregory J. Barlow
fight bloat. use blackbox.
Anybody who read The Cathedral and Bazaar (most people here, I'm assuming), know that the entire PREMISE of the free software industry is "release early, release often" -- which means that free software uses the attitude described in this article, only on steroids.
I find it scary that people think this is limited to commercial software. The article mentions that there are 5 patches for NT 4.0 -- there are 12 for the Linux 2.2 kernel, and that is just for the kernel (in many cases, the packages distributed on top of that have patches also, there are probably thousands of patches and updates collectively to every packages distributed in Red Hat 6.0, for example), AND Linux 2.2 has been around for less than 1/4 as long as Windows NT 4.0.
Feee software usually doesn't have formal testing either. Instead of a dedicated testing team like most commercial software has, the testing philosophy is to release it and for users to test it. Not good preventive treatment obviously. Nobody is going to test if the new SCSI driver is going to wipe off your hard drive - it's left for the beta testers to find this.
I can think of five or six showtopper bugs off the top of my head in Red Hat 6.0 that would have prevented the release from cooming close to shipping out the door had it been a serious commercial system, but it was released anyways.
I have also looked at the source code for many free projects such as GCC and GIMP and noticed that the code quality was quite low. For example, malloc() calls were usually unchecked (especially in GIMP). I have worked on commercial projects before, and checking malloc() is rule #1 -- if you happen to run out of memory while using GIMP, it'll blow up, where as commercial systems will simply fail to complete the current operations. If such a high profile package is of such low code quality, I expect the lesser profile packages are considerably more buggy.
Want to produce really bad software.
It's easy if you follow just a few
simple rules:
1) Produce no documents - avoid creating
requirements documents, design specs,
etc. Just jump right into coding.
2) If it's a large project, divide the
work into several different development
groups, and make sure they don't
communicate. If they can be
geographically separated, so much the
better.
3) Don't hire any experienced
programmers, or if you make the mistake
of hiring them, don't listen to them.
4) Make sure that managers create
impossible schedules. Nothing produces
bugs like highly caffeinated over-worked
sleep deprived programmers.
5) Change requirements (unwritten of
course) frequently. Be sure and add
plenty of new features at the last
minute.
6) Be absolutely certain, that you don't
learn any lessons from industry history.
Don't read Brooks, Deming, Humphrey, or
any other Software Engineering or
Quality literature. And for God sake's,
DON'T look at 'http://www.sei.cmu.edu/'!
7) Avoid any and all code inspections.
8) Avoid creating any sort of
development processes, or if you do,
make them so pointless and burdensome,
that they are self defeating.
9) Do believe that you can test quality
into a product. But be sure to compress
the testing schedule just in case.
10) Three words - "Ship it anyway".
[Insert pithy quote here]
*Flame suit on*
Yes.
Question: When was the last time you returned an high tech item because it was flakey?
For the average Joe, I'd venture that the occurance of these events are far and few between. One reason is with complex items it's harder to determined exactly what the problem is, or who is at fault. Consumers are becoming lazy in their shopping skills. If I buy a knife set with a broken blade, it's easier for me to put blame on the manufacter than when I buy a piece of software. I know a broken blade when I see it, but do I recognize a broke program? How can I be sure it's not the hardware's fault or the operating systems fault?
Another Question: When was the last time you bought something new that had a users manual with a wiring scematic in the back? Manufactuers don't even bother anymore. They know that most of us are too clueless these days to figure them out anyway.
So the software companies can get lax behind their lawyers and their propertery magic while the world around them falls apart.
Back in the mid '70s, when I was at CERL, Sherwin Gooch came up to me on the verge of panic. He said something to the effect "We're dead. Software engineering is no longer a profession!"
What rattled his cage was a court case in which the defendant, a software engineer, was held immune to the claims damage by his client. In the opinion, the judge in the case held that software engineering was not an engineering profession in the same class as civil engineers, and that therefore the programmer could not be held liable for damages resulting from his software.
Sherwin was right. It has taken decades for the demand for highly skilled programmers to rebound from the lows they experienced in the late '70s when I was doing systems programming at Control Data Corporation's side of the PLATO project for about $20K/year.
Seastead this.
Pieces of this are true, the pressure builds up and management applies pressure, frequently in the wrong places.
I work for a company that makes specialized software for select clients. We have a sales team which goes out and beats the bushes looking for customers. We rarely have more than about thirty active customers at any one time -- we do a large project, deliver it, and get out.
My part of the project was babysitting the deliverable builds (the code builds that actually got shipped to the customer) and constructing the master images of the software the customer would receive. It would get handed off to the QA team, usually with the admonition "Important -- We must ship this today!"
Usually with this sort of admonition, you knew in advance that the disc you'd just sent to QA would go to the customer no matter what (since the inertia in fixing any problem was a minimum of three hours, plus the minimum three hours it takes to install and set up our product and run the basic basic basic smoke tests). And frequently, the contents of the disc were crap.
At one point, we listed (in earshot of the manager in charge of the project) the criteria for QA approval to ship. The candidate master must be round, gold, and have a hole in the middle. Someone observed that a maple dip doughnut could satisfy these requirements, and be just as functional in the hands of the customers. (More so, since they'd have something to eat while calling Customer Support.)
The root cause of our problem was that we were too customer driven. There are direct competitors in our space for the same customers, and the sales team is under incredible pressure to make the sale and bring home the deal. If that means saying Yeah, we can do that when they don't have the first goddamn clue about how hard it might be to do that. The contracts team then rolls in and agrees to many things with regards to functional spec and deadlines, and they are under lots of pressure to close the deal. The technical people who try to estimate the complexity of the requirements are under a lot of pressure to make the estimates low -- still competing against the other companies in our space, you know!
So these deals are impossible before the CEO (or whomever) finishes signing his name on the deal!
And then QA gets the heat to sign off on this candidate which would better be used as a drinks coaster!
These deals we write usually have performance clauses for delivery -- we agree that we will deliver the finished product no later than this date, and will affix penalties for each day (frequently in the area of $10K per day) that the product is late. There have been times we shipped blank tapes or CDs with a product label on it simply because we were contractually obligated to ship something. Now is that insane or what?
The big problem in our space is that no one is willing to say "no" to the customer. If you don't say "yes", then our competitors will, and we will lose the deal. It means that our competitors get the customer's money instead of us while the customer figures out the awful truth!
Our company even went so far as to regiment an ISO9001-like procedure that says every release candidate must to A, B, C, D... There's a form that each candidate has and it goes through each section from being ordered, built, tested and approved by QA, then duplicated and shipped. In practise, we ship a fair number of 'one timers' and dummy up the paperwork afterwards.
I don't know what the solution is. I know in our space the problem isn't likely to go away -- one hears stories of the competitors making huge deals that fall on their faces with the customers paying the tab. Sometimes we get to go in and try our luck -- sometimes not.
So what do we do? Listen to the technical people. You pay them big bucks for a reason! Walk away from sales that require the impossible. Avoid deals with financial penalties for late delivery. And stop trying to lay the failure or success of a product on the heads of QA! They don't make the product crap, it's already crap when it lands on their desk.
Maybe liability for software would help. I'm sure the company would jack prices through the roof to cover the added risk, but it would sure as hell focus the attention of the managers and developers and make sure the company wrote deals that made it better to deliver late software that worked and not the other way around like it is today.
Late and right beats on time and crap every time -- or at least, it should.
Take a guess what commonly worshipped software development beast is at fault for the problems you and others here have described:
The Hacker.
The Hacker is someone who spurns top level design, and just wants to "write code."
The Hacker doesn't want to hear from a usability engineer, he wants to "release often" and have random people all over the 'net find his bugs.
The software industry is permeated by hot dog coders who, umm, basically are just coders. It's a real problem, and is worse in the Free Software community than in the Commercial Software business. "Open Source," also known as "fix it yourself," while viewed by some people as the central philosopy of Free Software development, is also merely the least wobbly leg it leans on. So we end up with Byzantine software, designed by nobody, and added to by everybody, that works well at the things coders have felt a need for, but has a User Interface reknown throughout the rest of the world as cryptic. Emacs is probably the supreme example of this design philosophy.
Please don't bring up "Peer review" to argue against my point. The classic notion of "Peer Review" that has increasingly been distorted by "Open Source" advocates, has to do with a body of peers with credentials. Not the guy with the loudest mouth on Usenet.
So far the commercial offerings are pretty even with open source offerings. Everything crashes.
On my planet, the open-source OS I use... Linux... doesn't crash nearly as often as closed-source windows (95/08/NT, take your pick). Furthermore, most of the open-source apps I use exhibit a far higher level of base stability than their closed-source commercial counterparts, even though the open-source apps are generally far younger. On your planet, things may be different.
Life's a bitch but somebody's gotta do it.
The article, like the rest I've seen that covered this topic, never addressed the Alice in Wonderland quality to life when you're used to Linux and forced to buy Windows for something.
I normally run Linux exclusively and don't accept contracts for non-Unix work, but I recently needed business accounting software. So I bought the higher-priced software that I knew many of my clients used. It was Y2K ready. According to everyone I talked to, it was the best of the breed and could handle my company moving from single-programmer-in-a-garage stage to multimillion dollar company. (Yeah, right.)
It was such a load of crap that I demanded my money back (and got it, since their packaging did make a money-back guarantee) and am doing those tasks by hand while the Linux accounting packages stabilize. I decided I simply couldn't afford to lose any more weekends to produce a "professional" invoice after 6 hours of struggle, instead of whipping out an "unprofessional" one in 5 minutes with vi and lpr.
Some of the problems were related to the fact that I installed it on a laptop. The high latency display makes the "friendly" animations that appeared on every single fscking page a smear. But the software also clearly had absolutely no usability studies; e.g., I could enter POs but I never found a way to list open POs and associate checks with the PO.
Oh yeah, that was probably covered in the tutorial. The one that used lots of multimedia (always fun on a laptop) to train a clerk in advanced computer skills like using the mouse to pull down a menu. There was, as far as I could tell, no way to get a top-level summary for people who know computers but not accounting.
On the bright side, the company was willing to offer me support. At a fee for each incidence, and the fee was apparently *not* waived if the bug was because *they* screwed up the configuration. Nothing gives you a warm feeling like spending hundreds of dollars on a commercial accounting program, hitting 'create new business' button and watching it shit all over the floor because it's missing some value in one of its VB scripts. (That warm feeling is enhanced when you see that they want to charge you money to fix it. I think the feeling is due to acute alcohol poisoning....)
Oh, I almost forgot. A few months after installing this program my laptop took a hard crash. I picked up a virus even though it's never attached to the net, always in my physical control, and I only install commercial software in the original shrinkwrap. Surely a coincidence.
I actually enjoy it now when people tell me that Linux is hard to install. I tell them that I routinely install Debian in less than an hour, it takes me longer to burn the CD-Rs than it does to build a working system. But let me tell them about how long it takes me to reinstall Windows from my Toshiba disks (although that's not really fair since two hours are consumed removing those packages always in high demand in professional offices, like the big Disney Channel icon). Or let me tell them about the last "big, easy to use" Windows application I tried....
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Well, to begin with, I meant that comment as a reference to extensively huge code that you couldn't hold in your head anyway. That said..
One problem I've noticed with a lot of C++ programmers (and hopefully they are still novices when they outgrow this mentality) has to do with the following.. C was a hammer, and C++ is a sledge. We have C++ because there were a few railroad spikes that C just couldn't nail down as elegantly as we would like. Unfortunately, now some people always bust out the heavy ammunition.. But to be honest, not every problem is a railroad spike. ;) C++ is deep and complex compared to C, and how complexly you program something should be directly affected by how complex the program needs to be. Not only that, but even if using C++ is deemed appropriate, you don't have to overkill just for the sake of overkill. =P
In the end, a program is only as good as the programmer. Better tools often make for better work, but even a sledgehammer won't help a stumbling buffoon nail down a railroad spike if he's too drunk to even stand still..
Anyway, enough of that.. I'll now simply comment on the post as a whole: I agree. Excellent points, all.
~ Kish
... sucks.
:-)
/. of late have talked about all the boundless opportunities for people skilled in software?!!
I am a software developper. Even if I can't spell it right.
While I haven't read a single comment on this article yet, I am willing to bet that most are "great article" comments from people thinking that it is the boss' fault. Let me ask you this: Who told the manager that they could do it in three months? Who didn't tell the boss to fuck himself when he moved the ship date up six months??
Jesus that article riled me up! It makes my profession out to be a gang of unprofessinal 31337 dudes who like to do nothing but play Quake all day, scarfing pizza and mountain dew and whine that they didn't get enough time when the ship date draws near.
If you see the development taking much longer than you originally estimated, you get off your ass and tell your boss. You tell them as soon as you see the problem, not 1 week before the ship date when nothing can be done. You don't sit there and pull all-nighters trying to get it working at the last minute. I know; I've been there. If your boss won't give you more time you tell him that the product will NOT be done and will be full of bugs. Walk if you have to. How many articles on
What else... oh yes... the "big code can't be tested" arguement. Whatever happened to programming modularly, testing it thoroughly and eliminating the bugs through good software design? Oh yeah, I guess that's too logical. The shuttle/MRI/microwave/car/elevator/aircraft computer programmers must have it all wrong, after all. Thank God someone in the games field has it right!
"PCs are all so different!!" Gimme a break! If it doesn't work on PC 'X', and you suspect hardware after you've elimiated all reasonable doubt that it's your software, you buy PC 'Y' and try it. It sounds like these guys have zero problem solving skills! Also sounds like they're programming too close to the hardware; that's what APIs are for and if the APIs are bad... well then at least you've done what you could and can try to contact the vendor for a workaround.
No software can be perfect; another fallacy. Sounds like laziness or lack of time. Or both. Either way, most people know what they're getting into when they sign on, or they find out shortly thereafter. Either way it's ultimately the programmer's responsibility to make the code good. Bugs will crop up after ship date, but if you've programmed correctly and used proper coding procedures you will have a detailed map of what goes where and can test inputs and outputs to find out exactly where the bug lies to correct it and bring you that much closer to a perfect program.
GIGO -- it's as simple as that. If you hack it together, you'll be hacking it forever. Stand up for your rights and stand behind your work. Whatever happened to being proud?
New York, NY, Jan 13 -- People for the Ethical Treatment of Software (PETS) announced today that seven more software companies have been added to the group's "watch list" of companies that regularly practice software testing.
"There is no need for software to be mistreated in this way so that companies like these can market new products," said Ken Granola, spokesperson for PETS. "Alternative methods of testing these products are available."
According to PETS, these companies force software to undergo lengthy and arduous tests, often without rest for hours or days at a time. Employees are assigned to "break" the software by any means necessary, and inside sources report that they often joke about "torturing" the software.
"It's no joke," said Granola. "Innocent programs, from the day they are compiled, are cooped up in tiny rooms and 'crashed' for hours on end. They spend their whole lives on dirty, ill-maintained computers, and are unceremoniously deleted when they're not needed anymore."
Granola said the software is kept in unsanitary conditions and is infested with bugs. "We know alternatives to this horror exist," he said, citing industry giant Microsoft Corp. as a company that has become extremely successful without resorting to software testing.
[I don't know who wrote this. I wish I had. -- ES]Question: For similar levels of complexity, why do software systems typically exhibit many more bugs than (digital) hardware systems?
:-)
Answer: Because the component parts of hardware systems are almost entirely isolated from each other internally, ie. almost all interaction is through the component interfaces. When one part fails, the others continue working: in computing terms this is very much as if each part had its own processor. The failure of one part can of course stop the hardware system as a whole from functioning productively, but it is far more common that only part of the overall functionality is affected.
Solution: Use the MMU to isolate software components from each other and to make their internal structure entirely hidden, leaving only their interfaces visible (an OO approach is implied). Then multitask their methods using a dedicated event-driven component scheduler.
Needless to say, this would require a dramatic change in almost all our software tools as well. Backward compatibility would be minimal.
In academia I used to do research in hardware/software for parallel OO systems, and this is one of the ideas that popped up. I've had a design for a Unix Object Infrastructure based on this approach on my whiteboard for some years now, but the spare week of kernel hacking I had planned has never materialized. Perhaps this should be turned into a Linux or BSD community project instead.
It would be rather nice for the free/open operating systems to take a quantum leap beyond the traditional Unix feature set, and possibly solve or at least reduce the woes of the software engineering industry at the same time.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
The following snippet of wisdom is attributed to Arthur C. Clarke: "Any sufficiently advanced technology is indistinguishable from magic." You've probably seen it come by thanks to /bin/fortune. For all intents and purposes we are at that point today with computers. Now, of course, if you ask someone, "are computers magical?" they will respond in the negative. But consider how people treat computers and how people treat mystical or magical objects. Magical things are acausal, random, and only to be handled by the priesthood. Computers are acausal, random, and only to be handled by the (computer) priesthood. In this regard, the flakiness of computers adds to their mysteriousness. And even the priesthood is not immune to this. The first thing a computer programmer will do when his or her program crashes is to run it again! As if maybe this time it will work and the bug will just be gone somehow. The social implications of magical technology are huge -- without a proper understanding of what technology is and what it can or can't do (and how it should or should not behave), the general public will continue to accept buggy software and, when it crashes, attribute it to the anger of the gods.
Nowadays most software failures are considered annoyances rather than catastrophes. Because of this, they don't justify the time and money it would take to advance the state of the art of software development. Nothing will happen until users recognize how much software, and for that matter hardware, failures are costing them, and start refusing to pay those costs on top of what they are already paying for the software itself, and become willing to pay the upfront costs to stop them in future development. That recognition will not come until something catastrophic happens. It will only be when enough people die because of a software failure that enough attention will be paid to the state of the art to make some genuine advances. Until then we'll be stuck with meaningless exercises in paperwork such as ISO 9000.
Maybe then we can actually get some standards for hardware as well, so that the operating system doesn't care which sound card or which video card or which printer it has installed, just like when it sends email it doesn't care whether it is going to a Macintosh, a Linux box, a Windows machine, or a TV set.
People should not fear their government. Governments should fear their people.
While I'll grant you all of that, the guy who's post you're responding to was discussing publishing. And on that note, many compositors still remember how to shape, reconfigure and transmit paper. It's messy and slow but we can do it. Because our _real_ media has been film, not paper. Except for the few lucky souls with digital presses, it still is. All hail film.
obProgramming: film based computers would just be like really really slow crt based computers (which were used in the 40s and 50s, IIRC)
-- This and all my posts are in the public domain. I am a lawyer. I am not your lawyer, and this is not legal advice.
It could have articles and documents about the software design process that programmers can learn from and send to their managers.
Some interesting topics:
It would be a great first step to cluefulness.
I'd be more than willing to help out in any way possible. I've had a lot of success with bosses in my own professional endeavours.
But then again, my bosses have all been experienced engineers who actually listen to me and respect what I say. I guess I'm very lucky.
Even when there exist objective criteria defining what software is intended or supposed to accomplish, and even when there exist objective and consistent criteria concerning aesthetics of UI design, art and related subject matter, software is just plain hard to make.
Software is much tougher to make than soap.
Why? Because even a relatively trivial program involves express specification of changes to a massively large state space. In the analog world, an engineer infinitely narrows the scope of vastly larger state spaces to be considered by making assumptions that things behave continuously -- not so with code, which grows combinatorially and discontinuously complex with each additional variable, object or control statement.
Nowhere does this become clearer than when one is asked to engage in true quality control: proving a program correct. Methodologies that work beautifully and elegantly in the small to demonstrate the accuracy of a code segment grow unmanageably out of control when facing a 100,000 to 1,000,000 line program. And in turn, we then have the bugginess of the proof --viz. was the spec specified adequately-- to consider as a new "quality control" issue).
Even the very process of quality assurance in code is harder than Q/A for soap. A scientist may often presume safely, and can often prove, that if the soap behaves properly at two ends of a temperature range, that the soap will behave properly between them. This is almost never the case with code, it being in the nature of digital things to exhibit discontinuous behavior.
The bottom line is that excellent code is enormously expensive -- requiring only the brightest, best and most sophisticated management, quality assurance, design engineers and technicians. Noone wants to pay for what they claim they are entitled to expect. However, this is like most things in life. You can get:
Good. Fast. Cheap.
but you only get to pick two.
Regrettably, management is evaluated more closely for fast and cheap, so noone really worries about good, just so long as its "passable" (and its often easier to pass blame to the coders for "good" than it is to blame them for "fast" or "cheap").
AFAIAA though, Microsoft aren't heading in the direction of hardware-assitance for their component architecture. They should. It might allow them to get back in control over their big unreliability problem.
While it may not be quite so urgent for us in the free/open operating systems world, I think it would give us an interesting spur if Microsoft suddenly came out with this kind of thing. It might jolt us out of our complacency and move the Unix architecture on a notch.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
...ah, but those particular ones tended to be fixed in patches. Kinda like...
user feedback: "Btw, your AI players get
infinite-range missiles."
Firaxis: 'k, we'll fix that in a patch.
{ patch fixes range for planet-bustin' missiles,
but *not* for conventional missiles -- which
nominally should have the exact same range }
user feedback: Huh?
Firaxis: 'k, that'll be fixed in the next
patch.
Strange. {shrug}
Only the dead have seen the end of war.
That's dumb. OSs like Windows and Unix allow considerable extension. If you don't do it right it's your fault.
When writing a driver, yes, that's true. That's why I DON'T blame *nix when my pre-alpha driver blows the system up. My point there was that writing a driver is the ONLY time I have managed to cause a *nix system to blow up because of anything I coded. Windows (NT, 95 ) on the other hand are not nearly so robust.
NT can hardly be blamed for application crashes.
I don't blame NT for application crashes, I blame NT for allowing those crashes to spread to other processes or the OS itself. It's my job to keep my app from crashing, It's the OSes job to keep your app's crash from crashing my app.
NT will terminate the process and report the error - or if it's a kernel level driver - do a BSOD to protect other processes.
Interesting concept, murder/suicide to protect the innocent. Seriously, my problem with NT is the number of times it FAILS to terminate the errant process to protect itself and other processes. Instead, the process gets away with a few things and de-stabilises the whole system. The programmer didn't catch the bug because the process didn't get terminated during testing either.
Short summary, if you defeat the safety and get hurt (write a driver and crash the system) it's your fault. If the safety fails and you get hurt (normal application crashes the system), it's the system's fault (and ultimatly the designer of the system). NT's safety seems to fail a lot.
It makes no sense to measure reliability in numbers of patch releases, especially when comparing proprietary with open source software. How much is fixed in which patch? Remember that open source software makes orders of magnitude more releases than closed source software, by design and for those who want it. Linux has distributions so that end users don't have to deal with the pitter-patter of little releases.
Look, I'm a full time EE and I work upteen hours every week. If you think I have time to fart around with buggy, unreliable software like Linux and its ilk and submit my patches you are dead wrong.
If you don't have the time to fart around with Linux, what do you have the time to fart around with? I'm not ready to say that Linux is the most reliable OS around, but I am ready to say that it is in the upper echelon. That is, other OSs may be more reliable than Linux, but it seems that nothing short of mainframe-style enterprise OSs is much more reliable than Linux.
If you're talking about enterprise-level systems like big-assed financial mainframes, I agree. You don't have the time to fumble with Linux--it's not built for the Big Guys (for that matter, neither is Unix). If you're dealing with Unix-sized problems or smaller, Linux is about as reliable as you're going to get.
At my network shop, we have three platforms: Solaris/Sparc, Linux/Intel, and NT/Intel. From our experience, Linux/Intel is about as reliable as Solaris, and much more reliable than NT. IMHO, Solaris is the Unix benchmark, so Linux is beautifully reliable for the types of jobs it takes a Unix box for.
--The basis of all love is respect
I think alot of software companies have missed the boat with the average home user:
If it's too complicated, they won't use it.
I'm not saying that they're dumb, they just have better things to do with thier lives than deal with something that's too hard to use.
Amen to that, brother.
I am a programmer, and I do a decent amount of word processing to document what I do (because I'm lazy, in the Larry Wall sense). I have Word (corporate standard, not my idea). I can keep 10 KLOC of Perl in my head. I am not just a luser.
I can't get Word to do what I want it to do. There is simply too many possibilities, too many ways to screw up.
Where's SpeedScript when I need it? Where's LaTeX?
--The basis of all love is respect
Show me some major bugs in NT that stops software development.
That comment is revealing in itself. Most people use 95/98, not NT. So why did you limit it so particularly? (And I see you've done it again in *another* posting on this thread.) I personally have to reboot 98 at least once every evening I use it, for some mysterious leak (that has survived the 95->98 upgrade, changes in devices, etc.)
I still hear bug reports for the app I work on where the toolbar buttons have disappeared. This was caused not by a bug of ours, not by an OS bug, but because the user installed Internet Explorer 4.0. So I guess IE really is part of the OS...
Things about Windows that have made development more difficult:
1) NT vs. 95/98, where the two have similar but not bug-for-bug identical APIs
2) DDE vs. OLE vs. DLLs vs. MCI vs. COM vs... 10,000 different ways to share data and code rather than getting it right the first time.
3) Changing the OS with their own apps, like the IE 4.0 thing mentioned above.
4) Once they move onto the new feature set (such as 98 vs. 95) they'll never touch the 95 code to fix bugs again.
5)... there's more, but I have work to do.
Part of the problem is that OS bugs, once detected, are the most difficult to "fix" (more properly, to work around.) Often they require the developer shift platforms to create the workaround. They may introduce inefficiencies for users who wouldn't have the problem to begin with. And there's no way to really fix the problem, since you don't have access to the source. And get the OS company to fix it? Hah! For one recent bug, I would need a fix for a product the OS company has dropped, and they laid off/transferred the entire development team (Apple and the QuickDraw3D team).
Ooh, a sarcasm detector. Oh, that's a real useful invention.
I think the thing that people don't understand is that programming is the only place(well okay, genetics is the same too) where your work must be perfect. You can inject typos in essays, we get the message. But you inject a mispelled command in a program => crash. I don't think everyday people understand this concept. You can't just do an allnighter, and get a "B". It must always be perfect.
"Capitalism ruins everything."
..."
... ) So, OK:
... pesticide-laden, hormone-laced food"? Ah, strictly a capitalist invention there, you betcha! If you want some good wholesome pollution, or were wondering what the practical upshot might be between mostly-capitalism and sort-of-socialism, visit the former East and West Germanies, or the countryside outside of Prague, or many many places in the former Soviet Union where toxic (including radioactive) waste was brazenly poured into lakes and rivers. TMI and the Love Canal have nothing on consequence-free socialist management policies.
Suuuuuure, it does. Right. "Tell me again how sheep's bladders may be used to prevent earthquakes
Responding to the entire post would overlap with the comments arelready posted (and as Mark Twain would say, would annoy the pig), but a few things stand out as too silly to let fly (and make me suspect that the whole things was flamebait anyhow
- "
- Time wasted in traffic jams? Surely you jest. Would you rather be waiting 10 years for a car, or queuing for *bread*? How about signing up 6 or 10 years in advance to get a telephone, and paying your brethren electrician a few bribes along the way? And besides, you don't have to take that job if you don't want it. Sorry. ("Aw daddy, I like all these diamonds, but they're so heavy! Why did you make me take so many?!") There's no pleasing some people, I guess.
Get this much straight: Capitalism is actually fairly agnostic about what you *do* within it; it defines certain things as moral (free exchange of goods, including services, including philosophy, including whiny, illogical peaons to governmental oversight and meddling in everything, etc.) and after that, you're on your own to find the path you think is best. Captitalism defines possibilities; socialism draws up job lists.
Cheers,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Good point, but alas I doubt if the world is ready. We've lived so long with the current standard style of programming that the lessons learned on the specialist machines that emerged from the AI scene have been entirely forgotten, it seems to me. They were just too far ahead of their time.
It's an interesting analogy though. Perhaps a hard object-oriented system architecture could fire the imagination in standard computing circles where a list-based architecture previously failed.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Sorry to disappoint you, but I'm a software professional, not hardware, although academia did teach me how the hardware fraternity did things because the EE and CSc sides were very sensibly integrated.
That was a previous life though. The lesson that the real world then taught me is that software is more complex than hardware only because it is architected on an appallingly bad infrastructure that makes it almost impossible to increase the size of a software system without making complexity go through the roof.
The reason for that is simple: lack of system-guaranteed isolation between components, which means that thirty years of development of structured programming languages *still* results in an unstructured nightmare in the presence of faults. That doesn't happen in hardware, except in the single instance of the power rail(s) being compromised by a major failure.
And it's precisely at that problem that the above solution is targetted: to provide a little hard structure to control the programming complexity in the same way that the O/S controls the complexity among interacting processes, a well tried and tested strategy it seems to me.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Those are all good points, but you've missed something. Yes, software systems are often much more complex than hardware ones, but why? After all, hardware systems sprawl out across the entire globe in an interconnected mesh, yet when the hardware of a router in Paris goes down then the hardware of the rest of the Internet continues quite happily doing its thing. How come? Let's examine this a little more closely.
Add software to the equation: now the software in the router in Paris goes down and, excellent, the software in the rest of the Internet continues happily working away. So far so good.
Now consider that router again, except this time look inside it: its SNMP module (just one component of hundreds within the router's O/S) decides to express a coding bug, and what happens? Ooops, IOS has just trashed everything in memory and the router reboots or hangs indefinitely.
What's the difference between these scenarios, and especially between the two last ones in which it is software that has failed? Simple, in the first two cases, there is faultline isolation between the components of the system, whereas within the router's software there is no isolation between software components in the presence of a fault at all. So many years of structured programming, all for nought.
*That* is a key reason why software is more complex than hardware in so many cases. It's not just a matter of size and of the number of internal states. Complexity can be controlled by a simple strategy of divide and conquer, as long as black boxes can be made truly black. In standard computing, this is impossible in the presence of bugs, and all large systems have bugs. The approach is utterly flawed for computing in the large.
What I'm proposing is a little extra structure to control the chaos, because chaos is precisely what the software world is fighting, although it's rarely expressed in those terms.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Yes, those are precisely the main areas of concern. You can definitely get good performance for a small number of large objects, but PC MMUs aren't really intended to cater for huge numbers of tiny objects directly.
However, creative design may be able to overcome the problem to some extent if some feature can be exploited to make a good tradeoff, rather like caches do in another problem area. Whether this is possible here remains to be seen.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
Almost all serious windows developers use Windows NT. This is a developmental issue is it not?
Of course developers develop mostly on NT, but the applications they develop run mostly on 95/98. As an example of where this screws things up in the app I work on, we had a crash that appeared only on 98, and only on certain machines. I attempted to set up remote debugging on that machine, and it refused to work. I put MSVC on that machine, and it crashed while compiling. I was never able to fix that crash. Apparently it "went away" thanks to other changes in the code, but as far as I know it might reappear on any new compile.
Unix/Linux machines often give you core dumps -- memory images of the program when it crashes -- which you can then use a debugger on to find the point in the code where it crashed. While this doesn't matter to the developer who is generally running the program under live debugging (MSVC isn't perfect, but it's not bad either), it does mean that it's harder to track down problems discovered by alpha testers (people in the same building.)
I mean, what Win9x application have you run on NT that goes all funny?
First off, there are a whole bunch that don't run at all. Second off, we've had to write workarounds for things that work in NT, not 98. Mercifully, I personally haven't had to deal with them much (other than the above crash), but I hear plenty of kvetching from my coworkers...
Sorry, I just don't have the time to respond more, but DDE and OLE are totally different (DDE is text-based, OLE is like published C++ classes), and you still need DDE to do thing like change the start bar; installing an app shouldn't change the OS (and break other programs) at all, no matter what the app; and the Linux guys have issued 2.0.x revisions even after 2.2/2.3 started.
Ooh, a sarcasm detector. Oh, that's a real useful invention.