I built a spotify music extractor called harmoni that helps you download your playlists and I feel I'm done. It does its job and it caters to both non-technicals and technical people alike.
Good software knows when to stop
11–20 of 304 posts
Re: Good software knows when to stop
#12>Ignore feature requests — don't build what users ask for; understand the underlying problem instead
not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game).
for years and years, the reply from blizzard was "you think you want that, but you dont. trust us, you dont want that."
they eventually caved and launched classic WoW to overwhelming success. some time later, in an interview, ion hazzikostas (the game director) and holly longdale (vice president & executive producer), admitted that they got WoW classic very wrong and that the people "really did know what they want".
anyways, point being that sometimes the person putting in the feature request knows exactly what they want and they have a good idea. while your default mode might be (and perhaps should be) to ignore feature requests, it is worth recognizing that you may be doing so at your own loss. after all, you might not not be able to fully understand every underlying problem of every user of your product -- but you might understand how to code the feature that they asked for.
Re: Good software knows when to stop
#13So uhm where can I get the 'als' command then? :P
Re: Good software knows when to stop
#14Earlier quoted context omitted.
Needs for actual survival and functionality do not out weigh needs for product manager promotions anymore.
The destructive forces (fire clearing deadwood) of the economy have been artificially suppressed for a long time. Most companies are zombie companies now. The US is an entire zombie economic zone.
[dead]
Re: Good software knows when to stop
#15"To order, to govern,
is to begin naming;
when names proliferate
it’s time to stop.
If you know when to stop
you’re in no danger."
Re: Good software knows when to stop
#16We need something similar to the Svalbard Global Seed Vault, to protect un-AI'd Linux distributions so that, in the event of an AI apocalypse, we will have access to clean operating systems.
[deleted]
Re: Good software knows when to stop
#17> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
Same with Old School RuneScape.
Jagex thought they knew better than the players what the game should look like, and overhauled the whole game to the point it was unrecognizable. It took a massive loss of paying members to get them to finally release 2007 version of RuneScape back.
Even now, OSRS has double the amount of players that RS3 has. Lol
Re: Good software knows when to stop
#18> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
This is a good point, though maybe means that "understanding the underlying problem" requires a degree of humanity.
I think it's fair to say that Blizzard at a certain point went corporate and "lost the plot", so they thought they knew what people wanted, even though they really didn't (don't you guys have phones?).
Re: Good software knows when to stop
#19> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
That's also a good case of the difference between a "Yeah, it'd be cool if you added this feature for free" type of feature request vs "I'm actively paying a company making a hack version of what I'd like from you - would you please let me pay you instead - for the love of god, please please please take my money?"
Re: Good software knows when to stop
#20> Ignore feature requests — don't build what users ask for; understand the underlying problem instead not quite in the same area, but this advice reminds me of blizzard and world of warcraft. for years and years, people requested a "classic" WoW (for non-players, the classic version is an almost bug-for-bug copy of the original 2004-2005 version of the game). for years and years, the reply from blizzard was "you thin…
I'm not a WoW player, so perhaps speaking out of turn — but doesn't that example show that users know what extra features they don't want, not extra features they do?