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

81–90 of 304 posts

Re: Good software knows when to stop

#81

Post by thewebguyd »

bigstrat2003 wrote: post #71
lemagedurage wrote: post #62

Earlier quoted context omitted.

We shouldn't discount nostalgia. Sometimes an otherwise objectively worse product is better because it reminds people of the past.

But there are people who didn't play WoW back in the day who still love classic, so it can't just be nostalgia. Vanilla WoW really did have a different design ethos than the later expansions did, and some people prefer that experience.

> Vanilla WoW really did have a different design ethos than the later expansions did, and some people prefer that experience.

Right, and that's my point. When you take away the nostalgia for the content, you reveal what players are asking for, which is a reversion to what is effectively a previous game as modern WoW lost all of what made it a good game, to those players, in the first place.

So yeah, there was definitely a group of players that literally did want Classic WoW, original content and all, but I also feel like Blizzard would have saw success continuing that Classic formula with new content. Blizzard sucked the soul and charm out of WoW. For all intents and purposes, modern WoW is a completely different game.

Re: Good software knows when to stop

#82

Post by pphysch »

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…

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 (some just want to see big boob textures, etc.) but that doesn't mean they are driving product decisions, except in the case that this demographic becomes core to the business model. But it has nothing to do with the particular preference.

Re: Good software knows when to stop

#83

Post by grim_io »

IncandescentGas wrote: post #76
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…

The counter-example, in classic MMO terms, is Ultima Online adding non-PVP game instances in response to player feedback. Without the dramatic threat of PVP conflict at most times, UO was less emotionally engaging. The non-PVP players were bored without the emotional excitement (stress, danger, whatever) of ad hoc PVP. The PVP-focused players were bored when all the reputational mechanics became more or less meaningl…

Arc Raiders and other involuntary pvp games will miss out on players like me who will not try it until pvp is optional and voluntary.

Involuntary pvp is the long term death sentence for a game. It punishes new players by making them easy prey for veteran players. Player numbers will fall hard and fast, like every other involuntary pvp game does.

Re: Good software knows when to stop

#84

Post by lithobraking »

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…

On this note, I'm seeing this pattern crop up in retail WoW addons. (It's maybe an even more literal interpenetration of the title.) Many of the newer addons are heavy vibe-coded due to last-minute WoW API changes, like ArcUI.

The addons have _so_ many ways to customize displays that their configuration menus look like lovecraftian B2B products with endless lists of fields, sliders, and dropdowns. I hear a lot of complaints from raiders in my guild about how hard it is to put together a decently functional UI. I wonder if these tools are allowing and/or causing devs to more easily feature creep the software that we build.

Re: Good software knows when to stop

#85

Post by motoboi »

In 2020 I became a full time Java developer, coming from a infrastructure role where I kind of dealt with Java code, but always as artifacts I managed in application servers and whatnot.

So when I first started dealing with the actual code, it scared me that the standard json library was basically in maintenance mode for some years back then. The standard unit test framework and lot of other key pieces too.

I interpreted that as “Java is dying”. But 6 years later I understand: they were are feature complete. And fast as hell, and god knows how many corner cases covered. They were in problem-solved, 1-in-a-billion-edge-cases-covered feature complete state.

Not abandoned or neglected, patches are incorpored in days or hours. Just… stable.

All is quiet now, they are used by millions, but remain stable. Not perfect, but their defects dependable by many. Their known bugs now features.

But it seems that no one truly want that. We want the shiny things. We wrote the same frameworks in Java, then python the go then node the JavaScript the typescript.

There must be something inherently human about changing and rewriting things.

There is indeed change in the Java ecosystem, but people just choose another name and move on. JUnit, the battle tested unit testing framework, had a lot to learn from new ways of doing, like pytest. Instead of perturbing the stableness, they just choose another name, JUnit5 and moved on.

Re: Good software knows when to stop

#86

Post by thewebguyd »

bigstrat2003 wrote: post #75
john_strinlai wrote: post #46

Earlier quoted context omitted.

that distinction sort of misses the point i was trying to make. sometimes users want something . that something might be a feature request, or it might be a feature removal. it doesnt really matter for the sake of my point(s): a) ignoring your users requests can sometimes be a bad choice. b) you might not necessarily understand every underlying problem that every user has. worse, you might think you understand the pr…

Sid Meier has talked about something similar: he likes to tell designers at Firaxis that "feedback is fact". That is, no matter how strongly you (the designer) believe that something is a good design, if the player says "this isn't fun" then that needs to be taken as the gospel truth. The players might not be able to explain why it isn't fun, and you might be able to tweak the design to make it fun, but what you can'…

Blizzard did the same exact thing with Diablo 4 too, and D3 also famously sucked at release.

You'd think they would have learned by now, as they repeat the same exact mistakes over and over again. It's like they hate their playerbase.

Re: Good software knows when to stop

#87

Post by wenbin »

paxys wrote: post #78
wenbin wrote: 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…

You are basically describing all software ever shipped before webapps and online updates became a thing. Companies wrote software and sold them in boxes. You paid once and it was yours forever. You got exactly what was in the box, no more and no less. The company then shipped a new verson in a different box 1-3 years later. If you liked it enough, and wanted the new features, you bought the new box.

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 and reliable. To me, that’s very good!

Re: Good software knows when to stop

#88

Post by john_strinlai »

lithobraking wrote: post #84
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…

On this note, I'm seeing this pattern crop up in retail WoW addons. (It's maybe an even more literal interpenetration of the title.) Many of the newer addons are heavy vibe-coded due to last-minute WoW API changes, like ArcUI. The addons have _so_ many ways to customize displays that their configuration menus look like lovecraftian B2B products with endless lists of fields, sliders, and dropdowns. I hear a lot of com…

the sudden influx of low quality UI addons has certainly been interesting to watch!

but, i dont think it is really an ai problem in this specific case. the biggest addons in wow have been like that since way before ai was a thing (elvui, weakauras, plater, etc.). they all have a thousand settings.

and, to be honest, in the specific case of WoW, i am totally fine with it. i dont want 10 different addons to change how my UI looks. i want 1 addon to do it. and there is just so much stuff to edit that of course you are going to end up with a thousand settings.

Re: Good software knows when to stop

#89

Post by thewebguyd »

paxys wrote: post #78
wenbin wrote: 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…

You are basically describing all software ever shipped before webapps and online updates became a thing. Companies wrote software and sold them in boxes. You paid once and it was yours forever. You got exactly what was in the box, no more and no less. The company then shipped a new verson in a different box 1-3 years later. If you liked it enough, and wanted the new features, you bought the new box.

And people liked that model, see the huge backlash when Adobe went subscription for creative suite.

I do wedding photography as a side hustle, I upgrade my camera maybe once every ~7 years. Cameras have largely been good enough since 2016 and the 5D Mark IV. I have a pair of R6 mk II that I'll probably hold onto for the next 10 years.

Point being, Lightroom has more or less been feature complete for me for a very, very long time. For about the price of 1/year subscription, I could have purchased a fixed version of Lightroom with support for my camera and not had to buy it again for another 10 years.

We are getting milked for every nickle and dime for no reason other than shareholder value.

It actually discourages real improvements. Before the subscription model, if Adobe wanted to sell me another copy of Lightroom they had to work really hard to make useful features that people actually wanted, enough to the point they'd buy thew version.

Now, they don't have to. You have to keep paying no matter what they decide to do.

Re: Good software knows when to stop

#90

Post by keerthiko »

grim_io wrote: post #83
IncandescentGas wrote: post #76

Earlier quoted context omitted.

The counter-example, in classic MMO terms, is Ultima Online adding non-PVP game instances in response to player feedback. Without the dramatic threat of PVP conflict at most times, UO was less emotionally engaging. The non-PVP players were bored without the emotional excitement (stress, danger, whatever) of ad hoc PVP. The PVP-focused players were bored when all the reputational mechanics became more or less meaningl…

Arc Raiders and other involuntary pvp games will miss out on players like me who will not try it until pvp is optional and voluntary. Involuntary pvp is the long term death sentence for a game. It punishes new players by making them easy prey for veteran players. Player numbers will fall hard and fast, like every other involuntary pvp game does.

"I may play your game if you trim away a core appeal factor for the people who already play your game by splitting the active player base" is not that convincing a feature request to a gamedev.

Many live service games that are punishing for new players are still thriving like LoL and DOTA2. Much that punish-factor can be resolved by good matchmaking, putting new players mostly with each other.

Post reply on HN