|
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.
|
|
|
|
|
Shipping it on time
We make commitments to customers and they often make commitments based on that. I have a project on now that involves a mid December release to UAT. If we miss the date, UAT will be delayed and quite possibly the client will not be able to go live before terminating their current contract.
This is a hosted system, so no contract means no trading.
Shipping it with all the planned features
The customers buy our software because of the features we promise them. As the lead in is usually 6 months to a year, a lot of what is sold has not been developed. We have to ensure that we deliver all requirements.
Sometimes, to meet time and reliability constraints a feature may be reduced or even curtailed. But this will result it in being released at a later date, often at our cost. Customers pay for what they get and if the strategic components are not available, they may not pay.
Shipping it bug free
A given. Any piece of software should be tested and re-tested until you are confident that it works as designed. That said, it is virtually impossible to release a complex system that is 100% bug free. Get me over 99% and I'm happy for the odd sleepless night as we patch an errant piece of code.
Shipping it with a polished look and feel
You can't polish a turd. If the software is shyte, the UI will suck like a dock-side whore. A good UI is a result of a good design process. If thought has gone into the look and feel, it will be fit for purpose.
As long as there are plenty of BACON lettuce tomato samiches, all four can be achieved most of the time.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
Its depend on client that it will be on time or its some loose time will give to release a build...
with all the features where included listed by the client, and also its the developers responsibility to do their work properly means there is no bug where left....
|
|
|
|
|
I must agree with you. Its depend on client. But in most cases the clients want to have all features on time with no bugs but they do not understand, that sometimes it is impossible to do everything they want on time...
|
|
|
|
|
there are no 'bug free' apps 
d{^__^}b - it's time to fly
|
|
|
|
|
it's true radioman,
developer can not release bug free applications, always threre are millions of user views 
following are the "software saying", i found it's very true
- Walking on water and developing software from a specification are easy if both are frozen
- Programs must be written for people to read, and only incidentally for machines to execute.
- Any simple problem can be made insoluble if enough meetings are held to discuss it.
- The software isn't finished until the last user is dead.
- Why do we expect documentation to accurately describe the product when the documentation is finished first?"
- When you spend time to find & fix all the bugs in your project, you can't complete the project in your life time.
- We did about 10,000 tests on it, and it was working fine until Monday
- Software has following options but you allow to pick any two : Fast, good, cheap
- Your problem is another's solution; your solution will be his problem
- There exists no "improve performance" checkbox
Rating always..... WELCOME
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
All project managers and clients should remember this 10 phrases.
|
|
|
|
|
koolprasad2003 wrote: - Walking on water and developing software from a specification are easy if both are frozen
This so True and we have faced this in everyday situation.
koolprasad2003 wrote: - Software has following options but you allow to pick any two : Fast, good, cheap
While this is hilarious[but true]  5d!
Believe Yourself™
|
|
|
|
|
koolprasad2003 wrote: Rating always..... WELCOME
My 5 
|
|
|
|
|
In the industry I work in (aviation) first it's shipping it bug free. Second will be on time.
I feel that its very much industry dependent... Thats why you have formal testing in banking and aviation industries. Other industries not so much.
On time before the market releases other products(software) before you.
On time in order to make a profit. We all know the penalties that envolves not delivering your project on time.
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
Bug free? My bosses are not used to getting applications that work. They have a nice collection of candidates for the Hall of Shame. They probably think it must be that way, as long as they get their stuff quick (= cheap) enough. Testing or anything else that takes more time usually is 'too expensive'. They will probably never learn that buying a really rotten program at 50% of the price still is a 100% waste of time and money.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"
And I smiled and was happy
And it came worse.
|
|
|
|
|
R. Erasmus wrote: We all know the penalties that envolves not delivering your project on time
We also know the commercial implications of shipping a POS. Delivery on time but full of bugs can destroy your company image far, far faster than late shipping.
In the world of hardware, shipping a buggy product can cost a company billions: think of the cost of recall and fix work. One company I worked for did just that with a new Visual Display Terminal (pre PC days) - the cathode ray tube failed after two months use. The cost of getting engineers to site, and fitting all new tubes was twice the company annual turnover. Fortunately the company survived, but it drove home a lesson: Test it, testing again, and only then think about shipping it when you have also got someone else to test it. Twice.
Software is the same - just you don't need to send an engineer.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Even when we ship bug-free (close to zero bugs), our boss thisnks - Hey that was pretty easy work you got!
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
your boss live in the pink world ;}
d{^__^}b - it's time to fly
|
|
|
|
|
shipping in time , and bug free in not only the things to achieve , it should have a nice look and feel too , we try to be the best among the competitors
pk
modified 14-Nov-11 4:20am.
|
|
|
|
|
Its very important to fulfill all the four points when releasing an app. 
A friend walks in when everyone else walks out...
|
|
|
|
|
The following is true for custom solutions:
- Being late is bad for business, having small bugs is acceptable if you show you are fixing and releasing often.
- Having a "working" software is a necessity, by working we mean getting the basic job done.
- Implementing the full feature set in the initial release is not cost/time effective as the users will generally only use 70% of the feature set anyway.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
No,most probably it should not is not possible to release app bug free in its first version (IMHO).
so i am going with to provide planned features and it should be the first preference from my point of view.
modified 14-Nov-11 2:17am.
|
|
|
|
|
Pritesh Aryan wrote: it is not possible to release app bug free in its first version
Yes it is!
Why should the first version be any more prone to bugs than any other version? If you can ship V2 bug free, then you should be able to ship V1 in the same condition.
Admittedly, it rarely happens, but that doesn't mean you can't aim for it.
Saying "it is not possible to release app bug free in its first version" is just saying "I can't be bothered to test this properly - let the users do it"
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
ok,..i should have to use word probably i think.
actually English is not my first language so i can't express my exact ideas or views over here .
modified 14-Nov-11 2:47am.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
