Live data from Hacker News

Good software knows when to stop

ogirardot.writizzy.com

301–304 of 304 posts

Re: Good software knows when to stop

#301
post #82

> 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…

The "underlying problem" here, for Blizzard, is shareholder value, and they understand it well. The decision to dedicate developer resources to re-releasing old content is driven by careful assessment. In most cases it's probably driven by falling new player acquisition numbers, and so the equation switches to favoring player retention or luring back veteran players. Every profile of player has their own preferences…

[dead]

Re: Good software knows when to stop

#302
post #93
post #87

Earlier quoted context omitted.

Yea, good old days :) The catch was that old boxed software eventually breaks on new OS versions or devices. However, SaaS has the potential to "freeze" features while remaining functional 20+ years down the road. Behind the scenes, developers can update server dependencies and push minor fixes to ensure compatibility with new browsers and screen sizes. From the end-user's perspective, the product remains unchanged a…

My experience is actually the opposite. In the old days there was no expection when and if users would upgrade anything , so vendors had to take extra care to ensure compatibility or they would lose business. People in a single office could be running 6 different versions of Microsoft Office, and the same file had to be viewable and editable on all of them. A company could decide to upgrade to Office 2010 but stay on…

[dead]

Re: Good software knows when to stop

#303
post #47

We should normalize "finished" software products that stop feature creep and focus strictly on bug fixes and security updates. It takes real courage for a builder to say, "It’s good enough. It’s complete. It serves the core use cases well." If people want more features? Great, make it a separate product under a new brand. Evernote and Dropbox were perfect in 2012. Adding more features just to chase new user growth of…

Dropbox is a great example. It's now a fundamentally different product than the original, and has re-created exactly the problem the original solved. There's no longer a good cloud-synced folder tool; everybody has gone back to implementing network filesystems that are much more complex and a badly leaky abstraction.

[dead]

Re: Good software knows when to stop

#304
post #93

Earlier quoted context omitted.

My experience is actually the opposite. In the old days there was no expection when and if users would upgrade anything , so vendors had to take extra care to ensure compatibility or they would lose business. People in a single office could be running 6 different versions of Microsoft Office, and the same file had to be viewable and editable on all of them. A company could decide to upgrade to Office 2010 but stay on…

Which resulted in businesses holding on to extremely old software and OSs because migration to the latest system was expensive and difficult. Now it's effortless.

It's not effortless for all the end users who have adapt to the UI changing on them all the time.
Post reply on HN