|
Losing the old mindset that a product can somehow be perfected is a major step toward understanding the problem.
|
|
|
|
|
In other words, "I feel much better now that I've given up?"
|
|
|
|
|
Not exactly... I'm not saying that there is anything wrong with striving for perfection... the problem is that once development lock-in is reached, perfection is no longer attainable... not by a human being, anyway.
|
|
|
|
|
The largest problem I see with software today is how users make their software purchasing decisions. Most users make their purchasing decisions based on the number of features (both superficial and core features) a product has, plus its presentation material (box, ads, slick sales people, etc.)
Since a retail software development company will make more money by putting their resources into 'marketing' instead of good quality QA, this is where it usually goes.
Unfortunately this is a marketing driven world....
Just look at the quality of many items you purchase today compared to 30 years ago.
|
|
|
|
|
than they used to be which has resulted in less buggy applications than in the past.
Anyone remember developing for windows 3.1? Or networkable apps under windows 3.11?
I would say on average it's more likely that a particular *feature* in a big program is buggy, but overall most commercial software is quite robust in general. Which I guess isn't too suprising since there are literally thousands more features in most commercial software than a few years ago.
Ground Zero Tech-Works
http://www.ayanova.com
|
|
|
|
|
I definitely think commercial PC software (not embedded stuff like in cell phones) appears to be buggier, because companies are under pressure to get new releases out faster, so they- Give the dev team less time to do their work (and sugar-coat it with the euphemism "aggressive scheduling"),
- Skimp on testing, and
- Ship with more known bugs.
Not to mention that with the software industry going south, there are fewer people on the teams.
They also have the mindset that "oh we'll just fix those bugs in a patch" which IMHO is a horrible attitude to take and shows no concern for the customers. Just a short time ago, my mom got Myst 3 and it crashed whenever she ran it. It turns out the company knew about a crash on some Intel chipsets, but lo and behold the game also crashed on S3 cards (like my mom's) and a couple other chipsets. That is inexcusable in my book.
--Mike--
http://home.inreach.com/mdunn/
Push the button, Frank.
|
|
|
|
|
One add to that problem might be the tendency to simply burden old and once reliable sourcecode with more and more and even more features. It's part of the "Give the dev team less time to do their work..." issue you described. Instead of e.g. redesigning once in a while companies tend to put workaround upon workaround in sourcecode written by people who have left the company years ago. So you end up with a big, almost unmanageable lump of source that was optimized when it was written for 16bit, tolerable when it was recompiled for 32bit and will be intolerable when it is recompiled for 64bit. All those steps with just more used-once-a-millenium-features instead of really porting to the new processors... and so on. 
|
|
|
|
|
I have being thinking about that lately from the ethical point of view. Is shipping a product with known major bugs ethical?
Recently I bought an application. The company's website claimes it runs unnder windows 2000, but the box or documnetation does not mention about it. I said let me tried. To my surprize when ever I use the multimedia (it has Audio and Video) the product crashes. I contacted Technical Support via email. Their reply was totally unrelated to my problem . I resent my original message with some strong words (I thought they never read the message, based on their reply). I got a shocking reply. They don't want to admit it was a bug in their side while they laid all the fault either with me or my PC ( including the OS). I contacted them by phone and returned it back.
Yes, it is impossible to create an application bug free, but
1. Fix all the major bugs, even if you have to delay your release.
2. List all you minor bugs and ( possibly work arounds) so the consumer is aware of it.
3. when ever a customer comes back with bugs, admit it and try to resolve it.
I think in one one what I am trying to say is "HONESTY"
Enjoy.
|
|
|
|
|
I do a lot of software development (all kinds). And it seems to me that the companies which produce the tools we need are having to get their products on the market too fast to keep up with the demands of competition. The competition places so much pressure to get out new capabilities/features and even completely new tools that it just isn't possible to test adequately.
When working contracts for some customer, costs often have to be cut at every corner. To the point that the cheaper tools sometimes get selected and they will typically have more bugs than the larger, better known tools.
I worked on a project recently using an particular compiler package (I will not name here) that had so many bugs in it that I could not rely on the object code it generated. (It was proven to generate buggy obj code more than once). And this was an application where failure was NOT an option.
I understand how hard it is to compete in the software market. But I, for one, am tired of being a "beta tester" for the tools that I need to do MY job.
WillCodeForMoney
|
|
|
|
|
...am tired of being a "beta tester" for the tools that....
This Code Project thingy with .NET BETA 2 is the worst of all 
(no offense, Chris)
maXallion
"Look for bugs, I hate bugs!" - Warden, The Mummy
www.maxallion.de - coded evil & more
|
|
|
|
|
I've talked to guys at Microsoft, and Nick Hodapp also asked some of the .NET framework guys and no one else seems to have experienced the problems we are having.
cheers,
Chris Maunder
|
|
|
|
|
Funny, that's exactly what I tell people who call us with bug reports 
Christian
#include "std_disclaimer.h"
People who love sausage and respect the law should never watch either one being made.
The things that come to those who wait are usually the things left by those who got there first.
|
|
|
|
|
When i started to program on good old Commodore 64, every user was able to load file from cassete, run it, copy it,... After my jump to PCs, there was still quite a lot of users that was able to configure config.sys and autoexec.bat, install programs, copy files and the ACTUALLY did know what file is... now i am quite thrilled if some of users is able to copy file, or he can at least follow my instructions over phone (instruction: close application, result: users shuts down machine).
Actually what was once called user now is in most cases called system administrator(dont feel insulted if you are what was once called system administrator,(registry is still BIG question for, lets say, 40% of system administrators)) so i think term user should be redifined.
|
|
|
|
|
I totally agree with You (I'll start on MPM system on 1983), but I think that the worst aspect on IT is the quality of (many so called) programmer. Like your system administrator they think that using a RAD (or a VC wizard) or editing resource is programming...
They claim to known 6..8 languages, but the result is poor code, most from cut and paste (productivity ?), unstable and unreliable.
They are unable to debug code (tedious ?) and too much concerned in new fabulous feature, so they forget to correct and maintain the function that let the software really work.
What I really hate are functions that can be found on standard library ( MS - SDK - STL, etc. ) re-written (with many enhancement - bug first) just because they are keyboard-dependant...
Every stone thrower can find me at zaksoft@tin.it
Davide Zaccanti
ZakSoft
|
|
|
|
|
Couldn't agree more! A recent example I had is a Co-Op student copying my code into his application and then having the nerve to call me and ask why my code doesn't work in "his" application. He didn't even bother to figure out what the code was trying to do or how!
|
|
|
|
|
yes, but we can't change the users, can we?  (well, maybe it could be done if MS would use the same ammount of money they're spending on marketing .NET to launch an initiative to educate users, which will never happen, of course).
as far as bugs are considered, i think it depends more on kind of the process you have at your workshop, then on specific tools, although the tools are the part of the process.
In company where i work, we introduced a well-defined development process a couple of years ago, and after some time of getting used to it, all projects showed decrease in number of defects and maintenance cost.
|
|
|
|
|
...and after some time of getting used to it, all projects showed decrease in number of defects and maintenance cost.
It wouldn't be coffee by any chance would it? 
|
|
|
|
|
yes, that too...
|
|
|
|
|
The so-called programmers... I am currently in school, and they're supposed to teach us C++ - and they succeed in doing that to some extent, only problem being that about 90% of students around 'know' C++, but not what a file or a directory is  . To them, "C++" is a really old version of the Turbo C++ IDE for DOS  . Is it the same everywhere?
"A surprise to be sure, but a welcome one."
- Senator Palpatine
|
|
|
|
|
Most users (and we are too, sometimes!) became more demanding in the last years. What once was a "configuration problem" solved by playing around with config.sys, is now a bug. If something the UI allows (or suggests) to do, but there's a messagebox "foobar not found", it's a bug now. Oh well, and if a bad written driver crashes your system, it's windows.
(There's another tendency, of "user used to bugs", accepting almost everything)
What upsets me, however, is more and mroe of software released as "Beta 0.1, 0.2, .., 0.9, 0.91, 0.92,...", or even "Alpha" so everybody knows nothing to expect - throwing in features rather than getting a halfway solid 1.0 out.
And, there are some bad folks in the crowd. My personal experiences with Star Office are horrible - fresh OS install, fresh StarOffice install, and crashes twice an hour. Removed it asap.
|
|
|
|
|
What once was a "configuration problem" solved by playing around with config.sys, is now a bug. If something the UI allows (or suggests) to do, but there's a messagebox "foobar not found", it's a bug now.
very nicely put. I haven't really thought of it that way, however, it makes alot of sence.
-Jack
|
|
|
|
|
well, and what is a bug now, is a feature tomorrow. (ever noticed how thin is a line between "Microsoft has confirmed this to be a bug in the Microsoft products..." and "this behavior is by design" in MSDN?)
|
|
|
|
|
I would say recent applications tend to be more robust in that they can handle more in terms of everything from users to function calls. They have better methods of using the hardware and also tend to be a bit more "friendly" towards other applications.
However they do tend to be more buggy, simply because the complexity we are trying to achieve has outrun everything else.
regards,
Paul Watson
Cape Town, South Africa
e: paulmwatson@email.com
w: vergen.org
|
|
|
|
|
I think that it really depends on what kind of software we're talking about here. Nowadays software is used everywhere, all the time and for everything. We're talking mobile phones, televisions, satellite, PDA's, military, hospitals, space exploration etc...
If software was more buggy, then the world would have collapsed long, long ago. Software has improved, programmers have improved and technology has improved. Its just that with such a large audience watching, each small bug is seen.
Programmers are what make the world go round. People don't understand that, and we don't excpect them to. After all, they're not programmers.
(2b || !2b)
|
|
|
|
|
> "Nowadays software is used everywhere...military, hospitals, space exploration etc..."
Well I work on government and DoD projects and most of those are on tighter budgets than any other type of project (thanks to the touchy-feely-the-cold-war-is-over-the-world-is-one-big-happy-place no-nothings -- I seem to recall people saying the same sort of things at the end of WWI and then came Pearl Harbor) and typically do contain more bugs.
Due to ever tightening budget constraints, the military (and space agency) has to rely more and more on commercial tools and applications (referred to as Commercial-Off-The-Shelf, or COTS) to develop and supplement applications that they need. And since many of these DoD and space applications are built using those commercial tools that get pushed out the door too fast, loaded with bugs, those commercial tools can introduce still more bugs into such critical software. Further, many of these contracts do not contain the budget to purchase the typically too costly on-going maintenance agreements with these commercial companies to fix the problems with the crap they are generating. Note that I am not saying that all commercial companies produce garbage software but some produce more than their share of it.
Recall a recent Mars mission that was lost because one subcontractor used one set of units-of-measure while another subcontractor used a different one and -- guess what? They didn't test it adequately due to the "smaller-faster-cheaper" philosophy. And when the 1st software called the 2nd, an error resulted in a computation and the mission was lost.
Luckily that was an unmanned mission. Can you think of some systems controlled by software where a failure would result in the loss of hundreds, perhaps thousands, of human lives?
Here is another example of the importance of bug-free commercial software. We all have endless complaints about the instability of different flavors of Windows. Fortunately they are getting better. This is good since future weapon systems such as the next generation of super carrier will use a Microsoft Windows operating system for many of its critical functions as the US Navy continues its development of the more automated "smart ship" concept!
Adequate test is critical in many development efforts. Due to the increasing use of COTS software over custom-developed software in safety-critical applications, developers must use extreme caution in selecting these commercial tools.
I hope someday that we, as a software user community, begin to demand quality over the latest bells-and-whistles from the commercial software industry.
The importance of stable, bug-free commercial software is becoming far more critical than simply worrying about whether Sally Secretary backed up her PC lately.
WillCodeForMoney
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
