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!
Just one more reason why to keep software within GPL. Tho I must admit, companies developing software for Windows versions should be exempt from scorn over bugs. In all reality, how is a company supposed to put out a bug free program to run on top of a bug-riddled OS?
Hehe I'm first now :P
To err is human,
To really screw up, you need a computer!
Most software sucks because of Moores law. Until researchers "hit a wall" in processing power , what posible insentives to people have to maintain/treek/improve/optimize code when it's going to be scaled out of relevance in a year? I think Moores law/marketingtrend could slow down just a little bit.
On the other hand, I wish that most users would have some appreciation for the vast complexity of even apparently "simple" pieces of software.
You cannot have your cake and eat it too. If the software industry had the same stringent standards as other industries, 99% of software would not exist.
If users weren't so rabidly feature-hungry, we wouldn't be in this mess. Unfortunately, users expect that each new version of software will have 23,456,236,263 (I counted) new features in it or they won't buy it.
Can your IM do this?
I teach an intro to computers class at the local library. Before I begin class, I personally apologize for the poor quality of commercial software the class has to use (you can guess which OS). Commercial software vendors get away with things that attorney's general would prosecute for if not software: false pretense, misleading advertising and faulty products in violation of product protection laws. I'm ashamed to have contributed to the mess over the last fifteen years I've been "in the biz", but of course, I've had little control over the Big Picture. We can only do our small part and hope it makes a difference!
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
There's plenty of reasons commercial software is buggy and I think they're pretty obvious:
1. HUGE teams of programmers working on different parts of the same program. One person can easily do something that causes a conflict with someone else's code.
2. Wide variety of hardward people run. They can't really test their program on EVERY possible configuration, can they? This has to do with programmers of drivers and OS software though too.
3. As mentioned in the artice, unrealistic time demands put on the programmers by management.
they should have this information burned into their brains.
i just do dopey little stuff when i program, but when i finally show it to someone, its a matter of pride in my abilities and knowledge. if i was to release a program that had errors in it, i would look bad. most software companies should allow the time for extensive beta testing and to let the programmers pour through the code.
this is also where open source would help out tons. if you had to release the source, you would:
1)have a MASSIVE base of programmers that could be working on it.
2)you'd be more likely to fix errors before releasing it. if M$ released win9x source code, it would probably be more humorous than informative.
3)there would be more healthy competition because the company who has the best code with the fewest errors is most likely to get the most customers.
thus ends my rant.
icq:=22921393;
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!".
First time I heard of this magazine... From the article I've just seen its very cool indeed. They even say the dreaded "f word" several times. I'll have to subscribe to it now :)
what game is it that the article was talking about in the beginning?
I admit, I actually waited until posting on /. until I could get a first post. However, once that post was made, I felt cheap...cheap and dirty. I didn't want to waste time writing a meaningful post, because that leaves potential for someone to click "SUBMIT" before I do, and I couldn't have that. Besides, I later realized that I was moderated down so far, that the glory was so short-lived it wasn't worth it.
-I9mm-
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.
if there's bugs, the company can release Version X.X and get more money, to pay more people, to pad the exec's pockets a bit more, so they can have more bugs in the next issue, so that they can release....etc etc etc..
heck, if windows was right hte first time, why would we need win2k? if linux 1.0 was had been perfect...why would we need 2.0.0.0.0.0.0.0.0.0.0?
granted, its not always about money. sometimes its a simple over site, or a situation that the testers/programers didnt think about.
Gorfin
Why would a company code at all? Just wait for your competition to write the program, then undercut them in price, since you don't have to recover development cost.
Je ne parle pas francais.
Software was easily usable, a few years ago. That was in the old days of structured programming, when business programmers and dinosaurs roamed the earth.
Then object oriented programming took over. Dbase and Wordstar did the darwinian thing. And feedback by business users ended. Programmers were free at last! And this was good. So sayeth Gates.
You didn't know that, did you. The biggest purveyor of OOP was his Billness. That's why software sucks, it all uses the method of Redmond.
Except, of course, the Linux kernel, which is still written in C.
It all boils down to money, mr. eries.
If all of these features didn't make users continually re-purchase the software (like "upgrading" to Windows 98, or 98 SE) it probably wouldn't be done.
Almost all of the software that i use is free (and legally so!). But the common user wants software to be easy-to-use and helpful, (like "Clippy" in MS Office... Ugh.) so they would invest the money for these new features.
They think that if they pay money for software, they'd be getting more performance than a free product; in most cases that is not true, as you probably know. People have to realise that in "CyberSpace" the old rules don't apply. Software is not really a tangible thing like a donut or a car is. Thus, the standard rules and laws can not apply very well.
Just my 1 1
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
1) The stock holders don't like it when the ship date isn't met because it drives the price down.
2)Marketers don't like it when the ship date isn't met because it means the product will not be released when people are most hyped about it.
Would one possible answer be that software companies should be more vague about their ship dates? Announce specific dates later in the project so that you have a better idea of what problems will have to be dealt with.
Though this would probably make marketing's job harder, it may keep the Wall St. boys happier.
The article mentions that most users prefer a smaller program that works, rather than a huge program with tons of cute features that is full of bugs. This is something that software developers need to keep in mind. At the beginning of a project a requirements specification is made. One should always try to follow this specification.
As a programmer it is very easy to look at a part of a program and say "Hey, wouldn't it be cool if this thing would spin when you press that button!" or something similar. Most cute features are things that the user wouldn't miss if it wasn't there, and they are very likely to add new bugs to the program.
It really helps to look at the program as a user, not a developer.
I wonder how many lines of code that stupid paperclip in MS Word takes, and who wanted it there, a user or a developer.
Phobos - Greek word for fear or flight
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.
Forgive me my ignorance, but isn't that what CTRL-ALT-DEL is supposed to do? Who uses that to exit a program?
I agree with most of this piece. However, I see other interests at work. Most of the people had interests: journalists, lobbists and soon on. I don't disagree about the fact that there is a lot of buggy software.
There also were a few inaccuracies. Win95 and Windows 2000 are completely unrelated. Win 2000 is NOT the successor to 95; 98 second release is.
As well the number of releases of Netscape is exagerated. If you count the service releases that Microsoft has released for IE then MS would have more.
And my final point. There is no effort made to see what the ultimate source of bugs is. Is it the OS, flaky web browser or the program itself.
And there were no examples of good software.
The software idustry is by no means perfect but not all software is fatally buggy. Good points but very one-sided.
I know that it is easy to blame the companies who produce the software (and believe me, they are certainly guilty in some regard), but what about the market that permits such software to sell so well. Isn't the user voting with his dollar, supporting buggy software, paying for yearly upgrade, simply because they feel that 'this is the way the software industry works'. Of course, there has been some monopolistic taint here that has prevented the market from stabilizing. Question: is the incredible rise of Linux a manifestation of the consumer's frustration with traditional software? Just trying to examine things from a different perspecitive.
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?
As a software developer (and the only guy in charge of a 200kline application), I can't agree with this more. The market shouldn't dictate the release date - the programmers should. Any programmer worth his salt will know when a program is ready: the testers like it, the code is clean, and he can't find anything wrong with it.
Software, like anything else, should be taken out of the oven when it's done.
I just wonder how the industry got this way. Why can't other industries squirt out crappy products at everyone else?
Or is it just that most industries do, and that's not OK for an industry that makes products people rely on?
Perhaps it has something to do with the userbase: instead of making products for geeks, we're making products for non-computer people these days.
This article should be mandatory reading for all programmers *AND* managers.
-- I can't think of anything witty to put here. Sorry.
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
I actually stole that from someone (name begins with a 'k' perhaps? sorry, whoever you are) in a comment a while back. It wasn't exactly like I have it, and it wasn't called Gates's Law, but I thought it would be funnier if people started repeating it as Gates' Law. :)
Gates' Law: Every 18 months, the speed of software halves.
CTRL-ALT-DEL in Windows normally a) gives you a desktop back (if you're in a fullscreen game or something) and b) pops up the Task Manager, where you can kill errant programs. Of course, there's also option c) BSoD, which happens waaay too often.
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.
Ship first, fix later. So long as your program
largely works, and doesn't corrupt data, it's ok
if it crashes or misbehaves occasionally. It's
more important to be out there and be largely
feature-complete than bugfree. So long as the
patches come often, it's far better to have
something that mostly works and has a lot of
useful features than a product that's far less
featureful than the opposition and bugless.
For every problem, there is at least one solution that is simple, neat, and wrong.
I have the pleasure to manage a release at a small software company that will release its project at the middle of this month. We didnt have a feature freeze yet and i will be happy when I manage to freeze it before the end of this week... :)
Once a week someone from the management comes and says that feature X is essential for the customer and that we cant ship the product without X. They start huge discussions about features that are almost impossible to implement and dont make much sense, only because they make cool buzzwords that can be used to impress customers... There is one programmer who cant see the need for a feature freeze and still wants to do small 'fixes and improvements', even if they are not neccessary for the release, and I cant stop him without causing a lot of trouble in the company (and of course, the management likes his 'improvements'). And there are the (closed-sourced) libraries and runtime environments that our product relies on and that are buggy and cannot be easily removed. When I go to the management I tell them I have to rewrite this part to get rid of the lib, they will tell me 'good idea, but first we need this animation in the dialog'.
The problem is that most people who do not develop software, and even some of the developers, dont understand how to stabilize software. We cannot (like Linux) have a 3 month code-freezed period, they dont understand it and think that we want to do a 3 month vacation...
Of course, most customers dont have a clue either. The classical NT user prefer things they can see to things they cant see. And stability is not something you can see... They get what they deserve.
(BTW, is there a serious company out there that wants a Java/database programmer?
I think this line of reasoning entirely validates open-source/free software concepts, the whole idea that "With a million eyes, all bugs are shallow".
They mentioned the idea that once a sofware project gets to be a few million lines of code, no one person can hold all of those patterns together in their mind. But with hundreds of people interoperating _transparently_ and openly sharing the information of a million-line program, it can be held in the collective conscience quite adequately.
I know that alot of people will probably post here, "hey yah, open source rulz!" and similar sentiments. But it nonetheless refreshing to feel a little validated by other people not directly involved in Free software.
Check my Go-related blog for beginners: DGD
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
Illiad didn't start this. People have been making "first posts" on slashdot for a long time...Also, did you think Illiad just decided to make up a "first post on slashdot" phenomenon for the comic strip?
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 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.
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 tried to print out the web page, but netscape crashed on me.
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.
When things start to slip behind schedule, several things are often done - programmers code like hell, often on little sleep, and more people are added. Both screw things up, and _will_ make things later and buggier. Management & marketing toying with features & ship dates are also a recipe for disaster.
One way to enhance software design is to make it much easier to sue software makers for lost time and money due to bad products, and get rid of those end-user agreements that try to limit liability.
Finally, why do programmers try to pull all nighters and program on 1 hour of sleep and 32 mountain dews? Idiots. No one can work well that way.
It seems publishers of software products often take care of "testing" the software for the companies which create it. (ie: Activision does some testing for id software?) Why not have these companies that test the software release information about the bugs they find? Even, just make up some way to rate a product, and put that rating on the box somewhere. Similar to the current "movie like" ratings you see on computer gaming products. A bug rating of "A" would represent a minimal amount of bugs found during testing. A rating of "F" would tell consumers that there were many bugs found during the testing phase which were not fixed before the product shipped. If there was a central body that oversaw this rating, I think software companies would quickly clean up there act after there software got a "F" rating for bugs.
:)
Of course, does anyone look at those "movie like" ratings on games anyways?
Open Source Time and Attendance, Job Costing a
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.
Pirates!
Why do I need dongles/key disks?
Pirates!
Why am I required to have the software call some server on the modem periodically?
Pirates!
Why does most software suck?
Pirates!
Yes pirates. The software makers scapegoat for everything.
I mostly agree with this article, however I think the industry will stabilize. I believe that more and more software/hw purchasers are starting to realize just how buggy software is. The market is going to mature, it is just a matter of time. When enough people get hurt in sufficient proportions, things must change. Its simply a function of the market; consumers haven't been demanding quality software. When they do, software will rise to meet those demands.
I think that the recent press attention given to Linux and other open source efforts is one of the first signs of movement. Most people couldn't care a less about "free" software, what they're looking for is more reliable, yet functional software. The linux community is starting to provide sufficient functionality where most people can consider it. However, this does not mean that Open Source must (or will) supplant commercial software. Just that the Open Source community offers the first enduring choice, commercial companies are going to turn around. They might adopt psuedo open source solutions (eg: Sun's recent licenses), but effective quality assurance and simplicity can stop most all of these bugs.
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.
you think you're a programmer? do you think you're a quality programmer?
You're ignorant.
Encapsulation and modularization are your friends..
This is particularly true with operating systems, which have skyrocketed in size and developed thousands of byzantine byways. Windows 95 had eleven million lines of code; Windows 2000 is slated to have a mind-blowing twenty-nine million.
..too bad the people from Redmond don't make nice to these two potential buddies..
Lets take windows 2000. that 29 million lines of code isn't ALL the kernel. Windows 2000 is the MOST modular OS I know of. Everything you need is either in DLLs or even better - as COM objects.
The source code to Windows 2000 isn't all in 1 files you know.
In that 29 million lines of code - include IE5, IIS, DirectX, and all the programs and utilities that comes with W2K.
they aren't being developed out of one source file, they are modular. Lets say that someone doesn't like the look of the quicklaunch bar on the starmenu and wants to add another one. He doesn't have to change shell32.dll or explorer.exe, he just makes a COM object with the coorect interfaces (IBandObject, IObjectWithSite etc) and adds it to the registry.
Complain about Windows, but not about it's modularization. Just cause we use COM don't do lame things like executing utilities and capturing output.
..but as I was reading that article Navigator 4.61 pulled the ol' Bus error crash. I just had to laugh.
Mark Twain has a famous quote >If I had more time, I would have written you a shorter letter. Implying, that with more time to think through his ideas, he could express them more succinctly.
Not all software gets bigger with time. I know of one exception. It's an SQL Anywhere product with a Powerbuilder front end. It tracks the money coming in. It fits on a very tiny portion of its CD. It's very fast, stable, and has very few bugs. I haven't found any after a year. It runs on NT.
It CAN be done.
This article is written from a Windows-user point of view, surely (i.e. by someone who lives in a world where software does suck, bigtime). How many of those comments does anyone think applies to 'free' software?
We've really noticed how when our project gets email, the Windows users are "Hey! I've downloaded your software so you owe me a favour, and I want this changed, do it for me NOW!" and the ROTW (Rest of the World) is like "Thanks for trying guys, btw, maybe you could improve it by coding this idea/applying this patch)".
All your ghosts are just false positives.
Crappy software will always exist because not every developer really cares about their product. Just like how their will always be at least one construction company that builds shoddy houses.
For free software the solution is easiest. Try it and if you don't like it you didn't lose anything.
For commercial software the solution is easy, if you don't like it, don't buy it. If you don't know if you like it, don't buy it.
Unfortunately, unwitting people will commercial software without trying a fully functional evaluation (if available). These are the people that get screwed by exchanging their cash for crap. These are the people we need to protect with a suitablity-for-use law.
By opening the door your new car, you agree to the following: 1) If the car explodes, too bad 2) If it is missing features we say it has in the advertising, too bad 3) If it is missing a tire, too bad 4) If the white plastic shrink wrap was missing on delivery, send the car back within 90 days
I've read many comments about how the software industry isn't like other industries, and I think it is all full of crap. Why aren't they?
They make a product. They sell it to the masses. The masses buy it.
Software is indeed a complex entity, but we're accustomed to dealing with complex products. How many of you own an automobile? How many of you know more than curosy knowledge of how the car works? How many of you know your car so well that you can break it down into bits and pieces and put it all back together again?
I imagine that the answers are Most, Few, Hardly Any.
And in fact, we've seen shitty cars being made. We've seen them sold to the masses. And we've seen the masses buy it.
But someone decided that enough was enough - for whatever reasons - and Ralph Nader published his infamous book, _Unsafe at any Speed_ , and the public woke up to the reality that they didn't want shitty products, and the companies changed the product to reflect what the consumers wanted, not just what the bottom line was. And it worked.
Albiet, most software crashes don't kill people, and it will be harder to convince the masses that they don't need to stand for shitty software.
It probably won't be because someone writes a book, or someone goes on a big TV or political campain.
What probably will cause the masses to wake up is when, bit by bit, they are exposed to software that doesn't crash. Why use Windows to surf the web and read email when I was able to use Linux to do the same thing, and I didn't have to reboot, and the GUI e-mail client, though it crashed, didn't take down the system, thus I could continue quicker? And slowly, as people see that there is another way, they will begin to accept products that work and are stable, and then they will begin to demand them.
An companies will produce products that fit the bill, because if they don't, the buck stops somewhere else.
Linux - Because Mommy taught me to Share.
Quality software isn't rewarded in the market. That's the problem.
First, a quick postlude by the choir...
*** Amen, Amen, Amen! ***
Okay, to the grit. Halfway through "Brigitte Nolan" get into "why browsers suck." I'd just thought I'd fire up oleview and see how many interfaces the intergrated IE 5/explorer exports these days...
*counting*
Oops, I lost track after 500. The plain old "HTML Document type" has over 130 alone. IE has more hooks than than velcro, and if just one of them is misused or misfunctions, asta la windows, baby.
Netscape has about 20, and still can't get it right.
And that does not even count having the program work right in the first place.
Complex? hell yes. Stupid? oh yeah.
For this to happen, stores need to start ACCEPTING returns! Most stores around here say that music and software cannot be returned except for exchanges for the same title. This is to combat piracy... It also keeps you from returning bad software! They just won't take it back!
First, for not having the guts to say "no". But it does seem rather pointless giving up one's job, knowing that there's always some fresh-faced kid straight out of college who'll agree to do whatever the boss says.
Something that we can control, though, is that we programmers (in general) hate doing quality-oriented stuff. Analysis, design, documentation, coding with clear (long) routine names and variable names, putting in all of the right error checks, etc. The important thing to us is minimal keystrokes and maximal cool. Perl poetry and C++ hackery are exalted, while quality-oriented languages like Eiffel are snubbed because they're not kewl to code in.
Perhaps we should clean our own houses first?
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
I've thought about this quite a bit, and I almost want it to be an "Ask Slashdot" question, but here is as good a forum as anywhere else.
Could the rapid proliferation of shitty software be related to Moore's Law?
Are software developers developing new software/features without optimizing current code just so they can state that it works on the latest processor?
I think some are. Take Windows. It gets bigger and bigger with no real significant improvements. 3.1 on my 486-66 (back in the day) seems to have run as quick as 95 did on a Pentium 100, which seems to have run as quick as 98 did on a Pentium 200. But try running 98 on that 486-66, and the desire to pump bullets into the machine is damn near irresistable.
Next, Take Linux. It gets bigger and bigger with significant improvements. It runs on my 486-66, my Pentiums, and My First SMP Machine [TM]. And the differences in X are appreciable, but I can run X on the 486-66 and not want to shoot the machine.
I compare my experiences, and I can't help but wonder if Moore's law has contributed to crappy software. Linux is used by many, and optimized by many - to run on my SMP machine and my 486-66. 98 isn't, and, as a result, its flaws are many and become glaringly obvious as the hardware you use becomes older and older.
Linux - Because Mommy taught me to Share.
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
Quote from CatB about Brooks law (in The Mythical Man Month):"adding developers to a late
software project makes it later."
Another quote "But if Brooks's Law were the whole picture, Linux would be impossible."
That is why I love the bazaar model and the Free Software philosophy. You can check that tyou are using good software and fix it/improve it if this is not the case.
Why add a feature that would add more bug. If this feature is usefull this will be in the next release, if it is not usefull enough nobody will care.
"The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." Bill Gates,
It is simple really. Features vs Fixes. With every release of software companies feel compelled to release new features in there software.
Look at Microsoft. (No I am not bashing them). There window 95 OS for instance, had a new look compared to teh windows 3.1 look. It was 32 bit as opposed to 16, and there were man new features in it. People loved all the new features, yet there were many new bugs. Plug and play for example. This was a new feature. In theory it was good, but in practice it became plug and prey. Prey the OS recognized your devices. Pray that there were not conflicts between devices either.
There are problems even in the Linux system too. They add new features to a stable kernel and then bugs creap in. They do get fixed, but more features are added in at the same time.
Most people see a peice of software and they suddenly seem to have visions of what this could be. They take the package and then add to it. They add more and more, until they have hacked the system to a state where it is no longer a good implementation it is just a querky working peice of software. In some cases they rewrite parts of the code (this happens in the Linux kernel). Thsi is good. It keeps the features and allows for better implementation of the system. However in other cases the code has been thru so many hands that it is almost impossible to rewrite in the time that corporations allot.
This is the difference. In the corporate world you have clients, deadlinesm and deliverables. This is pressure to release a peice of software, even if it has bugs. The bug fixes are hacks, to make things work.
Personally I am not into software that has that many features, after all how many features in Word does the average user use? I use either a simple text editor or HTML editor. Other than that I only use word when others need to send me word docs. Or when I have to do a design doc for work. Even then I could get away with an HTML editor if they'd let me.
Only 'flamers' flame!
This is a classic example of why I have a hard threshold of 1. It does have relavence, it was a quote from the fscking article, you twit. And secondly, if you were smart, you'd realize that it didn't get moderated up. Once you have so much karma, your posts start off with more points (you can choose not to invoke these karmic powers, but I'm often lazy). I thought some AC might have answered my question. Instead, I'm once again reminded at why these people are too stupid to think up a user name and a password, then log in. ;)
~ Kish
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
Some things to think about: 1. The poster and /. reveal a bias by their constant use of "commercial" in their editorializing. This problem is hardly limited to commercial softare; in fact, to be objective, it's absurd to suggest that open-source software is even as reliable as commercial software in general. In the last few years of using Linux, I'd say that less than half of the programs I've tried compiled or installed correctly, let alone ran reliably. This experience is synchronized with the general perception that open-source software is a bunch of hacked-together ports, all relying upon incompatible libraries, and that one is lucky to get *anything* working. Let's take off our open-source blinders and be objective. We are nowhere near being the kings of reliability. 2. This piece is pitting "honest" and "conscientious" programmers against "bottom line-driven" and "greedy" management. I would say, as a software engineer who reads the industry publications, that this is an inaccurate stereotype of management, and so much anti-management propaganda. Most of management is non technical and caught up in the industry mantras of "software quality" and "quality management". The author comes off sounded more like a disgruntled anti-management programmer than an objective reporter. In my experience, management has been very concerned about quality and the firm's reputation for quality. Deadlines are often brutal to all parties concerned, but are seldom (at least from my reading) quite as one-sided as the author presents them. 3. "Software is an industry none dare question." This is so absurd that I hesitate to critique it. Most users and developers regard the software industry with a degree of disdain unseen in other industries. Remember, both users and software developers have to use software products to meet their deadlines, and the central thesis of the author's article is that software is riddled with bugs. Computers, software, and the like all receive raised eyebrows from nontechnical folks, and technical folks are sick of system crashes (as a Win32 developer, I must reboot my Win 95 system an average of 3-4 times each day due to lockups). The author's claim is patently ridiculous. The only thing he says that's even more absurd is that software hasn't increased our productivity (because it crashes periodically, and then there's down time). The net increase in productivity is obviously very high. One wonders: did the author type his article on a typewriter and mail it into a publisher? No. He used a word-processor because he wants to be able to block delete, cut and paste, and use custom layouts--things that greatly increase his productivity. Regardless of what he says, he obviously believes something quite different. Also, the communications aspect he mentioned on the previous page obviates his claim about productivity. Software-based communications has revolutionized the way business takes place because it allows us to do much, much more in much, much less time. It's not perfect, but it's amazingly better than doing everything in Mayberry, where you'd need a human operator (can't use any software, like the modern telephone industry) to connect your calls, or just drive over there (in a car that doesn't use a software program to read its digital chipset).... 4. "Software is badly made. More than that, it is often horribly made. It is developed with the sort of irresponsible abandon that would be unconscionable if it were applied to bridge-building, car-making and possibly even plumbing." Actually software is used in hospital life-support systems, NASA and aerospace industry guidance systems. Amazing that problems are so rare that they make headline news when one occurs (e.g., the Mars lander). Besides the Y2K problem, users of large-scale proprietary softare-based systems have been very silent about how their software was developed with almost criminal abandon. It's just not the case. Desktop applications tend to be mostly usable, but crash occasionally because their publishers were driven to focus on features, and some of the features were not adequately tested, even by well-meaning software quality management protocols. They're not awful. They need improvement. 'nuff said. I don't have the time to respond to every point. My only hope is that this community, which got to be where it is by being a bunch of independent thinkers, hasn't been here so long that it has lost its ability to think critically, and that we have become lazy in accepting pro-open source propaganda as easily as the rest of the world accepts M$'s propaganda.
When companies like Adobe and Microsoft have software behemoths that so completely dominate their sectors that they exclude most other competition, the last (and perhaps greatest) source of competition the company has is itself; in order to remain profitable from year to year, new products must be sold to replace the ones currently installed. The problem is, most of the installed software is good enough for the current task (which is why it was bought and installed in the first place).
Enter the bugs. The foremost reason for why people replace their current versions with new ones is that the new ones promise to fix the bugs of the old ones. This means that if the company fixes all the bugs in its product before releasing it, it will have nothing to fix for the next version and it'll be forced to make some real (and costly) innovations. Of course, the new version will introduce its own new bugs, but that fact won't be apparent until after the product has been paid for.
Asking for there not to be bugs is like asking MS not to make the next version of MSWord use a new and incompatible file format so as to force users to upgrade and spend more money.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
Y'know, that thing in Corel's WP7 and later, it let's you ask plain-english questions and get bacvk answers without A) Insulting your intelligence, B) sucking down your CPU time or C) sucking down your RAM
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.
The projects may end up better if they have more time but the company could also lose revenue and not be able to pay their employees. Let's say you put quality first but your competitors don't and they out market you with glitzy hype and frequent buggy releases, well do you give in and follow their lead or do you stress quality? Will the customers care? If we use Windows as an example then no the customers don't give a damn about quality and will put up with a lot of bugs just to have what they have been told to perceive as the latest and greatest. At this time the public thinks "bigger faster better more" and not "stable" so the software companies have given them what they wanted. It is the fault of consumers for putting up with it in the first place.
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.
I don't think it's capitalism as much to blame simply ill informed people making bad decisions. As a very senior QA Engineer here in the valley, I have seen it everywhere. Most business are run by people who's only knowledge of current technology is the latest buzz words. They are obsessed with playing with MS Project instead of ensure that something does what it says it's supposed to do. I guess if you are to blame anything it's fear of "not shipping at the end of the quarter" and then not being able to explain to some board of directorys why they fucked up. So instead of making something that can make everyone proud at a company, it's ALWAYS about covering shit up that is only mildly difficult. But that's human nature everywhere. I also know of some really crappy is comming from Australia, Canada, and England. So I don't think America has cornered the market on greedy businessmen or stupid programmers.
Oh yes, and since you love the NSA so much, I understand they have recently procured some encryption software created in AUSTRALIA, that isn't y2k compliant.
I work in the software industry and I've found bugnet.com to be a very useful site when discussing things such as software quality and bugs.
This article is related to this topic, it talks about some people's experiences with the software industry's attitude towards fixing bugs.
I don't claim to be an expert in political science, or much of anything else, but I've read more on it than probably 95% of the population has, and I'm minoring in it at school. The basic, fundamental TRUTH to politics is that it's a means to an end; no matter the system, the FINAL END is always a happy functional society, where everyone has everything they could ever need. No poor, no war: that about sums it up.
Socialism and Capitalism just take different (drastically different) approaches to achieving the SAME end. Socialism says, "start everyone off under government-enforced equallity, and eventually the need for government will disappear." This (falsely) assumes that everyone will be motivated to be a good citizen, and contribute to the good of the nation, rather than just themselves. Capitalism is 180 degrees different; it assumes people are inherintly selfish, and will better their OWN situation. As this happens, it boosts the economy, and betters the situation of others. Eventually, everyone's happy. This is also bullshit; however, because it's based on a true assumption (we're selfish bastards at heart), it's closer to fully functional, and it's the system that works best in practice.
You can spew as much socialist crap as you want; but until you change the basic nature of man to be such that we seek to better the lives of OTHERS before our own, it's JUST NOT GOING TO WORK IN PRACTICE. Come on, free software developers are as selfish as Mother Teresa was. They want a working system, and want to do something they enjoy. She wanted to better her chances of getting in to Heaven, and wanted to feel good about herself. Every motivation for everything we DO is selfish, if you look deep enough. And until this changes, man just ain't gonna be able to function in a pure socialist society.
--
--
Just lurking, thanks!
This article tries to make it seem as if bad software is innevitable as it gets more complex. While most software is unstable crap that has lots of bad code (even Linux is full of bad code as much as I hate to admit it), software exists that has good, tight, stable code. Just think OpenBSD. Because the codebase is so tightly controled you have extremely good stable software that's really well coded. This is just making excuses. I don't upgrade a lot, because often things get worse rather than better. The problem is that most software gets to a stage where it does what I want and has plenty of features, but from there instead of just making the code tight and stable, most companies/developers start just haphazardly adding code and making the product worse. How about instead of this just trying to make the existing stuff better? I know it's not glamorous, but we need to do it.
-Laktar, a.k.a. Nick Rosen, laktar.dyndns.org
If I Ever Became An Evil Overlord:
27. I will never build only one of anything important. All important systems
will have redundant control panels and power supplies. For the same reason I
will always carry at least two fully loaded weapons at all times.
-- Peter's Evil Overlord List, http://www.eviloverlord.com/lists/overlord.html
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.
..you are clueless, and have no idea of what I meant. Go waste time playing in the sand somewhere else. ;)
~ Kish
Well that's why you have a plug-in and scriptable design. Little (features) that plug-into a core program and an easy to use scripting language for those one-off tasks.
Anyway, if the contrary were true, North Korea would be Silicon Valley.
I think the first horrid software job that I can remember in a game was the original release of Unreal. Anyone remember? You would die from sitting on a moving lift. That was all there was to it. The Unreal Tournament edition site blatantly makes fun of their past. This was a hideous creation and they still didn't get it even close to right for 3 or 4 more patches. Disgusting. Just another prime example of absolute CRAP.
My car, for instance, for all the care I gave it, began to literally fall apart once the 50,000 mile warranty was up. Little bits here and there just started to fall apart. Nothing serious mind you, but I'm putting up with more and more aggravations every day. Sure, my car works, but it aggravates me that it was literally designed to fall apart. They have this "down to a science", I think. My old Volkswagen ghia, which I could almost have kept running indefinitely (well sometimes they just get too old), never had this problem ...
Most industries are quite in tune with the "planned obsolesence" ("process optimization", in industry parlance) concept, which is ruinous to the customer, but there isn't anything one can do about it. Microsoft (and most windows software) software is even more deplorable still, but it's essentially the same thing: keep the product cycle churning. Don't let the customer stop to think. In the auto industry, they make things seem better by creating a "fake company" (Saturn: and by "fake" I mean it is designed to present the customer the illusion of competition) which markets itself as "a different kind of company", when, in reality, it's the exact same bullshit that GM makes elsewhere. In the software industry we have the MacIntosh (Apple fans please calm down, it's not personal). It's funny how people just lap this shit up (but mostly, the "lapping up" is done in commercials which are of course not real).
All I can say is thanks, Richard Stallman and friends.
support gun control: take guns from cops
The words "buffer overflow" come to mind.. Try firing that huge bastard up in your favorite text editor! =P
~ Kish
I worked on Communicator 4.X back when Netscape wasn't AOL so I have some perspective on this...
There's a good reason that so many bugs get "latered" or marked "wont fix". Those bugs probably weren't that important!
My point is only that not all bugs are created equal and that saying a product may ship with 2,500 known bugs isn't quite as bad as it sounds.
e.g.
Bug #1 - "Alignment of radio buttons in news server pane of preferences dialog not up to spec"
Bug #2 - "Monitor detonates sending shrapnel into users face when you resize the main window"
Most software ships with several hundred bugs similar in kind to Bug #1. If you're lucky, you'll only get a dozen or two as severe as our second example.
As an aside, it would really suck to get assigned an "exploding monitor" bug... because then you have to reproduce it!
:-)
Of course, everyone *says* that they'd rather have slimmed down software that works. They just don't *buy* it.
How many people actually use 5% of the functionality in MS Word? Almost everyone uses it.
That's all I have to say.
I just finished reading this article and as I look at my wrist to check the time, I notice something:
My watch crashed.
Resetting the time and alarm, and inputting all the phone numbers, scheduling, speed dial numbers and such is quite a nuisance, and I must live with these crashes until I get a new watch. And this brings up an interesting point.
I remember a while back with all the Java and Jini hype and how we'll have interactive toasters and lawnmowers and such, and how everything will be networked and have its own IP and do this, that, and the other thing. Well, if we're going to have all of these nifty devices, we sure better hope there aren't any bugs in the software running them.
A toaster which has a glitch which can result into it bursting into flames will not go over well with the general public, as with an automated lawnmower that can't tell your dog apart from crab grass.
Most consumers have seemed to tolerate the crashes that plague them daily. Yet if, say, a trailer hitch on a stationwagon is too low and continually grinds into parking curbs, there's free repair from your local dealer available in a few days. I don't see most software companies waving a free patch around after a week or so.
If we're going to have this happy wired world with everything from servers to wristwatches having their own IP, I think some better standards need to be established or adopted by major software firms before some terrible disaster occurs in the not so distant future.
Drudd's post is right on. Comctl32.dll is a great example. Windows 2000 includes a new version of the common controls, called Comctl20.dll. For backwards compatibility, it also includes a Comctl32.dll. Unfortunately, the Comctl32.dll in Windows 2000 is a different Comctl32.dll than other versions of Windows! Windows 2000's Comctl32.dll is a simply a wrapper DLL that thunks API calls up to the new Comctl20.dll.
.so and the new .so with different filename reflecting the library version numbers. Remember the problems of some Linux distros mixing up libc5 and libc6? Microsoft does this all the time..
As a third-party developer, if you link your program with Comctl32.dll on NT4 or Windows 9x, you must code around known Comctl32.dll bugs. When users upgrade to Windows 2000, your program dynamically links with the "improved" Comctl32.dll (which calls buggy new code in Comctl20.dll). Your tested program suddenly inherits new bugs from Comctl20.dll. Plus, your work-arounds for known bugs in Comctl32.dll might have bad side effects when the bugs disappeared in the Comctl20.dll.
This is a terrible design decision and typical of Microsoft's "engineering". On Linux, a library developer would probably ship the well-known old
cpeterso
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.
Oops, one more comment:
Writing programs that rely on Windows DLLs is like a building a house of cards. Here's a great DDJ article about how to solve your DLL woes - past, present, and future!
"Windows DLLs: Threat or Menace?"
Here's an excert:
The answer to the almost limitless problems of DLLs is obvious: Don't use them. Wherever possible, use static linking. Imagine the benefits. Some other developer's boneheaded installation or poorly designed updated DLL will not break your application. Your application won't fail because a component is missing, or because a registry setting has been lost or modified incorrectly. Your application won't behave differently depending on the applications already loaded, as a DLL-based application can if another application has already loaded a different copy of one of its components. Your installation will be exceptionally simple, and an uninstall will be just as easy.
I should warn you of one small hassle if you try DLL-free development. Your users won't believe that there is only one file to install.
cpeterso
I read an intreview with Gates himself in a magazine a little while ago.
The interviewer started to ask why there were so many bugs in the new version of Office.
Quoth Mr. Gates: No! There are no significant bugs in our released software that any significant number of users want fixed.
You can read the rest here
Makes me sick.
But, when did any figurehead EVER not lie in the face of the truth?
PPoE
It doesn't mean much now, it's built for the future.
While bugs certainly suck and no doubt cost billions in productivity, I think that one thing left out of the sucky software picture is lack of user-friendliness. In the world of Windows and Linux, if a program is hard to use or has a cumbersome interface, nobody gives a second thought about. Keyboard shortcuts for basic functions (like quitting an app) are often poorly chosen and differ from one application to the next. Different applications often deviate from a standard interface, making each new program a confusing challenge. And yet people continue to tolerate this. Microsoft continues to use big words like "user-friendly", but no one questions why a fully 32-bit non-backwards-compatible OS like windows NT still sticks with unintelligible DOS naming conventions for program files. While certainly the mac has had it's fault in certain areas, the applications for it always for a standard
What I find sad is that most of the CS majors(programmers) I have met through college ( a CS top 10 university) have so little experience with practical programming. They know next to nothing about software design, coding techniques, documentation, development cycles, etc. At least at my university there is little focus on programming style or project management.
.plan files and such but I've noticed some really nice touches like publishing internal "bug fix of the day" or inviting people to the company office to test and give feedback.
I've found that books like Code Complete, Writing Solid Code, Effective C++ absolutely invaluable in shaping my view of programming. The problem, as I see it, is that bad habits form early and programmers, being the stubborn bastards that we are, are loath to change habits on account of someone else's advice. Mostly we seem to have to actually get bit by the problem before we wake up and take action.
Good programming practice is boring and requires intense discipline. BUT IT'S WORTH IT. I'm a believer. I've done it the hard way and the boring way and the boring way was magnitudes easier and quicker once the boring(spec'ing, documentation, design) work was completed.
There are exceptions but that's exactly the point, isn't it? It is the exception when someone (or some group) can hack code together that's on-time and robust without going through the boring stuff.
Users are the problem? Yeah, when they're brainwashed into it. I'll concede that the majority are probably tickled pink with new features and fancy graphics and slick animation... which wears off after the 5th crash in an hour. You pay for a lot of this software, complain complain complain.
I have some suggestions which have differing degrees of merit/practicality. And I'm sure they've been brought up before in other books and papers and articles.
- Write programs with the intention of porting. This forces many potential bugs that are hidden in one platform/compiler to rear their ugly heads.
- Have a more 'open' development process. For gaming companies this means that once you've achieved a certain level of completeness put some of the internal progress online for your sonsumers to view and track. This is already popular with
Obviously the OSS method invites peer review/monitoring. Big plus there.
- Complain to your university about it's curriculum/focus. Maybe you won't get any benefit from it immediately.. but where do you think your future co-workers will come from? You'll probably get some BS about "we're not here to train programmers we're here to educate computer scientists." (I can't begin to say what's wrong with that). Since CS majors, from what I've seen at job fairs and the like, are the single greatest pool of new programmers, it seems to make sense that you'd train them as PROGRAMMERS as well as computer scientists. Suggest a alternate curriculum to focus in more specific programming topics like specific languages, design, documentation, cross-platform dev, networking etc.
btw: Is there a program 'quality' standard or award? I'm not aware of any that applies to general computer software. Nor of any general download/ewview site that rates programs on someothing other than features. I am reminded of the console gaming market where crashes in titles seem a rarity. I think I rememebr one Nintendo (8-bit) game that crashed. (Granted that, compared to the PC market, they have very homogenous hardware constraints.)
Apple used to be very anal about who got the 'seal of approval' as well.
Anyways, I'm rambling. I hope I've made some sense.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
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
To learn about effective software design practice check out extreme programming.
This can also be seen in the free software world. The failed projects started out with grand plans and a lot of talk. The successful ones started out with a little bit of useful, working code then built on it; rewriting and refactoring along the way. The Linux kernel, for instance, has been rewritten many times (supposedly).
Capitalism works for more reasons than pure greed. One of the more important reasons is because things are de-centralized. That is a subtle, but significant detail. Communism/Socialism assume that resources can be efficiently allocated with central planning. Central planning simply doesn't work. This has been shown a thousand times over, in a thousand different ways.
In other words, even if your socialist country was populated by cloned Mother Teresas; it still won't work.
I don't see the current problems in software as market failure at all. The problem is that users haven't been demanding quality software, instead they've been purchasing software on pointless features, eyecandy, techiness, "compatibility", etc etc etc. Perhaps this is failure in a sense, in that people don't always know (or do) what is best for them. However, I'd far rather have a system which experiences a little bit of turbelence than an unwieldy impersonal bureaucracy (even if they don't ultimately crash).
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
I honestly can't believe so many people here feel that just because a piece of software is commercial it has to be fucked up! Sure there are shitloads of unfinished games and other buggy commercial products, but for each of these there is some half-assed open source copy that is just as bad. Just because millions of people can see your code and fix does not mean they will. I'm sure anyone here can think of good and poor software, both commercial and open.
I'd say it all comes down to optimizing costs. Currently, for whatever reason, buggy products still make money.
There's some sort of cost relationship between product stability, feature lists, and usability. Businesses, as in any industry, manage those costs to generate the most revenue in the shortest time and for the smallest investment.
Labeling buggy products as Bad is as meaningless as labeling super-featured products as Good. It's an entirely subjective experience that ultimately is resolved at the cash-register. That which makes the most money at the least risk will always win.
Customers don't realize that short term wins (acquring products quickly and cheaply) have long term consequences (platform stability, overall software quality). Currently customers don't have the skills or experience to work factors into their own cost minimization equations, so they're effectively "weighted" at zero.
As the industry matures people will surely start to pay attention to these things, and businesses will have to account for this to remain profitable.
The big problem is that due to the institutional ignorance of the human population, The Masses are easily manipulated for the profit of The Individual. The current lack of understanding of the customer base has proven to be very profitable, so large corporations find it safer to continue to rely upon (and even take pains to ensure the existance of) this ignorance than to take a risk upon developing good software to satisfy a small (and statistically shrinking?) group of enlightened users.
As long as The System allows The Corporations to manipulate The Masses for their own profit, this will continue to be the case. The goal is for The Masses, and through them, The Government, to recognize that corporations are only *allowed* to exist because they are a tool believed to assist in increasing the standards of living for The Masses. Once this understanding is gained, then The Masses, via The Government can reshape the public tool called the corporation for their own benefit.
While bugs certainly suck and no doubt cost billions in productivity, I think that one thing left out of the sucky software picture is lack of user-friendliness. In the world of Windows and Linux, if a program is hard to use or has a cumbersome interface, nobody gives a second thought about. Keyboard shortcuts for basic functions (like quitting an app) are often poorly chosen and differ from one application to the next. Different applications often deviate from a standard interface, making each new program a confusing challenge to learn. And yet people continue to tolerate this. Microsoft continues to use big words like "user-friendly", but no one questions why a fully 32-bit non-backwards-compatible OS like windows NT still sticks with unintelligible DOS naming conventions for system files. And these problems are *NOT* due to management pressure and short deadlines. They are totally the fault of the programmers. While certainly the mac/apple has had it's faults, mac applications have always had interfaces consistent with that of the operating system. Keyboard shortcuts for mac appliations have *always* been consistent and well thought out. I think the windows/linux users have something to learn from the mac users, who will not hesitate to harshly criticize a program whose UI is crap.
I work for a large publishing house, and all of our subeditors sub articles on-screen, it gets laid out, and then they proof the print. The changes are made, the story is printed, and then they proof it again. If more changes are made, they print it out again, ... continuing until there are no more mistakes found.
Do you program? Take a large program that you're working on sometime and print it out. Have a good long read of it. Whenever I do that, I will inevitably find a section of code where I think to myself, 'what the hell was I thinking? And why didn't I catch that earlier?'
I don't understand it, but it's true.
In java for instance, there was never a table/spreadsheet widget. I wanted to design my own, but got agravated since I'm doing a table widget project than my original one. After searching around, a single person run company, who gives out the java class for free, had a very nice one. Since I could just download the class (lib), I could compile it in. He worked on it in his own free time and maintains it. The class was free for non comercial projects.
Apache,FreeBSD,snarf, BSD/OS, Perl, Lynx. All once started from independent, free form designed projects (Yes..BSD/OS was once BSD 4.something). They made their own schedules.
Can't release it today? Maybe tomorrow. Once it's done I'll announce it. If I'm a day late of my own personal schedule, no biggie.
-
ping -f 255.255.255.255 # if only
The deadline is being pushed back because it IS vapourware - Yes, it IS coming, but Microsoft knew they had no hope of getting it out by its supposed delivery date.
Open Source. Closed Minds. We are Slashdot.
Open Source software is CRAP.
I hate to tell you this kiddies but....
gcc is poor and produces bloated code compared to it's commercial counterparts.
I know you zealots won't belive this but ask yourself:
If Open Source was the best, why would any commercial software exist? Who would PAY for inferior software when a superior system is FREE?
Don't believe the hype.
Two examples:
Part of the Multics operating system was written, using 60s technology, that is, mostly a pencil, paper, and competent mind. It was, essentially, the VM/buffer cache manager. It had one, count it, one bug, and that was due to the programmer being misinformed about the API he was calling. Read the story, told properly, at this link.
The BBC Micro was an 8-bit microcomputer produced by Acorn. It had, like most others at the time, BASIC supplied in ROM. It was a very good BASIC, much better than many others at the time (and a lot better than that written by Mr Gates and Mr Allen). The author, Roger Wilson, wrote it in about 3 months (all in assembler, of course), as scheduled. He was then expected to proceed to testing and debugging, but stated this was not necessary as he had written it to be correct. It was, pretty much. It had about 2 minor bugs.
So, it can be done. You can even do it under commercial pressure.
Nicolai
Moderators who disagree with things, so mark them as flamebait.
This bites.
Open Source. Closed Minds. We are Slashdot.
To the moderator who labelled Max's post 'Flamebait':
You are a moron and a shining example of the petty shite-headedness of the average web user. If there were justice in the world you would be consumed by cockroaches, but I suppose we'll have to wait for meta-moderation.
Actually, what I'm hoping is that I'll make you so mad you'll waste another point on me as well, and that's one fewer down-mod that someone else will have to suck on.
The moral: Disagreement with a poster is no reason to get spiteful with your moderator points.
Shame on you.
Hokey statistics and ancient misconceptions are no match for a good thought in your head, kid!
I run a small retail business with point-of-sale records kept in xbase format. For doing things my purchased program won't let me, I own FoxPro 2.6, but 99% of the time I use my trusty single-floppy copy of FoxBase+ 2.10. (And I'm dreading the day I'm forced to move to Windows.)
What should be explicitly said in Clive Thompson's article is that while
software is not like other products, except, perhaps, commercial art or
illustration, it must be managed like it was just another engineering
project. In that regard, the failure of software to deliver is plainly a
failure of management.
Cynicism aside, most of us have experienced the project manager or,
worse, the project management team, without a clue as to what the
programmers are doing. Not that the manager isn't coming from a
technical background but that they simply don't have personal experience
with the tools and technologies their programmers are using and without
it they are unable to distinguish between honest underestimations and
outright bullshit for project milestones. They got their specs from
the business people, probably didn't understand them, tossed them to
the senior developers who (if they bothered to work with the DBAs and
Sysadmins) passed back a project model or at least a logical diagram of
the data and of the system. This draft suddenly gets set in stone and
approved, often after the team has begun work. Maybe the project model
wasn't even done by the developers. It might be done by the project
manager themself or a dedicated functionary who just scribes these
things all day.
This is compounded by programmers- and I've been here myself- dazzled
with their own innate superiority who blithely assume that they can "get
up to speed" with a new tool, technology, platform, co-worker, team,
boss, project, whatever in less time than it takes to cook an egg.
These programmers probably want to cloister themselves until the job is
done. Version management? Source control? Approved methodology? Review?
Hey, did anyone check if it works? Nothing is more frightening than
leaving the average developer alone in a cube for six weeks. It takes
discipline to do these things and most people, myself included, don't
take to it unless were forced to do so.
The third ingredient in this recipie is the tools themselves. If there
is a method for choosing development tools, what criteria are used? As
often as not, the tools are bought and paid for before the development
team is assembled. Are these the best tools for the job? Maybe. Or maybe
the box was just the nicest color, or the sales rep. made the best pitch
or took the manager to the nicest restaurant, or- and this is usually
the case- a competitor or colleague used the tool successfully for a
project that bears little resemblance to the one at hand.
What should be dawning on you if you've read this screed is that no
blame goes on the customer. All they did was ask for something, it was
the entire development process that was supposed to field that request,
sift through it, prioritize the goals and result in a software product.
If it didn't, it sure sounds like a management problem to me. I've got
it, let's shuffle the cubes around.
you get what you accept
There are horses for courses.
Did Linus divvy up his time like this writing linux. I bet he just started coding.
I hope different approaches are allowed for rocket ships and pacemakers then for computer games.
... 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?
OK, it won't crash you but unless you have been good about ulimits the following shell script will lock any Linux box hard. (Heck, pretty much any Unix as well.)
/bin/bash
Before running make sure that you have shut down everything that you care about. When you get tired of an unresponsive box, turn it off by hand.
Save the following as a shell script and execute it...
#!
# Tie up some memory
perl -e 'push @big, 1 while 1' &
# Spawn another me and wait on it
$0
# Oops, that one died, try again...
$0 &
# Stick around and keep trying to lock up the last process slot..
while ( sleep 1 )
do
$0 &
done
When you are out of RAM and out of process slots, you are SOL...
Cheers,
Ben
PS Note that I am careful to have the processes "chain out". That is to avoid having a lot of processes trying to be created at the same time. (Confuses the scheduler and slows down the creation of new processes.)
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
And if you see some obvious improvements to be made in some package you work with, then send in a patch.
--
An esoteric scratched itch:
Homeworld Map Maker Tool
I firmly believe if software houses would get their heads out of their asses and not let contractors/rogue individuals design/implement in any way they wish for job security, that we would be in a lot better position. I have been absolutely stunned by the apparent lack of thinking when certain individuals go out to develop a new feature/program. They just see the deadline next week and don't even consider that someone may need to look at/fix/upgrade their piece of crap code. And its not even that - there are individuals so firmly entrenched in the hack-and-slash mode of coding, that they will fight all attempts to actually do software engineering, not high-school hacking. I am not even going to get into the lack of communication between software teams.
I think it would be correct to say that Brooks essay No Silver Bullet stated that there would be no algoithm or coding method that improved software across the board in the next ten years. This ten year period was over two and a half years ago.
Most programmers are in unison in agreeing that the Silver Bullet didn't emerge.
While you may argue that the Internet is a silver bullet, in-house development is far more efficient a method as far as communication goes than the Internet. The Unreal team had members from across the globe for the first half of their game design. In the end, they all met in Canada to finish it off, as development was going too slow.
The closer to realtime communication is, the less time spent concentrating on synchronizing everyone's thoughts on matters pertaining to the project.
The reason the development of a free Unix works very well over the internet, is that it is broken up into very small parts. If one person is to develop 'grep', they would not need to be continuously in synch with someone who is writing an archiving tool.
Software is not the only industry that struggled with bugs in it's early years. The aerospace industry was plagued with them until techniques and processes matured to the point where "bugs" are less likely.
Same with bridges and architecture. The funniest thing is, most bridges and arcitecture designed today are safer because of computers and software.
Games? Who cares if some loser's machine spontaneously reboots at 3AM in some frag war. It's not the end of the world.
The recent satelite mishap? Metric vs. English? Well, NASA went all metric years ago. Why did their contractor write their commands in "english" units? Who the hells cares? How did the design pass inspection and get on a satellite? That's the real question. If their contractors handed them a bag of shit, would they dutifully seal it into the sattelite without looking in the bag?
The SEI? Their great contribution to the article was the incredible statement that tyops occur every 4.7 lines. Needless to say, those lines won't compile, will they? It would be so rare for a tyop to be a bug, that your time is best spent elsewhere.
Some stupid article like this comes out every several months, and as always, they are wrong. If you really think you should be able to buy COTS software for $80 that is guaranteed to run your powerplant, satelite, car or airliner without mishap, you need to lay off the glass pipe or get some psychological counseling. The hardware costs money, the software costs money.
Finally, I've been writing software for 12 years, and all I can say is there are no true standards for programmers/software engineers. I should be able to walk up to any group of programmers and discuss back box/OO techniques, regardless of the language used, and have their complete attention and understanding. The industry is nowhere near this level of expertise.
Personally, I've been criticized on two occasions for belittling other programmers (1)called programmer a "Worthless Chimp"; (2) called programmer an "Incompetent Shithead". Well, sorry, but when the project is late, and a couple programmers are doing nothing but collecting their paycheck and playing games under win98, and have zero interest in learning XML/UML/OO/C++/Java (even just the *techniques*) I get pissed.
Oh well, I'm sure things will only get worse now that the goverment will be teaching schollchildren not to be "hackers". Sigh.
I've seen Eifel and it's a nice programing language. Well I've never written code for it because it's proprietery and it isn't cheap. But what I REALLY wanted to say is:
Eifel and any other programing language won't change the problem we got with software quality A BIT! "A fool with a tool is still a fool" (don't remenber who said this one) and someone who doens't care to make good code under C won't care to make good code under Eifel.
So please, before you mention another Silver Bullet. Say what it is really worth and under what conditions. Greets MadMike
...are you talking about "first post" or "first sex"?
If you really attend a top 10 university, please do your bright classmates a favor and transfer out, you don't belong there. Closed minded or otherwise misguided students like you ruin it for the good students who can see the bigger picture. (I remember students in my data structures class whining because we used Modula-3, a "non-practical" language)
Your university years would be better off learning how to learn and opening up your mind rather than practicing such a simple vocation like programming.
I agree with you that paper is easier to read and annotate. However, it's harder to shape, reconfigure, and retransmit. I often print out my programs and read from printouts. I believe in the toilet development cycle. On the other hand, you can't test a paper printout of your code and tweak-n-run (or tweak-n-compile). Paper is good because of its permanence; it's bad because of its permanence.
Speaking of publishing houses, I'm writing a book for a publishing house that doesn't even lay out using computers. After the manuscript has been submitted, any changes are extraordinarily costly and time-consuming. That's just awful. But also somewhat beside the point.
I'm talking particularly about collaborative processes, e.g. largescale coding projects, or website development, or even political discussion. There, paper is a powerful broadcast medium, but crappy for feedback response. A lot of it comes down to the whole CVS issue, making sure that everyone is, if you'll pardon the expression, on the same page. That's just too damn hard with paper if you're talking about something that multiple people are contributing to.
If you're the only one working on a project, then paper is awesome. It's nice even to have paper copies of documents. But only copies. If I go to a meeting and meeting notes are handed out, that's pretty cool. But I'd want them also available in electronic form somewhere, preferably with some discussion mechanism attached.
As everything we do becomes more and more "living", the advantages of paper will become fewer. Would you print out the code of some collaborative project to look at, if by the time you came back from the toilet the code would be changed in some way? Everything's going organic, baby. Fortunately, we can expect that paper will become "living" too. (See Diamond Age, e.g.)
--
Make mine methylphenidate.
who's _really_ to blame?
I remember the good old days, before Microsoft all software was bug free, fast, efficient, easy to use and cheap. What's more, the company that sold you the software, used to send a team cheerful techies who installed the software for you free of charge, answered all your stupid questions patiently, and gave you a warm hug when they left.
There was such a thing as a helpdesk, but it was only ever used to thank the company for their great service, since there never were any problems.
Then came Microsoft, and it all went downhill. They invented the bug, and shrink wrapped it, bloated with features nobody needs, and lacking in features everybody needs, and sold it for millions of bucks and your immortal soul. Because nearly everyone is stupid, and MS mainly target stupid people who don't even write their own kernel, MS made a bundle, while philantropic organisations IBM, and later Sun, were forced to include bugs in their software too, or face losing market share, which would deminish their charity funds.
The most evil thing to date is, that MS demands an exploitative license fee for everyone who wants to include bugs in their software too.
All the talk about how "its the customer's fault" has a edge of truth to it.
There are companies out there that strive to release solid bug free code "when its done". They get trampled in the marketplace because they take too long and offer too few features.
Programmers are only human, and if you want to increase the reliability then decrease the functionality/features and increase the development time.
Better programmers loosen the coupling between the reliability and features/development time, but only within limits.
Oxryly
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
Things have got a lot worse in the last few years due to the willingness of employers to use H1 visa type programmers with minimal skills and experience, because they will work cheap, and never say no. Most of the time they are not willing to stick up for themselves--must be a cultural thing from a rigidly stratified caste based society---or their work.
Linus didn't have a schedule to keep, or clients to satisfy :^)
I'm sick of comparisons between software and various unrelated products, i.e. in the article (paraphrased), "If manufactors created razors like current software then ..." etc. So what ? Software is required to do *way* more then 99% of other products. A razor does just *one* thing, my computer does millions of really complicated things.
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.
She said:
"Why does Windows crash so much?"
I said:
"Why don't you use an operating system that doesn't crash? Besides, it's free!"
She said:
"It's just too hard to learn."
I said:
"I guess you just answered your own question."
Information is not Knowledge
Does anyone think its the tools that are used now to develop software with maybe are just not sutible for the fast pace of development. I know there are rapid development tools and the like (that are supposed to speed up development time - arn't they, but do they improve it??), but what if the bugs are in the development software.??
What I'm trying to get at is the way software is developed wrong or just not sutible any more ??. Do we need a new way?
The Ariane 5 rocket was one of the most advanced, computer-controlled rockets of it's time. The level of software control was amazing. In it's first flight, it blew up. The programmers had apparently put an incorrect sign in a calculation and the guidance system went into a catastrophic positive feedback loop.
London's 999 service (the UK's version of 911) was partially computerised in the 1980's, with ambulance requests being relayed and dispatched by computers. The monitors were set to display each request. If an unanswered request was pushed off-screen, a warning message would be added to the display. Unfortunately, this is an unstable feedback loop. On one busy night, the entire system freaked, loosing a large number of calls and sending the displays into an inescapable infinite loop of error messages. An unknown number of people died, that night, from these bugs. Beyond a brief mention by the national press and the return to a manual system, no attempt was made to hold the software firm accountable for injuries or deaths resulting from badly-tested software.
Software I've had a hand in debugging, for a company that will remain nameless, has had astonishing, trivial bugs. Some were through using positively ancient 3rd-party libraries (ever hear of upgrades?). Others were caused by the AWFUL output of automatic code-generators that rival The Last One in their uselessness. Absolute filepaths littered the code (gggghhhh!!!). An apparent ignorance of what a compiler warning means further led to shoddy code. I re-wrote the application, almost from scratch. The compiled binary, for a Sparc Solaris 2.5 box started off at 11 megabytes. After upgrading 3rd party components, and doing the code PROPERLY, I reduced the size of the binary to 1.5 megabytes. With a bit more time, I could probably have fitted this evil monstrosity onto a single floppy. I want to know how the hell someone could write SO BADLY that the resulting code was almost an entire order of magnitude larger than it should have been. Never mind how most of that extra code was pure bug.
The PDP-8 had an interesting bug in it's firmware. Popularly known as the HCF ("Halt and Catch Fire") instruction, the computer could be put into a catastrophic state which resulted in the computer self-destructing.
A number of Commodore PET computer games, when released, simply failed to run. The software not only contained fatal bugs, it contained bugs that would have prevented any testing or use at all, crashing on initialisation. This software was never tested at all, before release.
JAVA was originally designed for embedded devices and machinary requiring fault-tolerent software. It's licence specifically prohibits such uses and the language implies that it has not been ensured to work in the very environments for which it was intended.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
How do most customers react to buggy software? They buy Brand X'es DooDad 2.0. It crashes several times a day, locks up the PC, and runs slow as hell. They spend a year downloading patches, that sometimes work, finding workarounds, and ignoring some of the bugs. Brand X ships DooDad 3.0. Do they tell them where they can stick it? NO, They send them 50 bucks for the upgrade! Buggy software will last as long as there is a market for it.
Quemadmodum gladius neminem occidit, occidentis telum est
You can choose where to shop you know.
I do take buggy software back and get a refund.
IE Crashed twice on my while reading this article. Isn't that nice?
I experienced such a moment today. While using a piece of commercial, closed source software today, I discovered a simple bug, one that could _easily_ have been fixed had I access to the source. Since I'm not using the most up-to-date version of the company's software, I'm forced to either upgrade, or do my best to work around the bug.
I'm not suggesting there's some kind of conspiracy among commercial software developers, but it is frustrating to see a mistake made that any programmer worth his keyboard would have easily spotted. Why do things like this happen? Because companies throw more and more programmers at a taksk, hoping to solve a problem with sheer numbers. When will they learn that quantity is no substitute for quality?
Argh.
sKroz
-- Minds are like parachutes... they work best when open.
Let's see...
* Pulling down the big bucks (6 fig's if I worked full time, which I don't) as an independent contractor.
* Working 80% from home to do development, 20% on-site to install stuff and hold hands with my users.
* Work at my own pace on whatever schedule I choose, with the only criteria being that I pump out working stuff for people in a reasonable amount of time.
* Control over what technologies I use on a project. Users are happy to let you choose what to use, especially when you tell them you're much more likely to achieve success with oss-product x than css-product y. More importantly, to ensure that my stuff works, I climb up on the backs of smart guys by reusing their open source code and objects (***Code Reusability*** should be getting a lot more mention on this thread!).
* The choice to accept or decline projects, so I don't get myself in a real jam.
WDK, do you really see me having a better life in the world you envision? If you take every point above and picture it in a Marxist/Leninist/uniform/sameness-type work, these things just evaporate! The freedom I have simply goes away. I become a clock-puncher like everybody else, or the converse: every software developer gets to live the good life like myself, which I don't see happening all at once.
You might say I'm privileged to have these conditions. I do feel fortunate, but not particularly special (every couple months or so I learn that a friend or acquaintance of mine has negotiated themselves a similar set of circumstances). Thankfully I live in a socio-economic system that makes all this possible. And of course, I have to perform in order to make this happen as well: I do my work methodically, pay attention to the details, listen and respond with lightning speed to my users, and constantly seek out the latest and greatest bounty of code/objects the web has to offer. (Needless to say, I am very grateful to the entire open-source movement.)
Well, you must have expected you'd get a response from well-fed capitalists (in the US, at least). Good luck on proving your ideological stance to others, but for now I just ain't buyin'.
Yours,
GSherman
I've seen a few good responces here about how a lot of this boils down to capitalism, or at a level lower than that, human greed. When microsoft releases a new product, they don't do it because they want to distribute an improved version to everyone, they need to make money, or they go out of business. This is no secret. Everyone knows it. Open source is a different philosophy. I'm not a linux expert, but generally it seems new linux code is released when it's truely ready, and is either something new, an improvement, etc. Not just more bells and whistles. Of course human greed it still a part of this, we can't really escape it. But I'm sure you'd agree that linux is a superior operating system. So even with human greed present, we can still improve on a lot of things. Those who say otherwise can frankly go to hell.
Capitalism pretty much dooms us to the microsoft scenario, forever. In a capitalist system, you either kill, or you are killed. Microsoft suceeded at this, by whatever means necessary. They did what they were "supposed" to do.
The software industry bears out problems with our system more than many others. I'll compare it to the auto industry. First, keep in mind that the auto industry has PLENTY of recalls on their cars. In fact, you see product recalls all the time, in every industry. Any given car probably has a few problems. But these few problems aren't necessarily going to crash the car and kill you. Plus many of the problems happen over time. With software, everything has to work just about perfectly or the system crashes. Many of the problems with cars build up over time, parts wearing out, etc. With a computer program, this time interval is going to be very short. If you have some sort of cascade error, etc, when your processor runs millions of instructions per second, its going to crash really quickly. So really I don't see the software industry as being much different as any other. They all have their problems.
As posted in other responces, short timelines and marketing play a big part of the problem. Again, I don't see much of a difference between this and any other industry. Marketing exists everywhere. The marketing department doesn't care about saftey, functionality, etc, they only want what will make them money. The only thing that holds them back is the threat of lawsuits and bad publicity.
Any economic system that puts money before anything else is bound to have these problems across the board. There is no escape while you're stuck in the box of capitalism.
Think I'm just some anti-social communist who hates society? If so, ask yourself why you had that reaction. You're taught from birth not to challenge the way things are, or be different. Those that do are labeled outcasts, troublemakers, etc. There were a lot of good posts on this coming out of the littleton colorado tradgedy here on slashdot, so I won't expand on that any further.
By our culture's standards, Bill Gates really is the ideal man. He's sucessful. He has a lot of money. He has more money than the total GDP of the 50 poorest countries in the world (give or a take a few, I can't remember the exact number I read). Does he deserve that? I don't think so, and I don't think you do either.
The level of technology we have achieved has given us the power to give everyone the necessities, food, water, shelter, etc. Yet we can't even achieve that. Black people are lazy and violent, 3rd world countries are run by corrupt governments, so if they go hungry, its their own damn fault, right?
An economic system is basically just a way to distribute scarce goods. We don't have to convert to communism, socialism, or any other -ism to improve the average person's life, materially and mentally. We just need to find a better distribution method, and a better model for what should be produced, and how to go about it. Easier said than done of course, I don't have any simple solutions, because there aren't any.
So instead of just asking yourself "why does bill gates suck so bad?" ask yourself "what forces in this world made him what he is, and allows him to continue with what he is doing now?"
We all have to be part of the solution, because the citizens of this country collectively control this country. We have simply given those "in power" the actual power. When we don't ask questions, they'll do what they want. If we ask questions and make demands, they'll do what we want.
This is the real road to solving "why software sucks" along with most other problems. It's not as easy as just getting more time to code or having power over the marketing department.
At one company I worked for (sometimes known as the "IBM of the UK"), vital parts of the product hadn't been coded at all but we "shipped it" on time. What we did was begin to write the tape and then forceably interrupt the tar. Then we shipped "on schedule".
This bought us an extra week so we could ship something that had at least compiled! Needless to say, the product sucked then and still sucks today!
This is the software crisis revisited. Brooks pointed it out over 20 years ago. Guess what? it still hasn't been solved. Only now, we have millions of more computers, running billions of lines of source code. It just makes the problem much more visible.
Subject says it all
Customers are just getting what they will settle for. That's the free market for you. The free market is not supposed to give what you need or want. It's supposed to give what you will most willingly settle for.
;). Make them suppliers think and sweat a bit..
You can get stability: remember there are mainframes which have been running even before some of you here have been born. Some of those apps may actually run for years or nearly decades.
A problem for most PHBs and purchasers is that you can count features but you can't count bugs and reliability as easily.
That said it is not impossible under many circumstances, but still people don't do it. I've seen lots of Tender specifications and requirements and so far have not noticed stuff like "Mean operating time before crash/unscheduled shutdown must be > 2 years, penalty for each crash = $XXXXXX ". Hmm, if I ever write a tender spec, I think I may put stuff like that in. Don't just specify downtime, specify lack of reboots, if not people like Microsoft will just work on making their stuff reboot even faster
Also no one has succeeded in throwing one of those "class action" suits at shrinkwrap software manufacturers. How come those idiots sue McDonalds when they spill hot coffee on themselves but don't sue Microsoft when Windows crashes and loses their info? Weird.
Open Source Software is NOT the cure. The reason why Open Source Software _so_far_ is relatively stable is because for now the software is more programmer driven than feature/time (more features in a shorter time) driven. Stability is just a (desirable) side effect of current Open Source Software practices.
If things change, and open source programmers start focusing more sticking in features by a certain date than on doing what they know how to do well, then OSS will be just as unreliable.
Cheerio,
Link.
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.
Software engineering is still too much of a black art.
Just take any software engineering course at your local University and you will see why. There are so many design methods, none of which solve the problem of producing "good" software. Nobody seems to know how to produce a good product. We know certain truths about design such as adding more programmers to a late project makes it more late, but most things are still a mystery.
There are many reasons for late/bad software, I have heard users are to blame, managers and programmers themselves; that there are bad design principles, the specs were done poorly, etc. Even though we seem to know what we are doing wrong, why do we keep on repeating the same mistakes.
A professor of mine blames it on poorly educated designers, i.e. people coming out of business colleges with a VB degree who think they know how to code the perfect system. I would have to agree with him here, I think managers and programmers both need more training in software engineering. Just because you can write a sweet algorithm does not make you able to design a complete system.
All in all I still think software engineering is a black art, we know the problems but they are not solved. Sometimes we manage to produce a good system but this is rare.
Anyone else care to comment.
MSDN is the biggest pile of useless crap I have
ever seen. We do a great deal of windows
development, and I can tell you from experience
that MSDN (the official Windows docs) are awful.
It is not reliable documentation (like one has
under linux w/gnu libs) but simply content
spewed out so that people think that microsoft
is doing it's job.
MSJ (the magazine) is marginally better, but
unofficial (ie. the info there is "as is"). At
least you get it from human beings, not the VB
program that generated the MSDN docs...)
If they don't keep changing something else will eat em for lunch.
;). But it doesn't matter since customer stability + reliability expectations have gone down to an all time low.
Do you really believe all those DLL and API problems are mainly because Microsoft "screws" things up?
Nah. It's because if Microsoft freezes DLLs and their APIs, they will end up like those BIOS manufacturers. And BIOS manufacturers don't make big money...
Think about it. If the API's are frozen for > 2 years, someone is going to come up with a Windows compatible. Why do you think Windows 2000's dlls aren't quite the same as Win 95? Because of idiocy?
Yes because users are idiots, and keep playing Microsoft's game even though they keep moving the goal posts. Give me the reasons why users upgrade to Win 2K and Office 2K- the most stupid and most common is "Because other people are doing it".
Of course sometimes Microsoft screws up too - that's when they move the goal posts and the rest of their team haven't realised it yet
Cheerio,
Link.
One thing's for sure, using Windows sure makes computing an interesting crap-shoot. It's like trying to predict when someone will jump in front of your car.
-SG
NerdPerfect.com... Give me geeks or give me death.
I send that URL to the management/sales/marketting team of our company. Let's hope this makes them realize a few things...
"If liberty means anything at all, it means the right to tell people what they do not want to hear"
Show me some major bugs in NT that stops software development
I won't do that (there probably are some, but I can't think of any real show-stoppers at the moment). I will point out, though, that Windows presents the developer with hundreds of relatively complicated and difficult-to-use APIs. Such a byzantine environment leads to bugs that would not have occurred in a simpler system.
Windows tries to be everything to everyone, and also keep backwards compatibility with all software and hardware, all the way back to 1985. Complexity increases past the capacity of even the most intelligent programmers, and surprise surprise, out come the bugs.
I don't care if it's 90,000 hectares. That lake was not my doing.
Opendoc
Isn't it incredibly sad that there's an actual human being who thought it worth his time to type that? I'm drunk and I still wouldn't waste time typing that. Poor idiot.
Inaproprate tools!
C - is a portable assembler and not many more IMHO.
It's good for OS kernel and stuff, but doing something as complex as, say, a simple window manager in C is not justified. No, I can't point you a good alternative, but it MUST BE without 'pointer' concept. I'm 100% sure about that. Runaway pointer is a cause of almost all fatal program errors.
C++ - is just a monster. Akin to PL/1 on old IBM's. Akin to M$.
Either that, or you could actually
*engineer* software, rather than patching
it together in a random fashion.
Yes, it's hard. But it's possible.
A start would be to not make product
teams out of recent college grads.
I have had this happen to me lots of times. Press alt esc instead of rebooting and it will go away. I don't know if it is a windows bug though.
Wherever you are, there you are.
Here's the explanation I got while working on contract at a major publisher of games and consumer applications:
If you're working on commercial shrink-wrapped titles destined for home users (games, print shops, garden design, etc.,) most of the money spent on that class of software is spent during the Christmas Buying Season. It doesn't matter what date you announce; if you miss Christmas (which means in-store by October, which means Gold Master released to manufacturing in September) then your company is screwed.
No matter how good your program, no matter how good your marketing, PC consumers just don't buy enough software over the rest of the year to make up for missing Christmas. Thus commercial titles get booted out the door in September, no matter their state of readiness. The announced ship date isn't really a factor in this segment of the software market. If it's on the shelf in October/November, it'll sell, no matter how buggy. If it's on the shelf bug-free on the promised date in March, it'll sell maybe 10- to 25% as many copies. As another poster pointed out, it's simple capitalist economics - make the most money, in the most expedient manner.
I don't know where they shop, but around here (S. California) the software stores will not accept opened software for return. Only as exchange for the same title.
If it doesn't work with your system, then it's your fault. You didn't read the requirements right, or you have the wrong machine or something. It's your fault. Go away.
Of course, those are Windows apps. I mostly run Linux, which is generally quite reliable. The applications with the worst reliability are non-open-source, commercial programs:
OpenSource if definitely the way to go.
P.S. - Netscape did crash while I was typing this.
""You can disclaim whatever you want," says Emery Simon, counselor to the Business Software Alliance, which includes giants such as Microsoft and IMB."
Methinks they rushed this article a tad quick out the door, or a company named IMB as big as Microsoft or IBM exists -- and I've not heard of it! (shudder)
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
Windows 2000/NT is heavily COM based now. Standard services are starting to have COM wrappers. DirectX was written using COM from the ground up.
COM strictly speaking is for defining interfaces - which is a wonderful way to write programs (especially large sophisticated ones).
isolated each component of your project and write and debug them seperately.
Good grief, you are pumping Marx in 1999? How much more proof do you need that captalism won and that Marx failed?
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.
...yes it will, and I'd wager money on it in a Julian Simon kind of bet any day.
the most serious criticism a customer can make is to "actually return the box. And that almost never happens."
Does anyone actually know of a store that will allow you to return software? Maybe even for cash back? The only one I know of is Babbages, and there's only one in my area at a local mall, and it's not even that big of a store. Selection is low, and what is there is 95% games, not counting the console section. These days, if it's open, the assume that you just copied it and want your money back. Who cares if the software really is crap.
Hell, I even had this problem once with hardware. I purchased a cdr from a local, large business supply chain only to have them tell me that I had likely already copied what I had want to onto a cd, and that no, they weren't going to take it back. That was an intersting fiasco. In the end, however, they took it back. Muhah.
I'm working on a paper (which I eventually hope to be able to turn in for some class) dealing with parallels between the Information and Industrial revolutions. One of the major parts is about safety; at this time a century ago, the working conditions of most factories were terribly unsafe; think the Triangle Shirtcoat factory fire (lots of extremely flammable lint lying around; many young women died because of inadequate fire escapes so they jumped from the top stories of the burning building). It took some major (and much publicized) disasters for people to begin calling for safer working conditions en masse. I have the suspicion that it will take a similar mass failure in the electronic realm for a similar push for more bug-free software -- I don't claim to know what the failure will be, I'm just willing to bet that it will be a significant catastrophe. We've already had several minor accidents, like the Mars Orbiter or THERAC-25, but it's going to take something severe that affects many people, like a massive communications infrastructure failure. Though I don't think we have a lot to hope for right now, I have the feeling that eventually, peer-review of a program's source code (under any license, just as long as it's checked) will become basically mandatory, either by the laws of free-market economics or by (yuck) government mandate. The Free Software/Open Source communities already have the structures in place, putting us ahead in the game.
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.
Um, don't click that link. It leads to an evil page featuring infinite pop-up windows. Extremely annoying.
main(O){10<putchar(4^--O?77-(15&5128 >>4*O):10)&&main(2+O);}
That's right. Software just like sex depends on what and how. Take windows for example. It might have all the pretty and "friendly" interface but if you look beyond that there isn't much to enjoy. Sex with a pretty person might seems great but it doesn't go to well if he/she is empty headed. Eventually you'll get tired of him/her. Software is like that too isn't it? You can buy Unreal and have all the nice little eye candy or you can get quake 2 which doens't look at nice but runs faster and doens't crash your machine.. So it's your choice.. chose the bimboware or the geekgirl/guy ware..
I am thoroughly cheesed off with the whole industry. I've worked in support/servicing for around 10 years, and never have I had as many problems as now.
I first realised that the industry was in a mess around 5 years ago, and wanted out, but I was still getting paid well, and was reasonably happy.
Since then, things have gone downhill, but the icing on the cake was when I was supporting a Internet product, with a team of around 5 developers. The manager didn't have a clue - constantly changing specs, asking for new features at short intervals, and getting 'programmers' to modify each others code. I say 'programmers', as most of the code was actually Lotus Notes scripts.
The product was appalling. We had serious problems getting working support for all major browsers. Additionally the major customer reported odd bugs with on version of IE3 that we could not replicate.
The management then had some glossy brochures printed, listing features not implemented, or not tested, including non-Windows client support. The programming team had a few days to get the software to match the specs, and it still sucked.
Eventually I got so pissed off that I never showed up after payday. I was happier not working for the next 3 months.
Since then I have gone to support CA Unicenter - CA Unicenter seems to be the biggest heap of junk going, and they have the nerve to charge out on site visits to get it working, mainly due to the lack of accurate, in depth documentation. There is at least one, and sometimes three, CA engineers working on site to get the product working. There are also a number of 3rd party products that are equally as vile.
I felt so bad this morning that I didn't want to power up my PC, purely due to the mess here.
The big problem is that there is nothing else I am experienced in that will pay my mortgage.
http://msdn.microsoft.com/library/Welcome/dsmsdn /stone033099.htm
(You may need a free Online MSDN account ?)
I quote:
I think this is called the "near enough is good enough" principle of software engineering.
In their defence, having worked on huge, understafted projects, I agree with some of their points.
Linux is never a late project. It comes out when its done. That's the crucial difference -- no hard deadlines.
no matter what the reason that commercial software is buggy, articles like this one will only make people see the true value of Open Source Software. having laws passed to wash thier hands of responsability/liability is not a way to gain a loyal following of repeat customers. The true power and value of the OSS alternative is evident more and more every day, propriatary software digs themselves deeper and deeper into the mire with these tactics while OSS plugs away improving and refining without worrying about deadlines or BIG profits.
The Inmates Are Running the Asylum by Alan Cooper says it all. Go and read it! It very nicely summarizes what is wrong with this industry, and has some good ideas how to fix them.
J.
That was the point of the link, to give an example of when CAD would have to be used. I guess I should have explained what would happen better though. Sorry if I caused any fustration.
Funny that the guy who invokes Karl Marx is the same guy who invokes the christian Bible. Of course, "anonymous cowerd" couldn't even get the biblical reference correct. It's "The love of money is the root of all evil", not money itself. Big difference there, if you happen to live by the Bible.
And I presume "anonymous cowerd" doesn't, because he agrees wholeheartedly with Karl Marx, the guy who spelled out the following goals, among others, in the Communist Manifesto, section 2: (translated by co author Frederick Engels)
1. Abolition of property in land and application of all rents of land to public purposes.
2. A heavy progressive or graduated income tax.
3. Abolition of all right of inheritance.
4. Confiscation of the property of all emigrants and rebels.
5. Centralisation of credit in the hands of the State, by means of a national bank with State capital and an exclusive monopoly.
6. Centralisation of the means of communication and transport in the hands of the State.
7. Extension of factories and instruments of production owned by the State; the bringing into cultivation of waste-lands, and the improvement of the soil generally in accordance with a common plan.
8. Equal liability of all to labour. Establishment of industrial armies, especially for agriculture.
9. Combination of agriculture with manufacturing industries; gradual abolition of the distinction between town and country, by a more equable distribution of the population over the country.
10. Free education for all children in public schools. Abolition of children's factory labour in its present form. Combination of education with industrial production, &c., &c.
This list is quoted directly from the Communist Manifesto, as translated by frederick Engels. Now, this was written about a century ago, so some of these things aren't so revolutionary now. However, he who claims to support Marxism must support all 10 of these, and some others:
The bourgeois family will vanish as a matter of course when its complement vanishes, and both will vanish with the vanishing of capital. -- Communist Manifesto, section 2
So the state will raise everyone's children.
The bourgeois sees in his wife a mere instrument of production. He hears that the instruments of production are to be exploited in common, and, naturally, can come to no other conclusion than that the lot of being common to all will likewise fall to the women. -- Communist Manifesto, section 2
Obviously women who marry are just the tools of their husbands, Marx thought. So, let's just abolish the whole thing.
I don't loathe communism, and socialism, due to any "brainwashing." I have perfectly good reason to oppose it all/
I think that's the key to it... as soon as there's a deadline, compromises occur.
If a programmer/designer knows they have a deadline, they usually work to that deadline, and as a result, will break that deadline.
Of course, the alternative, no deadlines, may stop the project ever finishing. A happy medium is needed.
I'm contracting at a very large computer company at the moment.. my original manager was great, and set targets, but then understood when we broke them. It worked well.
Then a new manager took over (one who needed a really good beating with the clue-stick), and started acting like a twat. The project then became late. And later. And later.
What we need is an objectiv messure when
a testing for a programme is complete.
Not many testers og programmer knows it.
But there is a kind of tools called
covering tools that gives that kind
of objectiv messure.
Let the debunking begin!
First off, I don't think I said open source. I said free software .. Second off.. what is meant by "plagged"? Maybe you're trying to say "plogged" (a retarded way of saying "plagued")? I dated a girl from Wisconsin once who hated hard a's, and pronounced as many of them as she could in this incorrect fashion. "I've got the plog!" It was really scary. =P
At any rate, you're trying to say that the free software movement doesn't have enough clout.. not control.. the FSM isn't synonymous with Big Brother, you know (or.. maybe you don't know..). And yes, it certainly the fsck does. Luser.
This is incredibly vague. Er, I mean "vog"!
Wow, you're so.. specific.. big boy. Yeah, right. Care to define "serious problems"?
Hmm.. More ultra-specific detail.. I bet your gf (or bf, or, well, whatever.. one can't be too presumptuous these days) must know precisely what to do in bed, so good are you at making your thoughts clear!
How in the fuck did you conclude anything? All you said was "those things have problems". Hell, my life has problems, but I wouldn't consider it total lossage (not just yet, anyway). If you can't actually back up anything you say, why bother saying it? Just to try and troll? Why don't you get a real distro like Debian, smart ass? =P
GPL makes for a better license. This better license allows for a better development model. This better development model allows for better products. Will everything that is GPL'ed kick ass? No. Will the stuff that does (or could) actually be worked on, while everyone ignores the stuff that sucks? Yes.
By the way, you seem to think that anything "commercial", by definition, sucks ass. Do you think that Red Hat and the other companies that put together distros write the entire OS? Or even most of it? Or that every company in the world is a seething pit of 9 to 5 code monkeys who can only dream of the ultimate enlightenment that is hackerdom because they aren't "cool" enough by your standards? heh.
You apparently have a sickness. Have you gotten that checked out yet?
That's really.. exciting. Or.. ah.. not.
Did anyone really give a fuck what OS this nut is going to try next? Is that not totally offtopic? =P
Again, you're so.. specific.. For all I know you're not even using Red Hat, but rather one of those really gimpy distros, like, ah, what was the name of it.. LinuxOne or whatever? =P
Personally, I think all of this person's arguments stem from the following:
Naturally I don't care if FreeBSD folks don't care much for GNU/Linux, but if you're going to try to argue a point, at least back yourself up with some examples.. some kind of evidence.. So you sound a little less like a troll and more like an actual biped. ;) By the way, no, I don't think all FreeBSD users are fanatics. I think this one, however, is. Of course, there are fanatics everywhere. They all scare me. ;)
In short, when I read that post, the words "holy war" came to mind. ;)
~ Kish
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").
- Thompson seems to think bugginess is new.
- Thompson seems to think that released bug fixes are a measure of bugginess.
- Thompson uses some phrases without identifying where they come from.
..."good enough"... ..."death march"...
All in all it was a pretty fluffy piece of work I thought.The software industry's response to this crisis is to concede defeat-to shoot for software that's "good enough." What "good enough" means is, of course, a matter of some debate, but critics say it is quickly becoming a euphemism for "riddled with errors"-particularly in the overheated, rush-to-market realm of net apps.
Software has been rushed to market ever since there has been software. Net distribution has reduced the friction of putting out a new version and made it practical to have a massive public beta or to cheaply distribute a patch to new customers. But good enough software goes back decades earlier. Unix was developed as "good enough" for cryin out loud.
Windows NT, hyped endlessly as a way to revitalize computing, was shipped in such a state that this year Microsoft released its fifth-fifth-"service pack," designed partly to patch the latest swarm of bugs.
That's just stupid. True, if a package were bug-free, no bug fixes would ever need to go out. But everyone who uses software seriously has understood for a long time that large software products all have lots of bugs. The fact that MS sends out bug fixes only means that they have the same feet of clay as everyone else.
AFAIK those phrases were defined in the context of software development by James Bach and Ed Yourdon, respectively. They should be credited.
OK Here is a piece of code that works on my systems but is buggy
....
;-)
#!/usr/bin/perl
print "Hello World\n";
Seems simple enough and works fine for me.
But there are bugs in it
1. perl is probably not in that location on your system.
2. There is no exit
3. No comments
4. It doesn't work from a web server (hang on where are the specs for this program)
5. It doesn't take my name in and print it out.
Bah someone obviously didn't write the specification for this program, but if people tried to use it I am sure lots of people (who didn't know what it did) would say it didn't work, it has bugs in it.
It is impossible not to write a buggy piece of code even something as simple as hello world!
(I must admit I wrote a program the other day that ran first time, has over 100 sub routines, a couple of thousand lines of code and it worked first time as *I* specified it to, its a shame its not what the customer wanted, but he didn't specify it
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
Programming is fundamentally a creative, imaginative, and intellectual process. Being that, things only get WORSE if you force people to code faster or longer or harder. That's why bugs multiply. That's why throwing more peopl at a late project makes it later. Much of the industry is working under the wrong model. They view programmers as assembly people on an assembly line. Everybody does their thing and at the end a perfect product comes out. This is fundamentally wrong. Would you ask a scientist to work 80 hour weeks and expect his research to happen faster?
/makes/ the project should communicate with the R&D group and use what they've come up with if they can. This happens in some gaming companies (a segment notorious for its fast pace and deadlines). They've learned that they'll just kill their projects by forcing everybody faster. They set aside an R&D group which develops things the actually product coders can use. This is why you see game engines being developed separately from games. This is why you see some games from a given company all having the same general interface or look and feel. The R&D group produces the non-time-critical things. The other group produces the content and the actual product. I would much rather be working under the R&D model, where I could actually develop /better/ things than just more /crappy/ things. I think the industry needs to just treat programmers as scientists...put em on some floor away from other people...give em beverages, music, free reign, close the doors, and just wait for the magic to happen. You can't force magic.
What needs to be done, and what is currently done correctly in some segments (some game companies), is that there needs to be a partition created for purely Research and Development. This research and development should be ongoing and unaffected by the external considerations of PHBs and marketroids, like advertisements, deadlines, and IPOs. Another group who actually
It's 10 PM. Do you know if you're un-American?
In addition to the points raised here about what coders and managers need to do, I would add one thing that the computer media need to do. (By computer media, I mean anyone who reviews products).
Talk about the bugs!
Rate the product for stability. Any and all bugs encountered during the review should be listed in an appendix. When office suites, browsers etc. are being compared, say which is the least buggy, and factor it into your decision about who should be the winner. I am tired of reviews that just compare feature lists. Reviews I've read over the last 10 years rarely mention bugs, and never give an overall assesment of stability. And software quality has gone down and down. The customer needs to be able to an informed choice based on quality before the industry will be forced to clean up its act.
${YEAR+1} is going to be the year of Linux on the desktop!
Free software just sucks less because you can take out the money factor. Plus if you've got the source and you have the time and know-how, you can fix it yourself. Any major software undertaking is going to have bugs these days, like it or not.
Yes another reason why shrink-wrap CD-based software is a dead paradigm.
I've already seen a project where the design was really polished, but the implementation was done by a beginner which was more or less on her own.
The result was of course a piece of sh...
Was it her fault ? No, of course, we all began one day and all beginners should be closely supervised with his code reviewed, etc, etc.
To summarize: design is important, successfull projects do spend a lot of time in the design phase but good design alone is NOT enough...
I think one of the most intriguing issues raised by this dealt with the way licensing agreements are distributed. I suppose that I have never really thought about it before, but it is bizarre that they can try and argue that opening a box to look at an agreement you never before read can comprise agreeing to the terms. Based on that and the fact that at least one company in the article had had success suing past the agreement, it sounds like the current method of distributing licensing agreements could constitute an unconscionable contract, making them basically illegal and void. It would seem that it shouldn't be too hard(if you remove the obsticle of the software industries hoardes of lawyers) to argue that it is unreasonable to expect that if anyone knew that just opening a box to read an agreement constituted agreeing not to sue of the product was responsible for hosing their data they would go ahead and do it. Of course, if you actually want to collect damages, the problem becomes proving that a single product did the damage, instead of you symantic driver conflicting with a packard bell dll and all of them getting raised to a low boil by your buggy M$ operating system. But the licensing contracts themselves seem to be impeachable.
I had one with my Commodore 64! ..but I haven't seen one since. The reason why we don't have wiring schemnatics anymore is that they would give us incentive to climb inside the system and "mess with it". Well, the way most EULA's are made is that if we "mess with it", we will void the warranty.
- that cracks me up !!
...I was just starting to read page five of the article when it disappeared and I got a DNS screen. Then even my back button couldn't retrieve the article. At least I didn't have to shell out any $$$...
Today the Medici's would have set up an office and secretarial pool right inside Leonardo's studio. He would have been flooded with memos and diversity training seminars. Tortured by all too often incompetent project managers, and forced to put up with a general environment of mediocrity. Who's to say whether the Renaissance would have ever taken place if Leonardo had been forced to undergo the same working conditions software engineers are forced to contend with today?
Is it any wonder that mediocre, bug infested bloatware is the end product of such a system? On the other hand, look at the open source community. That's where the real Renaissance is taking place, and it's about time. It's also no wonder why this community is in abject terror of the corporations swooping down on them and corrupting the entire process. The sad thing is, their fears are not groundless...
Bloatware (Netscape, MS products, Staroffice, Corel) could never be produced in this way; it just isn't manageable.
The net result, I think, is partly an improvement in efficiency (it prevents software and software projects from becoming too big for their own sake), partly a shift of the burden to the user (they have to choose among 20 window managers and get them to cooperate with the rest of their system; and that's just the window manager).
>Windows 2000 is the MOST modular OS I know of.
Then you need to broaden your horizons. NT actually does OK, I'll grant, but it's no shining example.
Slashdot - News for Herds. Stuff that Splatters.
You know, the guy in the purple robes who's at the three-week seminar in Vienna. The one who didn't set up any database authorities for you, and doesn't know what a query plan is and who won't return your calls when you tell him the select statements are sequentially searching that 2 petabyte table with your cleverly designed indexes. The guy who never heard of update statistics. The guy who installs version 22.1 of the database, but neglects to get the associated compilers and libraries.
Coding, coding, coding - When you buy a house dont you ask for plans (of course you dont ask for cars but you trust that that the next door (non sleazy) automotive shop knows everything about your car). Ask for the design for the product. What design - i dont know pick up any one of those million models. Ask for their analysis diagrams, the methodology they used - wouldnt you do that if you bought a house - hell they are not giving away their source code. I mean what did they intend when they built a particular aspect. I agree with the quote from /. M$ just lowered the bar for entry into soft. dev. and subsequently all products suck now. A tool is just as good as the hand that it is in.
... is a futile measurement: I saw a `Programming Pearls' column in an old CACM that had the best illustration.
:= f(1);
The author of the article (a software consultant) found a piece of code of the following form:
a1
a2 : =f(2);
etc for 500 lines. Needless to say the (ir)responsible programmer was paid per line...
What FUD.
Gcc does NOT produce tighter, faster code. This has been proven again and again.
You slashdotters ARE A BUNCH OF KIDS WHO DON'T KNOW WHAT YOU ARE TALKING ABOUT BECAUSE YOU HAVE NO REAL TECH EXPERIENCE.
The assumption that any social or political system will revolutionize life and make for peace and happiness, be it capitalism, socialism, communism, or any other, is fundamentally incorrect. What is really needed is ethics on the part of the people; most any system will work, to some degree or another, if people are ethical. But they often aren't. Capitalism ultimately fails because greed and lust for material wealth becomes the focus of life for too many, and those who become or are born rich seem, all too often, to lack any sort of restraint or values. Socialism (as has been seen) ultimately fails as those with power subvert what may have been a good idea into something that suits them better. Communism (the true form) usually fails from laziness of the minority.
So what can be done about this? Simple--encourage ethical behavior. Respect other people. Be honest. Share your time and talents in your community. Stop talking and DO SOMETHING--ethical behavior is an active thing. Don't be quick to take offense at others' mistakes or even their intentional words and actions.
Just my two cents.
Articles like this one are very ignorant of reality.
First, comparing software development and applications to bridges and cars is ridiculous. If cars broke apart if any part in them was misinstalled by so much as a tenth of a millimeter (the equivalent of a line of code), we'd see a LOT more problems with cars. In truth, a car is a hell of a lot more fault-tolerant than software. The same with bridges. One misplaces screw won't bring down a bridge, but one miswritten line of software will bring down the application.
Second, as for some of the other facts in the article, here's the ugly truth: software quality has to be weighed against the cost of producing that quality. When a company puts out a software product, it has to weigh the quality of the product (the more bugs in the product, to lower the reputation of the company) against cost (in this case, time-to-market: if you are late, it doesn't sell). What would have happened if id software just NOW put out Doom, totally bug-free? Could it compete against the more-buggy but nicer looking games like Half-life? Not a chance.
Also, as a user, do you want to wait an extra 5 years for a product? If you have a million lines of code, it could easily take that long to fully test it. And remember, any fix put in for a found bug can easily create more bugs (as a developer, I certainly know this is true).
It all comes down to this: it is impossible to write bug-free code (of any realistic complexity, at least). It is not cost-effective to test code until it is (visibly) bug-free. The best a company can do it make a product bug-free enough to have users want their product.
One more thing: cars have bugs in them all the time. That's why you need a warranty. It's the car-equivalent of sending out patches after the car is shipped (and if the bug is bad enough, a recall).
As for the point that being steamrolled into coming to work at 8 AM, when 10 AM would do just fine and cut down on traffic problems, that's certainly valid, as is the claim that quality is undervalued compared to hype in many industries, and not just ours. I don't know that socialism will fix this, although it's a tempting thought, most likely all the more prevalent because the "socialist" European countries seem to Americans to be more concerned with quality of, say, films, rather than blowing up buildings and screaming. On the other hand, the exploding buildings are still bringing in the $$$. It's easy to see how someone makes the leap that this has much to do w/ socialism, but it's perfectly possible to live in a capitalistic economy and not buy everything that comes up the pike.
Where is the GPL video editing software? Wheres the GPL copy of soundforge? Sure things like apache and wu-ftpd are fast, but when it comes to enterprise applications, forget it. A bunch of programmers in their spare time cannot compete with a million dollar company. Again I will mention the lack of GPL video editing software. Has GIMP made a dent in sales of Photoshop? Nope. Does Adobe care? Nope. As for bugs what are you talking about? I haven't found one single bug in any of the applications/OS'es I use.
What most of you don't realize, is that software is a SOLUTION (hopefully).
It SOLVES a PROBLEM for people. Just because a piece of software has 1, 100, 1000000 bugs in it doesn't change how much of a solution it is.
I can show you some bug-free software which isnt a solution.
I would rather have IE5 with 2,500 bugs than Navigator with none.
If you think 5 NT 4.0 service packs are like 12 kernel patches you must be crazy. And I don't even want to count the number of "hotfixes" available. Your disdain for Open Source software and reality makes me think you are really a Micorsoft employee (one of the folks they send out undercover trying to create havoc). If you think code quality in commercial products is so great then why does my NT workstation find ways to run out of memory all by itself (oh and forget checking malloc, when NT runs out of virtual RAM it croaks bad).
"If builders built buildings the way programmers wrote programs, the first woodpecker to come about would destroy civilization" -- I wish I new who said that first. I first heard it back in '82, when I got my first programming job.
At first, I thought the problem was: trying to define an analog world via a discrete logic; you can predicate every point you can think of, and still not adequately describe a multidimensional problem space (i.e. it takes an infinite number of points to fill a 3D space).
Ever since Chaos theory was postulated, I believe it to be the finest description of software: "A sufficiently complex system behaves as if at random". That's software.
The onus is always placed on the programmers: "why can't we figure out what the stupid woodpeckers do?"
Believing the blame is ours, I once sought refuge in high level tools, CASE systems, and ISO 9000 paradigms. Only to find out that there are no "silver bullets" for software; adding more software to solve the problem of software only adds to it's complexity, and worsens the problem.
I see every youthful programmer fall into this trap: we always want to write a new language or a new tool that will make programming simpler, but we inevitably add to the complexity (I apologize to all my previous employers for every programming aid I've ever written!)
The problem is exacerbated by the marketing Balmer'$ of the world: software is a product: you cut a CD for a nickel and sell it for $100.00 (that nickel amortizes the software development cost). If there's a problem, sell them the update for another $100.00 next month. Balmer and Gates have made a little profit with this paradigm.
But, we've found the solution. Open Source.
It parallels the analog world: do you expect your automobile to run without tune-ups and never break down? Do you expect that, if your car breaks down, you can call high-school dropout tech support in Detroit and have them describe the fix via pushing buttons on the dashboard? If that doesn't fix it, are you supposed to buy a new car?
The current paradigm is maligned; yet users buy it hook, line, and sinker (often blaming themselves for the problem)!
As George Bonser said: "would you buy a car with the hood welded shut?"
Service is the answer. Software is a service, not a product. In an unprecedented throat-slitting, golden-egg-laying-goose-for-dinner maneuver, Balmer said that last week; legitimizing the Open Source movement. The only way to quickly and deterministically service a product is to have the source... find "what the programmer was thinking", and fix it or do it the way the programmer intended. Guessing and hacking at dialogs and re-installing are too frustrating and unproductive.
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
Language: Most, including the commercial stuff, use Ada because they recognize that code that is more readable is more easily peer-reviewed, tested, debugged, and maintained. So what if it takes a little longer to write and complile.
Processes: Most have lots of well-defined and well-trained processes. There are whole organizations (external and internal) devoted to the topic.
Time & money: They are essentially without competition and are usually provided sufficient money and time to do things right.
The reason that many software products are bad has more to do with the actual software itself rather than its development process or the management involved with the product.
10-15 years ago computers had much less memory, much less disk space and therefore could not handle the complex programs that we have today. The software that we have today are UI driven, need to communicate with many other services and are expected to share data via some interface.
The software that we have today is several orders of magnitude more complex than software even 5 years ago. Most hardware drivers are really stable. Why? They are small, concise, and completely self-contained, which reduces their complexity. Large software procducts do not have this benefit of simplicity.
If you have ever been on a large software product, you know how complex it can be. Tracking down every single bug/dependancy is a time consuming task usually requiring a large team of quality assurance engineers. Fixing most bugs are easy. Fixing some others can result in complete re-writes of subsystems, or directly affect whole pieces of the software.
When it comes down to shipping a product, most companies want to ship bug-free software, but its impossible. There will always be bugs. So, a decision is made to not fix some bugs deemed "not harmful". Most of these bugs have work-arounds. Sometimes management makes bad decisions based on pressures from executive management to ship the product. But, when it comes down to it, the bugs are not in the system because of poor management, its due to the overly complex software.
Software is like atomic particles in a chaotic system. You can easily predict the outcome of one or two particles, but as you add a third particle the system becomes more difficult, adding a fourth, or fifth particle makes the system impossible to predict for all except the most powerful computers.
As software becomes more and more complex, we will see less and less control over its quality. Yes, poor management and poor design philosophies exacerbates the problem, but the underlying problem is still the complexity of the software.
You think the weather is difficult to predict? Wait another 20 years and see where software is.
see http://www.MacKiDo.com/Humor/programmer_excuses.ht ml for some insights let's add question #0: what OS do you use?
Ever been asked in the hallway for a "rough estimate" of how long it might take you to finish a particular bit of software? (Other phrases might be "wild guess" or "pull a number out of your ...") Did you throw out a certain number of weeks or months? Did this number later appear on multiple versions of a development schedule? Were you later accused of missing a deadline because "you said you could do it in three weeks?" This is an example not of schedule negotiation, but of an ambush.
So that I can save time on long explanations in the hallway, here are some issues that must be discussed first.
According to Steve McConnel in "Rapid Development" and cited studies, your estimate of the product schedule is accurate within only a factor of four, AFTER you have an approved product definition. You drop to a factor of 1.5 only after you have a product design specification that details the implementation. In the hallway your estimate is worse. You aren't sure what you're being asked to build, and you don't know yet how you're going to build it.
Why do developers always underestimate development time? Because we are being asked to estimate the effort for one specific feature at a time. But features do not live in isolation. Features work together in a framework with many assumptions about what constitutes reasonable behavior. If you naively try to implement only features that are listed on paper, you will later hear questions like "Doesn't it dynamically update and save the results? Why can't I use this data in the other dialog? Of course that's required! Otherwise, what good is it?" We may be accurately estimating times for anticipated features, but we do not attempt to quantify times for unknown or implied features. Nor do we allow time to correct our original design. As soon as a feature is implemented, we realize the first specification was ambiguous and meant something different to everyone.
In short, the interaction between features increases your effort non-linearly as the number of features increases. Five interdependent features may need to be counted as fifteen new features, with extra work for each new interaction.
So let's assume we've figured out how to give a reasonable range of delivery times after having a product definition approved. We visualize all the known features. We try to quantify the magnitude of the implied features. We estimate a range of delivery dates within a factor of four, like 3-12 weeks or 2-8 months. We can't be more accurate at this point in our project without violating causality and other physical laws. We can imagine making the low estimate maybe 10% of the time. We can imagine making the high estimate 90% of the time. We're still in trouble.
According to "Death March" by Edward Yourdon, a typical software project now begins with a hard deadline and big expectations of what it can do. The deadline is the least flexible parameter. What about other parameters of features, staffing, and quality?
During early negotiations (and yes they are negotiations), your customers, management, and marketing are going to play hard-ball when it comes to features. Your product must do everything. No, they can't rank the features because they are all essential. So you put this parameter aside for the moment.
There might be some flexibility on the staffing. The company might be willing to throw money at your product manager. According to Yourdon, staffing follows some kind of inverse-square law. If you halve the amount of time for a project, you need to quadruple the number of programmers. The bigger the team, the longer it will take for them to work together well. Increasing staff shows diminishing returns. You can only add the developers early. According to "The Mythical Man Month" by Frederick Brooks, adding developers to a late project will delay the project further. Staffing is not easy to adjust, and staffing always has an upper limit.
Software quality, maintainability, robustness, stability, and usability, also can be degraded to improve your schedule -- to a point. If you overshoot your tolerance for poor software, you will also take too long to test and stabilize your product. Feature upgrades can be fatal. Better not push this parameter too far.
You can delude yourself. You can pretend that some magic silver-bullet technology will make you vastly more productive. You can pretend that your team walks on water, that 18-hour days can be sustained for months without burnout, that the project will never change scope again. But let's assume you're not on drugs.
You have the classic inflexibility matrix. The few parameters you can adjust, staffing and quality, are also the riskiest. Given all your hard constraints, you may find that the outer bound of your estimate well exceeds the acceptable delivery date of the project. What can you do? You can try to refuse the assignment, but you probably missed that opportunity. The rules changed when you were not paying attention.
Yourdon recommends triage of features, against the wishes of your sponsors. Divide features into "must have," "should have," and "could have." Don't let too much fall into the "must" category. If your users and managers wanted everything in the "must" category, then it's their lost opportunity. You'll have to prioritize for them. Give unequal scores to these features, such as 9 points for "must," 3 for "should," and 1 for "could."
Try to identify components that allow you to implement these features. Components should be parts of development that can proceed independently. The more you sub-divide your components, the better you can scale your productivity with more developers. Set the score of a component to the sum of scores of features it supports. Try to appraise the difficulty of implementing and testing each component. Don't worry about high scores that are easy to implement, or low scores that are hard to implement. These are casualties that will survive or die on their own.
When you start coding, begin with high scoring components that are hard to implement. These components represent the riskiest part of your development. Reduce your biggest risks quickly, and guarantee the most useful features. The last few panic-stricken weeks should be for easier components, not the riskiest ones. When you inevitably run out of time, you still might have something you can ship. Don't leave too much wasted code behind.
Start coding while your sponsors are waiting to launch the project, preparing slides and strategic documents. According to Steve McConnell, this "fuzzy front end" wastes the greatest opportunity to improve the delivery date.
Of course you still need sensible development practices such as described in "Dynamics of Software Development" by Jim McCarthy. Nightly builds, source/configuration management, risk monitoring, and benchmarks are still important. You won't speed up your project by abandoning previous good practices.
In short, you probably can't negotiate your development schedule. But you can prepare your sponsors for reality. Don't make it easy for them to ignore realistic schedules. You must find flexibility somewhere, so prioritize features for them. Those who set your constraints will have to make hard decisions eventually. Most likely they'll prefer having fewer features rather than nothing. Or they'll decide extra features are worth a delay, after all.
(Reality reasserts itself sooner or later.)
I never get why people insist bugs only occur in software projects. Now don't get me wrong I see a serious problem in the Software industry. But There are plenty of other industries which have similar problems:
We would never have electrical fires if there weren't "bugs" in the wiring.
I think a lot of folks would say there was a Show stopper in the titanics flood control design (the bulkheads didn't go to the ceiling.
If you have ever bought/lived in a house, there are alwaysd little things here and there (i.e. bugs). Shoot the tract home I grew up in had lots of them (I don't think there was a pair of studs 16" apart).
Now I personally think the state of the software industry is in shambles. People are writing tons of throw away apps using these cool nifty visual tools, only problem is the apps stay around and become huge piles of junk.
Part of the reason is most managers know nothing about software so it is harder for them to see what their butchering of schedules does to the code. (If I make a crappy kitchen table it is far easier for the common person to see it is bad. It is much harder for a barely computer literate person to tell what good vs. bad code looks like.)
Also, although the buck does stop with the developer on schedules, most developers won't quit over the issue of code cleanliness. I have had many co-workers who weren't willing to get fired on the principle of staying a professional programmer by insisiting on producing professional code. I was that way for a while (my first few years as a profesasional coder). Now I don't, (partially beauce the supply/demand curve for programmer is in my favor) but at least a portion of the blame needs to rest on the managers pushing for the tight schedule.
A new methodology called Extreme Programming (XP) has been emerging. The idea which is relevent here is to allow customers to make business decisions and technical people make technical decisions. Also of note is the methodologies emphasis on getting developers to work together as a cooperative team. As well as ways to make code more legable without lots of (obsolete) comments. An introduction is provided at ExtremeProgramming.Org
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.
Much of my work involves console games. When publishing a Nintendo or a Playstation title, let me tell you - you will NOT get a major bug out the door. They don't give a damn if you're missing Christmas with your hot, new title. If something corrupts a memory card or locks up the game mid way through, you're not shipping. Nintendo and Sony won't allow it. You're going to fix the problem and wait for testing all over again. Period.
Consumers need to demand a similar approach with commercial software. (Pick an OS)-certified should mean that it's been tested extensively under the given OS by some third party who hasn't got a strong stake in whether the product ships on time.
Becoming certified would become a sellable marketing point, and in time, major bugs would be a thing of the past.
In the mean-time, it would be nice if PC Labs or another of the ultravisible PC media companies would publish a monthly table of major products and a respective danger level. "UNTESTED" the first month, followed by graduation to one of "STABLE," "UNSTABLE," or "DANGEROUS", the ranking of which would be updated with each subsequent patch level. This would finally pressure Microsoft et al to stabilize each release before jumping back into adding shiny, new, sellable features.
Poor software is a result of the failure of the software business model, not of the technical model. Only if and when software companies become legally liable for what their products do, in the same way auto companies are liable, will there be a sea-change in software quality. With the liability comes the corporate-wide desire to do the job right, by any means possible.
"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
I've worked Software QA for about 3.5 yrs. now, having switched over from development and I can certainly sympathize with the article. While everyone rants and raves about the development process, few people seem to comment about the QA process.
Yes, QA often gets garbage to test and not enough time to do it, but in my experience, Software QA programs are also often inadequate. Few if any CS programs dedicate any instruction to testing. My own experience in my CS work in College consisted of 1 chapter from the Software Engineering book and 2 lectures. That's all. Everything I know about testing software I've taught myself.
At my last job (a well known and respected networking company), I did an informal poll of about 20 testers and found that only 3 of them could explain the differences between system testing, functional testing, integration testing, and unit testing. And some of these people had 10+ years experience as testers and were technical leads!
Another problem is this--a lot of talented engineers don't want to test. Software test is often viewed as the bastard step-child compared to development. Talented people view it as a stepping stone to development, not as a career. Many of the people I've worked with that have tested for many years are just not motivated. It's as though they went into a tech career for the $$$ but would rather be elsewhere. People who have a passion for breaking software are hard to come by. Consequently, you get a lot of interns, new grads, and inexperienced engineers working test, with unmotivated people leading them. A bad mix. . . Bugs that QA should find often slide through to Beta sites or even worse, paying customers in a "final" product.
Management often doesn't understand the role of Software QA. My feeling is that QA should be actively involved from early on in the design process since that's the place where most catastrophic bugs get spawned and act as the enforcer (i.e. QA should force developers to follow procedures and have the proper documentation).
I personally like test a whole lot more than development. I was bored with writing code, but have a blast trying to break it. I work with some real test talent at my job now, but that hasn't always been the case.
As a programmer, I have spent a long time pondering the reason(s) for buggy software. Some customers blame programmers, other's just blame software companies in general. While I do feel that I can always plan and implement better and should strive to do so, management seems to be the one more willing to ship soon than ship right. So many programmers blame management.
Various managers have told me, on and off, that I shouldn't blame them. The stockholders demand a speedy shipment. Not only that, but it has been shown time and time again that consumers will buy the product with the most features rather than the most stable product. Magazine reviewers don't help this problem much; they can be quite forgiving of bugs they encounter (after all they were probably reviewing a beta).
So down the road after buying the software, the consumer plays with it, finds the bugs, blames the programmers, the programmers blame the managers, the managers blame the consumers, and so the circle of frustration continues.
Obviously an academic. Spend a few years in the real world.
I've been a software programmer for hardware companies for over twenty years. I've heard so many EE's tell we idiot programmers to "just use the black-box appraoch".
The truth is:
1) Hardware is simpler than software; it's easy to compartmentalize (firmware, like hardware, is also much simpler), and
2) Even so, hardware does suffer from the same ills as software.
Stick that in your academic ear!
It really irks me when I see another EE who's taken the requisite programming class, written "hello whirled", and come to the conclusion that software is simple, programmers must be dumb!
Hugs & Kisses,
Chris
When I die, please cast my ashes upon Bill Gates -- for once, make him clean up after me!
You can sell a perfect product only once, so never produce anything perfect. This is something like the first rule of marketing. This also applies to software. Just sell the product with the bugs, so people will have to buy the upgrades and newer versions too!
is 'It would be cool if it worked.'." - Jean-Louis Gassee, current CEO of Be
What was the original ship date of NT 5?
(hint: vague, but a while back)
So, let me see if I understand you correctly. You complain about companies rushing software out the door, but when Microsoft takes the time to get it right, rather than ship buggy software, you blame them for not rushing it out the door.
You Microsoft bashers never cease to amaze me.
The demand for quality and reliability in cars was spearheaded by Japanese imports - Toyota, Honda, Datsun. Economy cars. They got their toe in the door via their price point. They shattered the market by delivering superior quality and reliability too.
The software industry is hooked on obscene margins and untenable R&D costs. Sooner or later the market will correct this transient condition. Let the current rulers of the profit addled heap cling to their status quo (UCITA) at their own risk. All that is needed to shatter the rule of buggy software is an existence proof for affordable, durable value on the desktop or on the net.
Going with the runaway metaphor, I beieve software is in the Stanley Steamer phase of evolution. Not very widely used compared to other mass market consumables (houses, cars, guns,...). Operated by trained specialists that accept the occasional exploding boiler. Where software is thriving in truly mass markets -- it works flawlessly. Witness ATMs.
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
I have spent the last couple weeks sorting out horrible DLL issues for the install of our upcoming software release.
MS makes it almost impossible to find out info about which DLL version you want and where to find it. Just when I thought I had it down, they released VBRun60sp3.exe and we decided to recompile some of the software with VS SP3, so we needed new files. Oy! (Yes, they're most are on the VS SP3 CD, so they're not too hard to find, but you still have to look at all the versions and test the files and such.)
One amusing anecdote: MS has a "Library Update" out right now that is supposed to fix problems that may have been caused by software developers installing DLL files individually, the end result being that they may be out of sync. The kicker: MS won't let developers redistribute this with our software -- they recommend we install the DLLs we need individually!
Anyone who has played around with Windows 2000 knows there's an interesting new DLL feature -- software installations CAN'T update system DLLs. If they do, W2K notices and makes you put the W2K CD in so it can copy the old one back in. Supposedly, this is part of a new direction MS is moving towards, having system DLLs only be updated by MS packages, and never by software installs.
Will this make our lives easier, because we can wash our hands of it (from a tech support standpoint -- "call Microsoft"), or will it just make things worse?
Cara Hart chart@eNOSPAMfurn.com Systems Administrator eFurn.com, LLC. and ARITEK Systems, Inc.
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
"I have only made this [letter] longer because I have not had the time to make it shorter."
Blaise Pascal
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
A clean product - maybe not. But cleaner is a very good idea, because the products are all the public have to judge the people behind the industry by.
What if the software (or that buggy OS) is used in a life-critical system? Does the programmer have a responsibility to ensure (to the best of his ability) a bug-free system? I would think so! Would civil engineers be allowed to build buggy bridges, or doctors perform buggy surgury?
Someone needs to stand up and stop the madness.
Cheers,
Brian
I seem to recall that when I graduated with about 70 other CS majors, there were also 270 EE majors in my class. Living in Silicon Valley, I seem to know ten times the number of software engineers as I do hardware engineers--and there seem to be many more software companies.
I don't mean to say that a college degree in CS is the only possible qualification for programming, but:
- the shortage of software engineers and high starting salaries has attracted less qualified (and interested) workers to software than to hardware
- there are no qualifications needed to get a programming job, and no certification or credentials you could get even if you wanted to--at least EE's can get PE certification
- many programmers lack not just credentials, but any training of any type in software engineering, or even two-week courses in the programming languages they use
- demand will continue to outstrip supply of qualified people for a long time
I don't know any hardware engineers who got into the field by accident, but I know plenty of bright people who have ended up programming because it was the best-paying option available. They might like to get more training or education in the field, but no employers will pay for it, and nobody will really care when they look for their next job anyway.Number one programming job interview question: name a product you have shipped. It doesn't matter if said product was buggy, unprofitable, or if the team that created it was homicidal at the end--shipping is what counts.
Incidentally, about the Dews. 32 cans at 12 fl. oz. per can would be 12 quarts (about 11.4 liters for those on the metric/SI system). I don't drink too much caffine until later in the day, but I'd say if you had 12 quarts of Mountain Dew in your system, not only could you program/work, you could probably run a marathon and chop a few sequoias down, unless your heart exploded first, which is another whole topic for discussion.
In general, I'd say programmers pulling all-nighers is not a big problem with the software industry, although I reserve the right to change my mind at any time. That's all for now.
"An empty head is not really empty; it is stuffed with rubbish.
Hence the difficulty of forcing anything into an empty head."
-- Eric Hoffer
I've come for the woman, and your head.
..if you're going to school to learn programming, you aren't going to learn much. Potential programmers are well advised to know something about programming before going to school. The most exciting thing you're likely to learn inside an educational institution is probably assembly language. College should be viewed as a way to get a degree, and thus, respect from most businesses who might be looking to hire programmers (many of which appear to be utterly clueless). Or at least you should study/practice some real programming languages outside of school during your stay there.
Hell, even people who want Web designers have ridiculous requirements. A while back I was doing Web searches for such jobs (just to be cute), and most of them required two years experience in Java (I don't think Java had been public for two years at the time =P). Not that I can grasp why you would need Java to do Web design, but whatever.. I've found that having Java applets on your page is generally a good way to make people never come back to your crappy Web site.. =P
~ Kish
Anyone who actually thought I was insinuating that design was the end-all and be-all of computer programming, and that implementation was not important in the slightest.. Well, honestly, I'm insulted that anyone would think I would make such a ridiculous and paradoxical statement. Design is the most important, but every phase of coding any given project deserves the utmost attention. Design shall simply consume the most time.
And yes, anyone who throws a novice at a nicely polished design and doesn't throw any help her way needs to be slapped upside the head. Well, unless you're really just not that concerned about whether or not she fails. You could have just as easily said that design is not enough and it's important you bug test. That's true, too.
Point is, I never said design was enough. I said it's your foundation. Would you build a house on top of a giant mud pit? No, of course not. You're going to find some good dirt and build a pretty foundation, then build it on top of that. However, you can't do a whole lot with just a foundation. You'll be pretty pissed the first time it rains if you're unfortunate enough to live there. Come ooonnn..
~ Kish
However, I can think of far better languages to use for that kind of thing than Java. Besides, you ever notice how most programmers can't do Web design to save their lives? And that most Web designers just don't have what it takes to be a programmer? It seems like a bad idea to bundle up all of the jobs of running a Web site into one position.. Likely, something is going to be terribly wrong. ;)
~ Kish
How many bugs can be attributed to the fact that programmers spent their time writing lines of code, instead of building systems.
If programmers could spend more time developing systems, and let the actual implementation code be automatically generated, would the number of bugs go down?
If programmers could spend more time simulating the behavior of programs using high level models, would the quality of the code implementation increase?
Will the preview function increase the quality of my post?
rogerd@rmii.com
First off, the NYSE is not the only market. Markets are present in virtually every aspect of modern western life. From going to the grocery store, to CPU prices, to car prices, to house prices, to business prices, to
Even big businesses are subject to these market influences. They don't operate in a vacumm. Furthermore, not even the largest fortune 500 firms are anywhere near the size of the USSR bureaucracy. To even make such a comparison is naive at best.
Many would argue that big businesses are victims of their size. But in either case, their sucess or failure doesn't cause people to starve. When a big business performs poorly, their profits or sales are affected since no one is forced to buy from them.
In a communist bureaucracy, some group is always setting prices, quantities, etc. When they choose badly (and believe me, they do) there is no immediate recourse for the people. Everything is administated, and legislated. It is simply impossible to legislate for every eventuality. And even if there were laws on the book, it requires that there be some supreme intellect that knows best.
Try not to think of companies themselves as being infallible. Think of it in a more darwinian light. That is: Individual companies can and do fail, nor is any one company 100% efficient. Rather companies on the whole compete in an open market, and governed by market influences, they are constantly pursuing these certain efficiencies.
I'm surprised that nobody has mentioned formal methods for specification, design and implementation. Back in the 60s & 70s people like Dijkstra declared that programming was a mathematical discipline. Check out Seven Myths of Formal Methods for a summary that dispels the standard myths. This is also really good. Formal methods won't solve all problems, but they're useful.
You know, nobody builds bridges without mathematics anymore.
What? Software is more complex than bridges? People have mentioned design. Design is about breaking down complexity. Some people are good at it, most are bad. A good understanding of mathematics helps.