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

161–170 of 304 posts

Re: Good software knows when to stop

#161

Post by bigstrat2003 »

john_strinlai wrote: post #151
JackSlateur wrote: post #149

Earlier quoted context omitted.

So we are back to what I said earlier :p People do not want "classic": people want a "good" game that has some specific characteristics

> People do not want "classic": people want a "good" game that has some specific characteristics as long as those "specific characteristics" are literally and exactly what classic wow is, sure.

Kinda. I think people want "classic WoW" because they aren't able to articulate what, exactly, would need to change with WoW to make them happy again. But they can pretty easily paint to the old version and say "I liked that, bring that back". I think it's plausible that you could (with time and effort) design something that isn't the same as classic WoW while keeping the players happy.

Re: Good software knows when to stop

#163

Post by bigstrat2003 »

motoboi wrote: post #85

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

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

I think that people are just afraid that if they use a library in maintenance, they will run into a bug and it'll never get fixed. So they figure it's safer to adopt something undergoing further development, because then if there are issues they will get fixed. And of course, some people have to deal with compliance requirements which force them to only use software which is still updated.

Re: Good software knows when to stop

#164

Post by asukachikaru »

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…

Similar thing happened to Diablo II recently as well. Blizzard added a new class and couple of quality of life updates, after not touching it for over two decades other than the pretty authentic resurrected remake. Some of the QoL updates such as loot filter are very long overdue (integrated by competitors and have been asked by the community for years). Blizzard even sent surveys looking for player opinions about further updates for this 25 years old game. All these while D4, the one that should be their flagship product has its expansion announced. I believe there is something other than nostalgia that makes D2 superior than all successors. I don’t believe current Blizzard is capable of adding contents without breaking that authenticity though.

Re: Good software knows when to stop

#165

Post by erikpukinskis »

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…

It’s funny, Express.js tried this. 4.x was basically a complete piece of software. There weren’t any great reasons to change the API.

But people hated that. They considered it “unmaintained”. They moved to Koa and Hono because they appeared to be more “actively maintained”.

Re: Good software knows when to stop

#166

Post by antidamage »

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…

Runescape has a similar thing going on. What everyone's not understanding is not that improvements are bad, lots of the player base also want to see games evolve. It's just that a significant proportion of the audience also like The Old Thing and they're often more engaged as an audience in the first place.

You hear this story over and over about every kind of software.

There are two audiences every successful developer needs to cater to: the "I wish this did X, I want new features" side and the "I liked it the way it was" crowd and they're distinctly different groups.

For a long time I produced a popular technical art asset for video games and even I realised I needed to include every single version of the tool with every single installation. If a developer has to go and find out how to get "the right version" at all then I'm 90% likely about to lose a user.

Focusing on the "we did this right just keep going like that" and really understanding WHAT you did right and WHAT people like is really important. It's really hard to be impartial when you made the world rather than consumed it, but always take the win.

Re: Good software knows when to stop

#167

Post by ivanjermakov »

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…

I think it's common in libraries of small to medium size. I often see Haskell and Rust packages that are not updated because full functionality achieved, no bugs and 100% test coverage.

Absolutely not the case with enterprise software. Zawinski's law is truer than ever: https://news.ycombinator.com/item?id=20165602

Re: Good software knows when to stop

#168

Post by dcuthbertson »

latexr wrote: post #59
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 t…

There are few things so valuable as a good user who is willing to work with you. Many years ago I worked at a company that was going to shutdown a very buggy product. There was one user who relied on it heavily and convinced the CEO to make one more release, and I was tasked with working with that customer to make it happen. Over the next month, we fixed the bugs (I coded, he tested). We wound up making a stable and more user-friendly product. It was a real pleasure to work with that guy. The company still mothballs the thing, but I know we had at least one happy customer in the end.
Post reply on HN