Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Good software knows when to stop

ogirardot.writizzy.com

Post reply on HN
Print view View original

51–60 of 304 posts

Re: Good software knows when to stop

#51

Post by GolfPopper »

jasonlotito wrote: post #30
thewebguyd wrote: post #23

Earlier quoted context omitted.

To be fair on the Blizzard example, I think Blizzard could have also made the player base just as happy by, doing as your quote said, understanding the underlying problem. It wasn't only a "we want WoW classic bug for bug," it was "the modern game has become so unrecognizable that it's basically WoW 2.0, you ruined it with the modern systems" Blizzard could have rolled back LFR/LFG, class homogenization, brought back…

> Blizzard could have rolled back LFR/LFG, class homogenization, brought back complicated and unique talent trees, remove heirlooms, re-add group guests and world mini-bosses, remove flying, etc. and players likely would have been happy. 100% nope. Classic is what we wanted. All of what you just said is you saying: "you think you want that, but you dont. trust us, you dont want that."

Agreed. Current WoW has done some similar things to what the prior poster suggested, and while I personally find the current game better that it was for a while, it remains a very different experience from Classic.

Re: Good software knows when to stop

#52

Post by rutuhffhbb »

> ready to upgrade your favorite Linux distribution and packages to their latest versions

It is "their" distribution, to do with as they wish. If this would happen to your workstation, you are a fool, for not following release notes.

I already jumped distros for several reasons, marketing BS was one of them. I do not need latest scam or flag of the month!

Re: Good software knows when to stop

#53

Post by allemagne »

NoSalt wrote: post #7

We 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.

https://archiveprogram.github.com/arctic-vault/

Of course, any AI smart enough to apocalypse us would also know about these.

Re: Good software knows when to stop

#56

Post by john_strinlai »

manoDev wrote: post #24
john_strinlai wrote: post #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 thin…

That's reinforcing the author's point: the classic game already existed, users just wanted the same game with some maintenance updates - not a new game with new features. In this case it was the producers (not the users) that were wrong in wanting to throw away something that already worked. I believe his point isn't exactly about users not knowing what they want, but instead the tension between evolutionary design v…

>users just wanted the same game with some maintenance updates - not a new game with new features.

this is similar to the comment by treetalker, so i dont want to just copy/paste my reply to them, but focus on "add" vs. "remove" is sort of beside the point(s) i was trying to make.

Re: Good software knows when to stop

#57

Post by tambourine_man »

ssenssei wrote: post #11

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.

Spotify is a moving target, however. It may change its API, remove it completely, etc. I think you can only be truly done if you don’t rely on a third party.

Re: Good software knows when to stop

#58

Post by sfink »

john_strinlai wrote: post #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 thin…

Users usually don't know what they really want. But neither do developers or product managers. The "understand the underlying problem" part is hard, and easy to convince yourself of incorrectly.

There are also shallow wants and deeper wants. I don't have the experience to know, but my guess is that classic WoW was more of a shallow want, where people were very happy to get it, but the deeper want was more about a style and feel of gameplay. The players would be happier with new stuff that kept the magic of the classic game, but they justifiably knew they couldn't trust Blizzard not to add anything without messing it up. So the only practical way to satisfy the desire was to just roll back all the way to the classic version.

In a perfect world, some designer would come along and incorporate carefully selected bits and pieces of the new version, probably with some novel changes to balance it out, and end up with something superior to both classic and new WoW. But that would be really hard to get right, and distrusting players would fight it (with very good reasons for their suspicion), and you would have a giant mess of different people claiming that they know what to keep and what to discard, except nobody would agree on the same things, etc.

Re: Good software knows when to stop

#59

Post by latexr »

john_strinlai wrote: post #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 thin…

I have been in situations where a user makes a feature request and I don’t think it makes sense, but because they’ve been polite and understanding I decide to take the time to explain exactly why it wouldn’t work, but while doing so I basically rubber duck and come up with solutions to the problems I’m describing (which the user hasn’t foreseen yet). Sometimes that ends with me discovering yet even stronger reasons to not implement the feature, but other times it makes me delete the whole reply and work on it instead because I have worked it out. Sometimes doing so ends up taking less time than writing the full reply. Often the feature ends up being even better than what they originally requested.

In contrast, if a user has been rude, entitled, and high maintenance, I may end up not even trying to reply in the first place because I know they’ll just be combative every step of the way, and giving them what they want just makes them demand more, seldom being appreciative. These tend to be users who want something a very specific way and refuse to understand why the thing they are asking for is profoundly selfish and would shit the interaction for everyone else to satisfy their own desire. So I don’t do it.

This has been a bigger sidetrack than I originally intended. I guess the moral of the story is don’t be a prick to the people you’re asking something from.

Post reply on HN