No, all software grows until it gets email. Jamie told me that.
I’m having flashbacks to the email client built into the Opera browser back in the day.
Good software knows when to stop
191–200 of 304 posts
Re: Good software knows when to stop
#192I think it’s always worth it to consider feature requests from your users. Other comments here reference video games. This is nothing like video games. Video games have arbitrary constraints anyway and should be carefully crafted to preserve the vision. If you don’t like it, make a new game.
Software’s constraints are not arbitrary, they are attached to specific use cases and any new feature that benefits any of those use cases should be considered.
The real issue is when these companies (especially VC backed) add new features and BS that no user has ever asked for. Features that exclusively benefit the company’s bottom line or support some quiet pivot to a new audience leaving everyone else to the curb.
Re: Good software knows when to stop
#193> 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…
Exception that proves the rule, IMO.
Re: Good software knows when to stop
#194We 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 the hard part is understanding if “finished” software is still maintained. I’ll pick on AppZapper here. It doesn’t need to do much, it’s a Mac app that finds the files related to an application and deletes them, for a complete uninstall. It released in 2006, with v2 coming out in 2010. The website looks like it’s still from that era and the last update was in 2020, almost 6 years ago. To be fair, it’s a cool…
What exactly is wrong with installing an abandoned product? Just because it's abandoned doesn't mean you can't use it.
Re: Good software knows when to stop
#195Earlier quoted context omitted.
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, ve…
> 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 [the new] version.
Re: Good software knows when to stop
#196> 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…
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…
> I think Blizzard could have also made the player base just as happy by [...] understanding the underlying problem.
I'm reminded of the 1995 interview in which Steve Jobs elucidated the fundamental reasons that Xerox missed its golden opportunity to own the computer industry and why former PepsiCo CEO John Sculley later ultimately failed at the helm of Apple.
It's fundamentally the same issue with a number of gaming conglomerates nowadays. These companies are more interested in increasing the sales of sugar water than making great games. Perhaps, then, it's not surprising in the least to learn that former Activision Blizzard boss Bobby Kotick was on the board of Coca-Cola for a decade.
Re: Good software knows when to stop
#197> 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…
Fortunately there's significant correlation between quality of communication and quality of ideas, so your approach might just be optimal!
Re: Good software knows when to stop
#198Earlier quoted context omitted.
I think the hard part is understanding if “finished” software is still maintained. I’ll pick on AppZapper here. It doesn’t need to do much, it’s a Mac app that finds the files related to an application and deletes them, for a complete uninstall. It released in 2006, with v2 coming out in 2010. The website looks like it’s still from that era and the last update was in 2020, almost 6 years ago. To be fair, it’s a cool…
What exactly is wrong with installing an abandoned product? Just because it's abandoned doesn't mean you can't use it.
I think the reasonable fear is that the product no longer works. Maybe Apple changed a required API in 2021 and poster would be purchasing a lemon.
Re: Good software knows when to stop
#199Rediscovering the Unix philosophy?
Re: Good software knows when to stop
#200We 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 remember the first time I experienced this was an iOS app called Task Eater. It was simple To-dos. Attractive, snappy, everything you could need. The dev released a "final update" where he basically declared it was done. This was pretty early iOS (iPhone 4 era?).
The only problem is he never updated it to roll forward to future iOS version/iPhone models and it hasn't been usable for years (and years).
This made me search it up - the world moves so fast it's difficult to find any information on it whatsoever.