View Single Post
Old 06-22-2010, 07:08 PM   #58
Kolenka
<Insert Wit Here>
Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.Kolenka ought to be getting tired of karma fortunes by now.
 
Kolenka's Avatar
 
Posts: 1,017
Karma: 1275899
Join Date: Jan 2008
Location: Puget Sound
Device: Kindle Oasis, Kobo Forma
Quote:
Originally Posted by Bremen Cole View Post
I agree. A percentage would also be consistent across platforms, as well as let you know about how much book you had left. As I always say, I just want the options. The more options, the more each person can customize and get what they want. With dead tree books there were not options, now we should have them....
There are a couple schools of thought about options and feature development.

One school says that every feature you do should be considered 'done' by the time you release it, and that includes all the polish expected of it. It should be something you only go back and change based on feedback or it needs an addition on it as part of another feature. Do the stuff with the biggest impact first, even if it means you leave out some users for awhile.

The other school says that you should get as many different features into the schedule as you can, in order to cater to the largest group of people possible. There is no reason the polish can't come in towards the end of the schedule once you have the "core feature-set" done and you are moving onto fixing all the bugs in the code.

Take a guess as to which camp Apple considers themselves to be in.

And there is nothing inherently wrong about either camp. You can do it terribly wrong both ways, and you an do it right both ways.

The catch with the first is that it is easy to create a product that carves out a niche and quickly dies if you are too laser focused on a bare bones feature set. The upside with the first is that your schedules are a bit more realistic in terms of features, when they will be properly debugged, and so on. So if the unexpected happens, perhaps you slip a few smaller features instead of slipping the release date, or worse, feeling like you don't have time to fix bugs before you have to ship.

The catch with the second is that it is easy to create a product that has a long feature list that can please anyone on paper, but once they have it, they realize it does none of them particularly well. These products tend to die off quickly because they are buggy, lack any sort of focus, and don't do anything in a way that sets them apart from the competition, they just do more of it. The upside here is that you are less likely to ship the product lacking in functionality. More people are willing to give it a try, which if you play your hand right, means you reach more people. If you can control the rough edges well enough, you can get a customer base willing to wait for the polish to come along.
Kolenka is offline   Reply With Quote