Live data from Hacker News

Users hate change

gist.github.com

281–290 of 315 posts

Re: Users hate change

#281
I had a very jarring experience a few months ago with pocket casts. I had bought the app on play store a long time ago to listen to podcasts in my car. I had it set up to auto download my podcasts and certain other automations.

I get into my car in the morning, put my phone into a clamp, open the app and it plays through my car Bluetooth.

One morning I was in a hurry to leave because I was running a bit late. I open the app and it's like a completely new app! Nothing was left unchanged. My download and automation settings were either reset or those features had been removed. The app now looked like some design interns over-zealous first attempt.

I gave up and turned on the radio. Until this day I haven't been able to set it back up exactly like I had it before. And this is an app I paid for. It was very cheap, sure, but still.

Re: Users hate change

#282

My pet theory is that every software product has a "peak version". Before that peak version, the product is not yet in a complete state, and it is fairly obvious, both for the developer and user, what features are missing. Once the peak version is reached, new features are not added because they improve the product, but to justify selling the product again to existing customers, and to 'keep the team busy'. Instead o…

> the product's feature set is frozen at the "peak version"

And then youa add a plugin and extensions API, so people can continue adding features, without annoying anyone — although the product is "frozen".

Isn't browser like FF and Chrome an ok example of this b.t.w.?

Re: Users hate change

#283

Earlier quoted context omitted.

Honestly? Because no software is free from bugs and there will always be a need for support. The difference between single sale and subscription can be life or death for a company, its products, and its support. But if you don't feel that a subscription to a service adds value, please don't buy it and voice your concern to the developers. Especially if they're a small shop. That said, subscriptions can be canceled. F…

Then charge for bug fixes. Charge for updates that make the application run on a new version of the OS. If those things provide sufficient value, users will pay for them. I've been paying for that for decades for my commercial text editor. And can subscriptions be canceled in practice? If you cancel your Photoshop subscription, your documents suddenly become unopenable. In this way, software subscriptions—at least fo…

Charging for bug fixes can also be seen as protection money: "Nice security holes you've got there, it'd would be a shame if anyone were to abuse them."

And no software vendor would like to categorize bugs as security related or not, or maintain and test all combinations of old releases plus security patches applied. The easiest is if all customers stay on top of tree.

Re: Users hate change

#284
post #29

Earlier quoted context omitted.

The solution is that every deployable version of the service should be usable on it's own and users should be able to chose exactly what version they are locked on to. Or they can choose to live on bleeding-edge and always get the latest updates. Wishful thinking maybe

That was feasible in a world where every computer was air-gapped because there was no such thing as the Internet. Now every app needs to stay up to date for security reasons, even if it doesn't directly use the internet itself.

This constant stay on latest and cross your fingers mentality has to go if we ever are to have more stable releases and interfaces (both UI and APIs) again.

Average app developer is clearly not trustable for keepimg a whole system secure (Zoom for a recent example). We have to go back to air gapping but do it on app and even internal component level instead of whole machine. Sandboxing and containers is the only way forward.

Re: Users hate change

#285

Earlier quoted context omitted.

I agree with your examples but I think a piece of software is different because users expect it to change over time. New Mac OS version? Users want to support it. Found a bug in a library uses? Users expect to get a fixed version etc. And while as a software user/buyer myself I like the idea of paying once and be done with it I kinda understand why people need recurring income if they keep on working on a piece of so…

>users expect it to change over time No, they expect to have the opportunity to upgrade to newer versions which may be different if they want those differences. They don't expect the one they bought, learned to use, and have grown proficient with to suddenly be completely different one day for no good reason. Consider buying a truck because you haul stuff around a lot. You don't expect to just come out to your drivew…

Your example is not addressing the point the parent made. Users definitely expect free updates to new OS versions with all the bells and whistles this version supports. They also definitely expect bugfixes. Nobody mentioned changing design here.

I can guarantee you that inboxes of all iOS developers who have not implemented dark mode will fill up the first day iOS 13 is released to public.

Heck, people expect your app to work on the first beta and will complain if it does not.

Re: Users hate change

#286

Earlier quoted context omitted.

I agree with your examples but I think a piece of software is different because users expect it to change over time. New Mac OS version? Users want to support it. Found a bug in a library uses? Users expect to get a fixed version etc. And while as a software user/buyer myself I like the idea of paying once and be done with it I kinda understand why people need recurring income if they keep on working on a piece of so…

>> New Mac OS version? I have been avoiding the available OS update for my Macbook Air because I've heard it kills performance, reduces battery life, may not run one of my favorite applications, and AFAIK brings nothing that I actually want.

YMMV but to me Mojave works way better than High Sierra on my 2009 MBP

Re: Users hate change

#287
post #210

Earlier quoted context omitted.

This is a bit naive. Software and especially apps these days are more a stream of updates (like Netflix) than a v1.0 you buy once. Updates are expected from users (and app stores). Example: A customer bought your app on iOS 9. It worked perfectly fine. You wrote it once, because you couldn’t expect more revenue from existing customers. It stopped working on iOS 11, because 32-bit support was ended on Apple’s side. Of…

Software bought for iOS should work on iOS. Forever. What you're glossing over here is that for literally decades, that was a pretty good baseline assumption, because we actually valued backward compatibility. The lengths that Microsoft went to in order to maintain that compatibility in the first several major releases of Windows are legendary. The lengths that Linux developers still go to are also remarkable. It's o…

Windows has great backwards compatibility but at the cost of acxumulating legendary amount of cruft. It also means that if you develop new entreprise software you have to use ancient frameworks.

On Linux retrocompatibility is handled at the source code level. So stuff will work as long as you are ready to compile your own old versions of all libs in a chroot somewhere. Trying to run even a few months old binary will often fail.

Mac is similar to Linux but the burden of recompiling is on the developers. Many applications ship an old version that you can run on some Eldritch version of macos.

If you introduce a cloud component everything breaks unless you are ready to support multiple versions of your DB.

No wonder so many entreprise devs fled to evergreen web apps.

Retrocompatibility was a given because it was relatively easy.

Re: Users hate change

#288
post #210

Earlier quoted context omitted.

This is a bit naive. Software and especially apps these days are more a stream of updates (like Netflix) than a v1.0 you buy once. Updates are expected from users (and app stores). Example: A customer bought your app on iOS 9. It worked perfectly fine. You wrote it once, because you couldn’t expect more revenue from existing customers. It stopped working on iOS 11, because 32-bit support was ended on Apple’s side. Of…

Software bought for iOS should work on iOS. Forever. What you're glossing over here is that for literally decades, that was a pretty good baseline assumption, because we actually valued backward compatibility. The lengths that Microsoft went to in order to maintain that compatibility in the first several major releases of Windows are legendary. The lengths that Linux developers still go to are also remarkable. It's o…

Fair enough. There’s obviously software that goes back decades and we all benefit from the great backwards compatibility of MS or Linux.

But: How useful is your copy of Windows 98 these days? Can you collaborate with others with your copy of Photoshop 5.0 or Office 2003? Can you easily install Quake I on a modern machine without hassle?

> Ask yourself this...

It depends. I see your point and you are right to a certain extend. But then I see lots of people asking for new features or are glad about new capabilities the app now offers. I’d say it depends a lot on the type of software.

> competition is no longer an effective protector of the customer's best interests.

Why? You still get to buy some software or use your iPhone 3GS. It’s just a security thing. Or did you expect free updates to your OS?

The buy-once-use-forever software doesn’t really work, because software is rarely isolated like some Linux CLI tools from the 80s. You need to have security updates or collaborate with people by sharing files. Someone wantsnew features and change, others don’t. At least under the new model, you get to use software for a low price if you don’t use it that much (Adobe cloud is what, 10 bucks a month compares to 600 upfront?).

Re: Users hate change

#289
post #210

Earlier quoted context omitted.

This is a bit naive. Software and especially apps these days are more a stream of updates (like Netflix) than a v1.0 you buy once. Updates are expected from users (and app stores). Example: A customer bought your app on iOS 9. It worked perfectly fine. You wrote it once, because you couldn’t expect more revenue from existing customers. It stopped working on iOS 11, because 32-bit support was ended on Apple’s side. Of…

What's wrong with charging for upgrades? I buy a computer with Mac 9 and some programs, and when I want Mac 10. I buy upgrades.

Is that true? I bet you wouldn’t – or most people wouldn’t. The OS for them is an intangible thing. Your app/software is what gets the blame if it doesn’t work in a new environment. No way average Joe pays again for the same product he bought before, just because he now as Mac 10 now instead of 9.

Re: Users hate change

#290

Earlier quoted context omitted.

I like the jetbrains model. You can always stop paying whenever you want and you get to own whatever last version you hold.

That's not exactly how the JetBrains perpetual fallback license works. You don't get a license for the last version you used under your subscription. You get a license for the version you had 12 months before you ended your subscription. If you buy an annual subscription, you are paying for 12 months up front, so you immediately get a fallback license for the version that is available at the time you start or renew t…

I hate JetBrains and regret ever having supported them. About 70% of that is due to this policy.
Post reply on HN