A couple weeks ago, they decided to pull the feature because it was too confusing and it wasn’t adding value.
This is wrong. If the feature weren't adding value, the users wouldn't care if it disappeared. In this case, it added the value of allowing a family to have separate queues and ratings with a single account. Whether Netflix was able to capitalize on that value is another story...
I think this is like when Joel S talked about the problem with the 80/20 rule - sure, most users only use 20% of the features, but they are a different 20% for each user.
37s and others don't seem to agree with this, and want to have a pure 20% - and claim that the interfaces that result with Joel's way are "enterprisey" (a term I have heard a lot to describe anything which isn't consumer level simple).
Well, no. I think the point of the blog post was that adding features is expensive (more so than the simple development costs) and that adding needless features is incurring needless expense. That much is spot on.
The problem was that, as reality demonstrated, a "needless" feature is something that is very much in the eye of the beholder. Some folks really loved this gadget, apparently (I know zilch about the whole affair). So maybe it's a poor example of an otherwise valid point.
with 82M subscribers, 82-164K using this feature, and 1286 comments -- a large majority of the userbase was getting no value out of it, while a small proportion was.... it's not so easy to define 'value' in a scenario like this.
Another good example of this is in microprocessor architecture.
A long time ago instructions were added to the x86 architecture to make life easier for assembly programmers. These instructions are large and take many clock cycles to execute.
Today since most people don't code in assembly and because modern processors have longer pipelines these instructions are rarely used. However Intel and AMD still have to support them on every x86 chip to maintain backwards compatibility despite the fact that they aren't adding much "value".
I'm not sure how much of an issue that really is. A modern x86 processor is a decoder for the x86 instruction set in front of a RISC core to do the actual work. x86 instructions are not directly executed anymore. So long as it's efficient instructions by the time it reaches the core, who really cares how many cycles it took on the original hardware?
Whatever you do, some subset of your users will moan. You need to see what sort of % of your userbase is pissed, see if you can please everyone (User prefs or something) etc
This post seems more like an excuse as to why some products have hardly any features to me.
Like others have said, I think 37s just wants another chance to say "don't add features". This is old advice by now, though it's still good advice to take, depending on what you would otherwise do. Some web apps these days might actually take it too far.
Also, as I've read others complaining about, 37s seems to treat bugfixes and features similarly. I used Backpack for a while and am still slightly bitter that I couldn't put snippets of code in notes. I forget the details, but their handling of angle-brackets in code did something obviously wrong, like double-escaping, and I wasn't able to get anyone there to even understand the problem.
Basically, it's like stone carving--you can shape the stone, but once you've made a dent, you can't put the chips back without restarting. If you have severely invested into some really boneheaded design choices, the best way out might actually be to spawn a sub-company, have it create a "lightweight competitor" to your own product (designing it the correct way) and then merge the company back in, throwing away your product and using its.
Thinking about it, I'm surprised Microsoft doesn't do this.
This is wrong. If the feature weren't adding value, the users wouldn't care if it disappeared. In this case, it added the value of allowing a family to have separate queues and ratings with a single account. Whether Netflix was able to capitalize on that value is another story...