Live data from Hacker News

Good software knows when to stop

ogirardot.writizzy.com

221–230 of 304 posts

Re: Good software knows when to stop

#221
in enterprise none of this tends to hold true at all. you need to balance the optics of what people think they need vs what they actually need.

a lot of times people with "we MUST have features XYZ to buy" and then when they actually get set up you see they use only 50% or less of the features. was it useless to build them? they wouldn't even consider you in the first place if you didn't tick the boxes for some higher up decision maker.

probably applies more to people who are already bought in. you have that "luxury" at that point, buy in, cost to switch, etc.

Re: Good software knows when to stop

#222

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

Well to me it sounded like they followed the first part (ignore feature requests) and failed at the second part.

Just build the feature is the wrong lesson to learn. The right lesson is to expend more effort to understand; and yes, part of that _could_ involve shipping the feature in order to get data/feedback.

Re: Good software knows when to stop

#223
This reminds me of a line from REAMDE that I'll never forget.

"Writers like having residences."

The backstory is they hire two writers-in-residence, who keep making more work and excuses for more work for themselves... so they can continue having a residence.

The same is true for writers of code, it turns out. So we bit twiddlers sometimes gin up excuses to change things, so we have an excuse to be employed and having a residence.

Re: Good software knows when to stop

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

I wrote my comment before I read yours, but it perfectly explains why software doesn't do that. Sadly I can't take credit for the core idea: https://news.ycombinator.com/item?id=47272024

Re: Good software knows when to stop

#225

This reminds me of a line from REAMDE that I'll never forget. "Writers like having residences." The backstory is they hire two writers-in-residence, who keep making more work and excuses for more work for themselves... so they can continue having a residence. The same is true for writers of code, it turns out. So we bit twiddlers sometimes gin up excuses to change things, so we have an excuse to be employed and havin…

"We must make a full rewrite of our codebase to X architecture / Y language".

How many times I've heard that...

Re: Good software knows when to stop

#226
post #58

Earlier quoted context omitted.

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

> 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, [...] > In a perfect world, some designer would come along and incorporate carefully selected bits and pieces of the new version,…

> but players actually, really, 100% truthfully, no exaggeration, wanted classic WoW. not retail WoW with some classic-feeling bits. they wanted (basically) bug-for-bug classic.

You're speaking in the same manner of absolutes like most gamers tend to speak on discussion forums. It makes you unbelievable tbh.

Get this: The playerbase for retail is still larger than classic. And those who advocate world PVP have their servers eventually trend towards one faction. These are the just effects of the vocal minority. It doesn't mean the vocal minority are right for all instances. Just that the incentives lined up.

Re: Good software knows when to stop

#227

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

Speaking of classic WoW... found this gem recently where a guy talks about his experience playing classic in 2026 without any nostalgia: https://www.youtube.com/watch?v=NjQgoaagS-E TLDR classic is pretty damn good!

Re: Good software knows when to stop

#228

> 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 got out of my WoW addiction, but I think in this case "Classic" was people asking specifically for LESS features in their game

And the people owning the product were convinced players wanted more features.

Re: Good software knows when to stop

#229
post #194

Earlier quoted context omitted.

What exactly is wrong with installing an abandoned product? Just because it's abandoned doesn't mean you can't use it.

Apple tends to expect a lot from its developers. Changing processor architectures is a big one. Unlike other platforms, Apple cuts support and moves on. If an app is abandoned, it starts to show sooner on Apple platforms than anywhere else. If it’s something that will become critical to a user’s workflow, that can be a big problem. Why invest in an app without a future?

I prefer the perspective that a computer program is akin to a mathematical constant. This was true in the old days. A program I wrote in C64 BASIC, way back in 1980s, should still work precisely the same today (even on one of the freshly-manufactured Commodore 64 Ultimates).

You've honed right in on what's changed since the old days: Platform vendors (such as Apple) now continuously inject instability into everything.

You might argue that developments such as "changing processor architectures" justify such breaks from stability (though I myself have qualms with one of the richest companies in the world having a general policy of "cutting support and moving on"). But I would point out that Apple (and other vendors) create instability far beyond such potentially-justifiable examples.

To me, it appears as if Apple actively works to foster this modern "software is never finished" culture. This is seen perhaps most clearly by they way they remove apps from their iOS store if they haven't been updated recently (even as little as 2 years!): https://daringfireball.net/linked/2022/04/27/apple-older-gam...

Shouldn't we be demanding stability from our platforms? Isn't the concept of "finished software" a beautiful one? Imagine if you could write a useful program once, leave it alone for 40 years, and then come back to it, and find that it's still just as useful. Isn't this one of the most valuable potential benefits of software as a premise? Are the things we're trading this for worth it?

Re: Good software knows when to stop

#230
Good software isn’t always „software that makes money”.

Of course it is important to do stuff that doesn’t make money.

But if your goal is to make money you need software that people will pay for and people will use 20% of features but each one person will use different 20% of the features.

Post reply on HN