This is an interesting article that promotes getting software out before it's perfected. Posted on this programmer's blog.
Not all, but a lot of software has bugs. Just check PHP's bug list. (Total of 41898 bugs) http://bugs.php.net/bugstats.php However, maybe you can find a point in the middle. Release a version that works correctly, and keep adding features to it and make it more perfect and useful. If you release software with too many bugs and problems, the clients will lose their trust and go with another software. Once they lost their trust it's hard to get it back. So don't try to lose it on first place.
Interesting point, Nico, but at what point do you determine it's ready for market? What do you measuring and how? Do you benchmark something or is it a case-by-case call?
I'd say it's rather a case-by-case call. But if your software does what it is supposed to do, without any errors in all circumstances and situations that you can think of, then I'd call it ready for a first release. Write your code in a way that it doesn't produce any errors in any case. Users can be stupid if they want, so never expect them to use the software like they're supposed to do. If a field is only supposed to submit numbers, then make sure your server-side script verifies that. Don't expect the user to enter a number where it tells him to do. Also, it's good to write your code while error reporting is set to E_ALL (in PHP at least). Make sure it doesn't produce any errors for best security and performance. Put your own script in all possible circumstances that you can think of. (Empty fields, incorrect input, etc...) Keep in mind that the users of this script may be using a different version of PHP, or that they're on a different platform or have a different configuration for their server. So make sure all newer build-in functions exists, and/or try to emulate them if possible. Do never use PHP short open tags as they can be disabled in php.ini, etc... As said, that a software has bugs is the most normal thing. Just offer updates or patches as soon as possible to the user so he sees you're a reliable company/coder/ or whatever.
wait first of course, why need to be hurry? :-/ unless if you're planning to make it as Open source and hoping that you're going to get some collaborative work from other programmers, I don't think it's worth it to get it out ASAP :-/
No software will ever be perfect and you'll find you can never meet the users needs perfectly on your first try. You bug test it the best you can and do get user opinion but once you believe it's bug free and you have all the features you want to release it. Once software is released to a much larger user base you quickly see bugs come up as well as feature requests or changes on how the feature should work or even usability. I've done in house programming for corporations before and you'd be surprised what the users can find. You release the software and within a few days there are requests for changes and all sorts of things you never anticipated. But you then realize it's a necessary step otherwise the software would never get out the door. It's just a matter of not any show stopper bugs being in there and if so patching them very fast.
If you don't ship the software, you can't make money on it. If you do ship the software and there are critical bugs, your cost of software just went up A LOT. Look to eliminate all critical bugs. Then ship and make sure you have the infrastructure in place to do automatic updates as needed. In other words: PLAN FOR BUGS. They'll happen anyway. Just make sure you don't have anything glaring (like it's unable to install on a typical machine).
Since I come from an engineering background, I am familiar with the concepts of paralysis of analysis and "it's time to shoot the engineer and start production". For the most part, with software the risk is much less than in engineering. A software crash typically is much less catastrophic than a physical crash and redoing code is much easier than redoing steel, concrete, glass, composites, etc.. With that being said, software should get out into the user reasonably quickly and can be covered with a beta tag. I like to refer to Guy Kawasaki's book Rules for Revolutionaries which has two chapters calle "Don't worry be crappy" and "Churn baby, churn". The idea is that you need to get the code or product out there and find the real problems with it and fix them quickly. I am also reminded of a company that launched a new luxury car brand. The first vehicle cost about twice as much as their basic brand. The first model had defective cruise controls, defective brake lights, and a major electrical system flaw. You would think the company would have suffered but they quickly responded and survive today as Lexus. Lexus still ships products with major flaws but the respond quickly in fixing the problems. Ship the product and then get to work.
I think the question is not about the software having bugs, but about how easily you can fix them. No software will every be bug free, of course. Some people say that users will be put off the software if they find a bug - not necessarily. If a user finds a bug and reports it, you fix it quickly and then contact the user who submitted the report, telling them that you have fixed it, thanking them for the report and providing a link to download the latest version (or however you distribute bug fixes), then you have just involved that user in your software in a profound way. That user is much more likely now to remember your software product and your company, and to look upon you favourably in the future, recommending you to their friends, etc. For industry examples, just look at microsoft and google. Google is always releasing its products in beta first (e.g. gmail and google maps), and microsoft is king of the downloadable updates. There is nothing wrong with this.
Remove all the major bugs from the software before shipping. Maybe you have to patch some of the unexpected things in the future, but don't ship it if you have things in it you can catch and fix now. If you're trying to make a first impression with the software, the last thing you want is a negative viral effect of everyone telling their friends it's trash.
i just wrote a long message stating why i think you should take the time to do things right.. but i took my time on the message and when i hit the submit button i was taken to a login screen.. which i than logged into.. which took me back to that same login screen and that continued for a little while.. long story short.. lost the post.. however, i'd still like to say flawless software isn't that hard to create, at least on your side of it.. if you're designing a program to work in XP than noone using XP should come across any errors.. if someone is trying to use your program on some kind of 3rd world operating system they made themselves, than they can expect problems.. anyways.. i quit
As with most replies...it depends. I use to work for a hedge fund and all tools were built for internal use. We went with the test first philosophy. It really is the only way to work in that type of environment. Test, change, test, change, test, change. The programmers had to work closely with the traders and analysts to constantly refine and improve the software. As soon as something is functional, they want it start using it.