|
not each and every piece of code can be bug free, but should have to be stable release ....
|
|
|
|
|
Delivering in time and with all the main features is the core to me.
Some bugs are usually acceptable on the the first release as long as they're not critical.
Customers like punctuality and delivery.
Although they exist, I never worked on a project that didn't care about the delivery time.
Time-to-market is very important and can completly ruin the whole project chances of success if shipped one month later.
The trouble with this is to be able to elect the "main features" and don't want to have everything done.
Another important point is to define critical and non critical bugs.
So my 3 rules of thumb are:
1. Don't change what is already done. Leave that to the next version.
2. Do what's important first. Don't loose time with less important things.
3. Give severity points to bugs. Don't fix lower severity while higher exist.
I must admit I don't always follow these strictly  but I try to keep them in mind.
Cheers!
Alex
modified 14-Nov-11 19:02pm.
|
|
|
|
|
All things considered, delivering the goods on time is, perhaps, the single most important requirement in any serious (software) project.
You may delay the delivery date once, maybe twice if your product is really unique, but if “delay” becomes your middle name, the client will seek for an alternative elsewhere.
Sure, the product won’t be perfect (it will ship with annoying bugs and the user interface will somehow look hideous to some of its users), but at least most of it works as expected and the client may proceed with its own agenda.
Then, under lower pressure, you have time to fix some of the bugs, brush-up the looks and feel and delight the client with extra-unexpected-features he didn’t know he needed.
|
|
|
|
|
you really want to say all of the above.
however, in the business world what really matters is introducing a product inside a target window that best maximizes the purchasing ability and pattern for your customer. there is a reason why you see products released only at certain times of the year.
bugs can fixed, new features can be done in subsequent releases and as the product continues with it's life span you can improve its look and appeal.
as if the facebook, twitter and message boards weren't enough - blogged
|
|
|
|
|
It is always my goal to provide bug free code regardless. Experience and good coding practices can mitigate a good number of them. V&V should bear out most of the oops and huhs.
So for me it was important to have all the planned features working, if the customer/client is not getting what they ask for then the goal of the project has not been met.
It was broke, so I fixed it.
|
|
|
|
|
S Houghtelin wrote: So for me it was important to have all the planned features working, if the
customer/client is not getting what they ask for then the goal of the project
has not been met.
What happened at the design phase?? How does one decide to ship an application that is not what was asked for??
Peter Wasser
|
|
|
|
|
|
As a manager, if you give me buggy and unmaintainable code on time, the chances are I will not give you more work. If you tell me a couple weeks before the deadline, you need more time to ensure less buggy code and more maintainable code, I will give you more work.
I have a guy who always is on time or delivers early, but his code is buggy. I have another guy who is usually a little late, but his code is rock solid. The buggy code is in QA too long and the deployment date always slips. The rock solid code, passes through QA with little delay and the deployment is never delayed.
I want the rock solid guy, you would not last with me.
|
|
|
|
|
Message Removed
modified 16-Nov-11 9:24am.
|
|
|
|
|
Amazingly there's no bacon option...
I'd say that if you'd ship it with bacon...no one will bother if it has bugs, doesn't contain all planned features, etc 
"Whether you think you can, or you think you can't--either way, you are right." — Henry Ford
"When I waste my time, I only use the best, Code Project...don't leave home without it." — Slacker007
|
|
|
|
|
Maybe you should just replace the planned features list with bacon, then you could probably get it out faster too...
|
|
|
|
|
whatever the contract says.
|
|
|
|
|
The contract probably doesn't allow for bugs.
|
|
|
|
|
The contract probably doesn't allow for delays nor missing features either.
sign and execute, or don't sign.
also, bugs and maintenance/support contracts go hand in hand.
|
|
|
|
|
Granted I wouldn't mind shipping an app bug free, but let's be realistic here. If we (us developers) were to eliminate all bugs the deadline may be extended (depending upon the severity of the bugs). That's why I chose the last option to give the app the polished look and feel. The polished look and feel also encapsulates shipping an app without major bugs and leaving known minor bugs.
Also, with leaving known low-level (no show stopper) bugs in code that will be addressed hopefully in a short period of time with an update could make a customer feel that the app is always improving.
Just my thoughts.
What do you think?
|
|
|
|
|
I agree... 
There's that happy medium, of course everyone wants to ship bug free software, that's just not all that realistic.
|
|
|
|
|
|
I agree to a certain extent.
I always believed that a polished look and feel would not seem very "polished" if there were major bugs. (Just my opinion).
However, you're analogy is something I very much agree with and it also applies with minor bugs too! If the minor bugs in an app feel like a root canal as you put it I can see customers (including myself) moving to another app.
Thanks for your 0.02.
|
|
|
|
|
I love to make it as bug free
No matter what the destination.The way we choose is Important.
|
|
|
|
|
and thats the real challenge.
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
yeah its really challenge to developers
No matter what the destination.The way we choose is Important.
|
|
|
|
|
..it's got to be On Time, otherwise my clients are non-compliant - drop-dead date is not a moveable feast.
It’s not because things are difficult that we do not dare, it’s because we do not dare that things are difficult. ~Seneca
|
|
|
|
|
My nature would be to make sure it works as flawlessly as possible before it's touched by those user-creatures.
Experience has shown that they really do prefer form to substance.
Just look at their voting habits.
Purchasing habits.
Mating Habits
What passes for music these days
ad nauseam
So I voted for "Shipping it with a polished look and feel".
Besides, it's in biblical: 'Answer a fool according to his folly, lest he be wise in his own conceit. Proverbs 26:5
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
People are willing to accept a bit buggy sw delivered on time than a "100% bug free" one that goes beyond promised due date because the bugs-patch cycle of sw is so ingrained into people's minds that it seems "natural" to them.
|
|
|
|
|
The question says what is most important to you, meaning me, and not my employers, or customers, although I of course realise that many developers are their own employers.
So the most important for me is bug free, or as close as I can get to it.
On time is not so important , and I am lucky in that I develop for an audience who cannot go elsewhere, and the business will not suffer (in most cases) by late releases.
Shipping it with a polished look and feel is nice, but not really important to anyone. Users want to be able to use it, and useability is far more important than looks. An easy to use app generates far fewer support calls.
Shipping it with all the planned features is also not so important, as long as communicated properly, because moving forwards future releases that give more or make things easier are seen as a positive with users and managers.
But if you release something that is overly buggy then you cannot get on with new features, or new apps, or polishing it up for future releases, because you keep being disturbed by support calls or bug reports.
And buggy software annoys users, it makes them lose confidence in what you have done and what you do in the future. It makes them less keen to get to know your software, and often it makes them look for workarounds so that the app ends up getting used in ways you were not expecting it to, and further issues can then present themselves. Also users who are used to buggy software and frequent patches stop reporting bugs or issues when they do find them. They either work around, ignore areas, or just assume that it will already be being worked on.
Releasing software with as few bugs as possible, ideally none, makes everything you do from then on so much easier.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
