Don't forget the lifetime support subscription you bought for "ls" 2 years ago. It turns out the lifetime is for the lifetime of the software, not your lifetime.
Good software knows when to stop
91–100 of 304 posts
Re: Good software knows when to stop
#92> 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…
A variant of the first is the highly imaginative user who keeps coming up with new variations or expansions of their idea. It’s not malicious but it can be exhausting.
Especially if you try to address their core need but their imagination doesn’t extend quite far enough to see how your effort would help, because they love their ideas.
Re: Good software knows when to stop
#93Earlier 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.
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 Windows XP, so the Office division had the finanical incentive to ensure that newer versions would work on an older OS.
Nowadays the standard is "you must be on the newest version of everything all the time, or the app won't work". Don't want to upgrade to Win 11? Want to use Firefox instead of Chrome? Don't want all the bells and whistles that come with the newest version of the software? Too bad.
Re: Good software knows when to stop
#94> 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…
But they didn't actually build WoW classic. They just built another version of the game. Gameplay wise it is drastically different.
Economics & business wise it is very simple while it is popular: monetization.
Re: Good software knows when to stop
#95Good software doesn't get you VC funding.
As if VC funding is a good thing. Good software is made by individual people, nonprofits, or privately-owned entities.
Sometimes you need to pay the people who made the software. You can't steal during all your life. At some point you have to pay the others for the work they did.
Re: Good software knows when to stop
#96This is an article Microsoft Windows, Office, Outlook and MS Teams developers and product managers should read, they continually break the working software only to come back regularly to what they have invented already, in the meantime annoying many who had to experience the experiments in between…
Re: Good software knows when to stop
#97We 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…
This is one of the biggest issues in software development: So few projects are willing to admit that they are finished. I can probably count on one hand how many software products I use every day that actually get better (or stay the same) on update. The vast majority of them peaked somewhere around v1.0, and are just getting worse every time the developer touches them.
I can understand the incentives for professional software. If you admit the software is done then management will question why they need you anymore.
For OSS it’s more psychological: admitting you’re feature complete is cutting off the dopamine hit of building new things.
Re: Good software knows when to stop
#98Link this to the Spotify product developers
I dislike spotify but weirdly enough I can never point out exactly what's so frustrating about it...
App is slow. It plays music video content as default. Gui has many non interesting parts. I just want a list of albums and songs.
I guess I just want it to be "boring but functional. :)
Re: Good software knows when to stop
#99> 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…
Same with Old School RuneScape. Jagex thought they knew better than the players what the game should look like, and overhauled the whole game to the point it was unrecognizable. It took a massive loss of paying members to get them to finally release 2007 version of RuneScape back. Even now, OSRS has double the amount of players that RS3 has. Lol
This isn't even true. OSRS was on life support with very few players for years until they started giving it updates.
Turns out the 2007 version of the game was ROUGH for a lot of reasons - they picked the time because, IIRC, it was the most complete backup they had.
OSRS has now had nearly a decade of consistent updates, a large team, and typically 10x the online player count of the "modern" game. The catch is that OSRS is not the 2007 version of the game, it's an alternative update timeline which broke off at the 2007 version of the game.
Re: Good software knows when to stop
#100Earlier 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.
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…
SaaS has that potential but the reality is more often that the vendor gets acquired, or they just decide to stop supporting it, and shut it down. You have no options to keep running what you had, only to migrate to a replacement, which is likely another SaaS which will do the same thing.