Hacker News Reader

> The worst idea ever in technology is regularly scheduled updates. Innovation has never and will never happen on a schedule. This is simply greed-driven, promotion-driven, pointy-haired-boss-driven development.

this is sort of uncharitable. the development/maintenance cycle for software is incompatible with the traditional way of monetizing a product (ie, design it up front, manufacture at scale, and then the buyer gets what they get, barring severe safety defects). buyers of software expect the product to at least mostly work in the first place, but they also expect bugs to continue to be fixed after the sale, even if the bugs are introduced through unforeseeable interactions with other software.

imo, subscriptions are actually the ideal way of aligning incentives for products that involve ongoing maintenance. but buyers tend to consider this a ripoff if they don't actually see a stream of new features in development. while it introduces some unfortunate constraints in the dev cycle, bundling up features in a scheduled update is a good way to make it visible to users that their subscription dollars aren't just falling into a black hole. trickling out new features "when they're done" earns the respect of engineers, but results in the average user simply not noticing that progress is being made.

> buyers of software expect the product to at least mostly work in the first place, but they also expect bugs to continue to be fixed after the sale,

Contrast that to traditional physical goods, where buyers expect the product to work as advertised, right out of the box, or their money back. Software in the Internet era has it easy, because it gets to release shitty half-finished versions, and then keep charging money while never quite finishing the software.

> subscriptions are actually the ideal way of aligning incentives for products that involve ongoing maintenance. but buyers tend to consider this a ripoff if they don't actually see a stream of new features in development

Because software does not decay on its own (despite the misleading term "bitrot" being popular in tech circles). That's literally why digitizing data has taken the world by storm: digital data does not decay; as long as the physical medium is readable, you can make a perfect copy of the data it contains. As a buyer, I don't expect my software to need maintenance. I expect it to work out of the box (just like I expect every physical product to work out of the box), and once I find software that fulfills my needs, I expect it to work all the way until computing technology moves forward so much that it's no longer possible to run the software. Which, in the era of virtual machines, may take decades.

So yeah, there's a need to clearly justify to the customers why you're charging subscription, because software in its natural state does not need maintenance.

>As a buyer, I don't expect my software to need maintenance. I expect it to work out of the box (just like I expect every physical product to work out of the box)

Software is far more complex than most physical products. There are only so many failure modes for a screwdriver or a couch and they're all pretty foreseeable. The most complicated physical systems, like a car, house, or even a human body, do need maintenance.

I'm frequently frustrated with software bugs like everyone else (my building and apartment have this awful smartlock system that's riddled with bugs and which bricked me out of my own home due to a bad app update a few weeks ago--shoutout to Latch) but I'm not sure I'm on aboard with an anti-maintenance attitude. If there are bugs I'd like them to be fixed!

> I'm not sure I'm on aboard with an anti-maintenance attitude. If there are bugs I'd like them to be fixed!

Me too! I'm not trying to be anti-maintenance (though I do wish technology will be developing towards less and maintenance required, but that's another topic). I'm pro-quality. The impression I'm having is that maintenance burden on software is being created in order to justify subscription model - and that the ability to do post-release updates made vendors and devs no longer care about delivering reliable and quality software (customers become the new QA, bugfixes can always be added latter, except they tend to be deprioritized in favor of new features).

Note I'm not postulating a conspiracy theory, just a spontaneous coordination of the entire industry due to market incentives. But the effect is still there, and I feel it needs to be countered.

> Because software does not decay on its own (despite the misleading term "bitrot" being popular in tech circles).

in theory yes, in practice no. I work on a product that targets windows and macos. on windows yeah, a version of our software from 2015 probably works as well as it did the day it was released. apple deprecates stuff in their API every year that we have to go back and update. they also break a lot of stuff that isn't formally deprecated and we have to find workarounds for that to. "our software will work forever as long as you never update your OS" is not acceptable to most customers.

Sure, but until quite recently, OSes were not updated at such breakneck pace. At this point we're hitting what can be seen as industry-wide, self-justifying scam: software needs subscriptions because it's being continuously updated; it's being continuously updated in big part because every other software is being continuously updated.

Still, as a Linux and Windows user, I've absolutely grown to expect my desktop software to work 10 years or more without updates. After that, I can always spin up a VM with an older Windows version.

I find that what causes SW to break most often is changes to the OS, either other app updates or OS updates.

I work in a hardware company, and for any important function I usually set up a dedicated computer, install the software, and then never touch it ever

This is how the more sophisticated oscilliscopes etc. work. They often have Windows XP installed if you buy them used. Simple, doesn't break, no internet, if it's mission critical or expensive it's worth a dedicated and frozen computer

> they also expect bugs to continue to be fixed after the sale

I wasn't disagreeing with that. I mentioned "long periods of stability and refinement" — refinement including bug fixes — and "any issues with the new technology need to be resolved". But again, bug fixes don't magically happen on a schedule either. Maybe fixes are easy, maybe they're hard, you never know in advance.

> bundling up features in a scheduled update is a good way to make it visible to users that their subscription dollars aren't just falling into a black hole

This is exactly why it's not true that "subscriptions are actually the ideal way of aligning incentives for products that involve ongoing maintenance". Instead of maintenance, subscriptions incentivize continuous delivery of new features, and consequently continuous delivery of new bugs.

I suspect this is a reversal of cause and effect.

Did consumers demand subscription services? Or did vendors (led by Adobe) decide to change to subscriptions to get uniform cash flow?

At agencies I have worked at all creatives I worked with would prefer to spend $200-400 and have a permanent software license. Perhaps this isn't a representative group.

I'm not saying consumers demanded subscriptions. vendors push them because it's a saner way of managing revenue for products that require maintenance post-sale anyway.

that said, I think consumers would prefer subscriptions if they understood how it aligned incentives. one way or another, a product will stop receiving support when the money stops flowing in. with a permanent license, it ends when people stop buying licenses. with subscriptions, it continues as long as enough people keep paying.

> I think consumers would prefer subscriptions if they understood how it aligned incentives.

Funny how consumers tend to despise them though.

The term "subscription" itself a typically a euphemism for "rental". There are a small number of companies who offer a year of updates that you get to keep forever (which makes consumers play the game of when exactly to buy to maximize the new features in that year), but most so-called subscriptions disable the software entirely if you stop paying. In other words, rental.

Long-term rental is almost always a bad deal for consumers. One of the few exceptions is housing, because many consumers can't afford to buy a house, and also houses are one of the least liquid assets you can own, if you have to move it (and yourself). Otherwise, rental is going to cost you a lot more in the long run.

Financially, rental can work well for the seller, of course, but we end up with "subscription fatigue", where the market can't sustain as many sellers, and the few rich companies get richer (which is exactly why they were "pioneered" by BigCos such as Adobe, Microsoft, and Apple).

> Funny how consumers tend to despise them though.

sure, and as an individual I behave the same way. I always want to solve my problem in the cheapest possible way. still, I can't help but notice that products with stable ongoing revenue tend to get much better support.

I think the clearest example is with games. most games get released with a pile of bugs. a bunch get fixed in a release day patch and then there are a few more patches over the next few months (when most of the sales happen). once the initial wave of sales subsides, you tend to be stuck with whatever bugs remain. cs:source had several game breaking bugs for years (defuse kit over bomb blocking defuse, defusing through walls, etc.) despite being one of the most popular FPS titles of its time. AFAIK, most of these still exist fifteen years later. csgo, which is monetized through microtransactions, gets bugs fixed almost as fast as they can be posted to reddit/youtube. microtransactions aren't quite the same as subscriptions, of course, but they generate revenue proportional to the current userbase, rather than the rate that people buy the game for the first time (which will inevitably dry up).

> that said, I think consumers would prefer subscriptions if they understood how it aligned incentives.

Actually, I think subscriptions misaligns incentives. With subscriptions, it becomes important for the vendors to keep releasing updates (so that the customers feel like they're getting value out of the subscription), which means having bug-free software is a terrible idea. You'd need to either release intentionally buggy software (so you can ship a follow-up version to fix it) or go on a feature treadmill (in which case trying to stabilize has rapidly diminishing returns and high opportunity cost).

As a consumer, software that was developed knowing it would never be fixed and has to be perfect the first try is much better (even if it still has bugs). Mario64 had bugs (e.g. backwards jump going really fast); but the bugs weren't really noticeable in normal gameplay because they couldn't just ship an update most of the size of the whole game before you start to play.

No, subscriptions introduce the perverse incentive to release unfinished products and slowly drip-feed fixes. Having to test extensively before a one-and-only release may not drive nearly as much revenue, nor provide a running deliverable stream for a given engineer/product manager's CV, but it is clearly the better user experience.

you say this, but given a choice between a "finished" product and a competitor with more bugs and more wanted/needed features, users will almost always pick the latter unless it catastrophically affects their workflow. engineers care about quality; customers care about the fastest way of solving their problem.

> engineers care about quality; customers care about the fastest way of solving their problem

Almost all customers care about quality. The problem is that many customers have only very limited information about products, so they have a hard time judging quality vs. competitors before (or even after) purchase.

This reveals a general problem with the market: it doesn't select for quality. Otherwise we wouldn't be having this conversation. The market is really good at producing cheap crap. So the truth is, yes, engineers have to care about quality. The motivation for quality has to come from pride in your own work, not from outside market forces. If you care about quality, then you have to strive for that over quantity, and also charge sustainable prices instead of trying to lowball. You may not be the market leader, but there are many profitable niches. Some customers are definitely willing to pay for quality.

> Almost all customers care about quality.

yes, but not to the exclusion of features. I work on a B2B product where our customers bill their customers by the hour, so they tend to have a pretty good idea of how much time a feature saves them. if a competitor adds a feature that cuts the time needed for a project in half (not unrealistic) but crashes and forces them to start over a quarter of the time, the customers will still buy their product instead of ours. they'll complain incessantly on the competitor's forums about the crashes and threaten to switch back to our product, but they won't actually do it unless we come up with something new that saves them even more time.

customers care about saving time and/or money; they only care about quality to the extent that it furthers that fundamental goal. if there is some bug-ridden alternative that solves their problem faster, they will do their best to find it and purchase it.

edit: to be clear, I mean "reliability" when I say "quality"; their are many other "qualities" a product can have, one of them being "cheap".

There's a big difference between not caring and making a tradeoff. You can care about A and B but decide B is more important than A. But if you don't care about A, then there's no tradeoff, you just choose B no matter what.

The question is, why do we make consumers make that tradeoff? Why are we shipping junk at all? There shouldn't be a reliability tradeoff. All products should be reliable. It ought to be a bare minimum standard.

> There's a big difference between not caring and making a tradeoff. You can care about A and B but decide B is more important than A. But if you don't care about A, then there's no tradeoff, you just choose B no matter what.

fair enough, I probably overstated my point with some of the wording.

> The question is, why do we make consumers make that tradeoff? Why are we shipping junk at all? There shouldn't be a reliability tradeoff. All products should be reliable. It ought to be a bare minimum standard.

everything in life is a tradeoff. we could make software more reliable, but then we would have to spend less time adding new features, or we would have to hire more/better engineers and charge more. maybe we even get to pay down tech debt and gain the ability to add features faster in the long run. doesn't really matter if someone else dumps a bunch of buggy new features in the meantime, converts our customers, and forces us out of business. in the absence of some industry-wide gentleman's agreement or regulation, we have to observe the behavior of customers and do what their behavior (not words!) indicates they want.

> doesn't really matter if someone else dumps a bunch of buggy new features in the meantime, converts our customers, and forces us out of business

This is always presented as the doomsday scenario, but how often does it actually happen?

The story of Apple in the Tim Cook era is unrelenting annual releases, more and more "subscriptions", massive return of cash to AAPL shareholders, but decreasing product quality. Did Apple make that tradeoff because they were scared of going out of business? No, they were doing very well before Cook took over. Cook simply has lower standards than Jobs, there's no other reason. He's been great for investors, not so great for customers.

You state that "unless" as if it weren't generally the common state of "competitor with more bugs."

No, users pick a finished product.

Developers get paid every couple of weeks, so an agile business tries to track the value gained from that expense on a similar cadence. The process has become more about corporate governance than delivering customer value.

> Innovation has never and will never happen on a schedule. This is simply greed-driven, promotion-driven, pointy-haired-boss-driven development.

For consumer goods, it is the hype cycle.

New updates and releases get press. They also restore consumer confidence.

If Samsung announced that next year they weren't releasing a new Galaxy phone, the entire industry would freak out. Consumers would lose confidence in buying Samsung phones, journalists would write articles questioning if Samsung was pulling out of the market, a lot of bad things would happen.

Give it 18 months without a release and people would start to think of Samsung as "that company that used to make phones."

They would have to fight like heck to restore their image.

Software is the same way. In the Vista/7/8 era, Microsoft looked like they were falling behind because their competitors started releasing yearly, or even bi-yearly, feature updates.

Sure every Android version up until 7 was kinda-sorta-terrible, but it kept Android in the news. Likewise, Apple got huge free press every time they announced a new revision of OS X (now MacOS), and every time they came out an announced a new version of iOS.

The result? "The desktop is dying, phones are where the real innovation is at!" articles being published even faster than those software updates came out.

You can of course release too fast, rarely do Chrome or Firefox's releases get any press (unless there is a controversial UI change), but in general frequent updates are free advertising.

Tesla is also great at this, I'm nowhere near being in the market for a Tesla, but at least a couple times a year I still end up hearing about software features they are rolling out!

> If Samsung announced that next year they weren't releasing a new Galaxy phone, the entire industry would freak out.

The smartphone industry has only themselves to blame for setting up this expectation. But it is possible to get off the train. I remember when Apple announced they were dropping out of the annual MacWorld San Francisco conference, because they didn't want to constrain their product release cycle. Apple survived that just fine.

> In the Vista/7/8 era, Microsoft looked like they were falling behind because their competitors started releasing yearly, or even bi-yearly, feature updates.

Competitors? Windows and Mac had near 100% market share on desktop. There was only 1 competitor. Vista was released in January 2007, but Mac OS X 10.5 Leopard was infamously delayed until October 2007 because of iPhone, so this telling of history doesn't seem entirely accurate. Moreover, Mac OS X releases were already slowing. Here's a list of months since the previous major .0 release:

10.1.0 6

10.2.0 11

10.3.0 14

10.4.0 18

10.5.0 18

10.6.0 22

10.7.0 23

10.8.0 12

10.9.0 15

10.10.0 12

10.11.0 11

10.12.0 12

10.13.0 12

10.14.0 12

10.15.0 12

Thus, major Mac OS releases were slowing down year by year — which is totally sensible — but then Steve Jobs died after 10.7 was released in 2011, and only then did they switch to a yearly schedule.

The competitor in the 7 era wasn't more PCs, it was tablet mania. Fear of tablets replacing PCs lead to Windows 8.

Of course that didn't come to pass, but everyone acted like it was the future and the market responded accordingly.

This criticism is based on the assumption that all updates are created equal. But they aren't.

One week, the update could be a relatively minor bug fix. The next week, a major feature upgrade that's been in the pipeline for months.

You also remove the ambiguity of "Is this worth pushing out? When should I push this out? Should I do some more fixes or push this one out first?". You got fixes, push them out in the next update.

Your criticism also assumes a small team. If you have a large enough team where you can split them into new feature development and current bug fixing, they're going to work at different rates and be ready at different times. If instead your entire team just works on "the product", then there is no effective difference between fixing issues and creating functionality.