|
I think these should be addressed before shipping a product:
1. Major issues, Showstopper stuff etc.
2. New features to well......DIFFERENTIATE the product. People aren't really going to be interested to shell out their cash for a new version which just fixes bugs.
3. UI is dependent on time and most of all whether it is planned to be a major overhaul for the product's next release.
My Blog
My Achievements:
* Posted 25,000th message in GIT O_O
* Official supporter of the "thatraja's GIT Meet Sponsor Foundation" 
What you do, when you don't know what to do is what you do when you don't want to do what you do.
|
|
|
|
|
This shouldn't be an either-or question.
|
|
|
|
|
I agree.
Better yet, allow us to rank the options given.
|
|
|
|
|
It isn't; it's specifically asking the most important. That doesn't make the rest not-important, it just says that it's on top of the list.
If you could rank them, as suggested in another post, which one would be on top?
Bastard Programmer from Hell 
|
|
|
|
|
Dmitri Nesteruk wrote: This shouldn't be an either-or question.
The real world rarely offers you everything you want. That's the entire point of the question.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
If you think as an end user first you look at the UI and user only purchase/download an app if he loves the UI.
However if it is not performing well, get ready for poor comments.
|
|
|
|
|
mahesh@indianic.com wrote: If you think as an end user first you look at the UI and user only purchase/download an app if he loves the UI.
However if it is not performing well, get ready for poor comments.
Depends on your audience. Most will judge the book on it's cover, where some readers actually read reviews and specs.
I'm not paying for "shiny".
Bastard Programmer from Hell
|
|
|
|
|
100% bug free is sometimes difficult.
Hi,
This is arun
|
|
|
|
|
I answer, but: if I have shipped on time soft with 1000000 bugs - what the sense of this soft? Ok, I have no bugs (it's not realistic, but just imagine) and have only a half of planning features. What the sence?
It's simple example, but I just want to say- really it's always compromise and depends of projects/customer requirements.
modified 16-Nov-11 10:14am.
|
|
|
|
|
That's why I prefer to use a "10%" as the basic measure.
If 10% of the application has severe bugs, or if it crashes 10% of the time, then it is unstable in my opinion.
If it has a delay of 10% (or even 20%)... then, well, depends on the contract.
If is misses 10% of the features... well, I can say that ones takes to the other. After all, a project that is on time, but having 90% of the features will not be on time with all the features.
I can use the articles for example. Which one is better: A software that comes with the article and is incomplete? Or a software that has all the features, only partly explained and most of the features crashing at one time or another?
In my opinion, an article is a kind of project where it is more important to give a bug-free code than to give a full-featured project.
Do you want to create a new programming language?
Do you want to know how to create a virtual machine?
Are at least interested on how they work?
So, see my article: POLAR
|
|
|
|
|
One assumes that a polished look and feel means all features are in place and bug free!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
If everyone thinks like you then you'll never see "Shipping it bug free" 
|
|
|
|
|
I think you can have a polished look and fee without having all of the features in place and without being bug free.
I've been working with WPF for the past couple of years and here's my example of look and feel vs features and bugs. When we first released the internal application I'm working on we had a mix of standard WPF controls and Infragistics' WPF controls. There were some areas where we just didn't have the background, button and highlight colors matching between them. There were also some areas where the flow of the application just wasn't natural (things were on separate tabs that should probably have been on the same tab etc) That's all look and feel stuff.
I'm not saying we were bug free, but we did have all of the features worked in, and most of the bugs worked out for the release. After that we fixed any bugs that were reported, then cleaned up the look and feel to make the app look "Polished". We could have gone the other way and made the application look really nice for the release, but it would have required leaving features out, leaving bugs in, or pushing the date back.
|
|
|
|
|
Polished look and feel does not mean polished code. So I have the feeling your are not assuming correctly.
You can have a great look and feel, with an application that looks well thought, easy to use and understand. Yet, some features may not be available and some menus or buttons will be disabled. And it could crash occasionnally (or frequently).
Bugs and missing features may not even be an issue for some apps, if they are still useful in the end in spite of the issues. That would probably not be the majority of the cases, but it is sometimes true.
In the end, I could not answer this poll because it depends so much about what the program is about. What is important varies a lot, and all 4 answers may be the best one depending on the product.
|
|
|
|
|
Not at all. An app can look fantastic with the UI gleaming and shiny, but it can run like a dog, crash continually and have half the features end in a dead end.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Chris Maunder wrote: have half the features end in a dead end
In which case it does not have a polished feel. IMHO a polished look and feel encompasses the entire app, not just the shiny bits that go whizzzzz.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
OK, so remove the "dead end" part of my comment.
An app does not have to be feature complete to be polished. Saying as much is akin to saying practically every app you use is unpolished, since almost every app in existence can have, and probably will get, new features.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
There is a huge difference between new features and features that have been specified and not completed. AFAICT no application is ever completed till it is dead, bloody users always want something more!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Exactly.
However: do you agree there an app can be polished yet not feature complete?
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
Nope, but only b/c I an irritating bugger.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Self awareness is a virtue.
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
On the app, the client and the type of contract.
In most cases, you can get away with 1 month of delay if it is to incorporate critical features/demands that were omitted from the original proposition or to polish it enough to be usable (a rushed application might do more harm than good).
There's no such thing as a "bug-free" app. Best to have a really usable prototype with the most important functionality and without the kind of time-consuming bugs that can hamper further development. I would also suggest having some decent instrumentation: it's very important to have logs showing how some things are used and what types of error occur, and this is not something you can fix retroactively.
modified 6-Apr-21 21:01pm.
|
|
|
|
|
I agree that it depends on the kind of the project and contracts.
In general, people who use "systems" want all features, even if some of them crashes and then must open the application again (considering they don't lose all their data).
For games it is exactly the opposite. I really prefer a never stopping game with less features than a game full of features that keeps crashing.
So, my real opinion is:
For systems, it is to be on time and have all the needed functionalities.
For games, it is to be bug free and have a great look and feel.
Do you want to create a new programming language?
Do you want to know how to create a virtual machine?
Are at least interested on how they work?
So, see my article: POLAR
|
|
|
|
|
I chose bug free even though we all know it is impossible to have an app that is bug free and the reality is that we all end up releasing something that has a few minor known bugs.
On Time - If it has a few glaring bugs, it's not finished so even if you ship it "On Time" I still consider it late because the reality is you are still working on that release after your "shipped" it.
All Planned Features - I'd rather ship and receive a piece of software short a few features than one that is buggy. If the software is buggy I'm unlikely to want to continue using it.
Polished - Polish can go a long way to making an app feel better to the average user. Just look at Apple's success. For the most part they aren't doing anything all that amazing, but their products are polished (especially the hardware). That being said, if you polish a turd, you're still holding a turd.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
