4 ms·
Interesting how far we've come. There was a time when a new version of an application came along every 2-3 years or longer; or never (it was fully baked and di
by blunte 6y ago
Interesting how far we've come. There was a time when a new version of an application came along every 2-3 years or longer; or never (it was fully baked and did what it said on the package, from day one).
Now we suffer from update fatigue, where half the time we fire up an app or turn on a device, it must spend a few minutes updating apps.
I'm not convinced that we always get value from these updates. (Security updates are indeed important, but sometimes their need is evidence of pushing out features too soon, without proper testing and review.)
Google Calendar seems to do everything I need and more; same with Gmail. I don't want new versions of them unless there's a really compelling reason. I sure don't want < 2 month release cycles.
- Icathian 6y agoIn fairness, I think that while you mention security as a main source of this, you have it a bit out of order. Security pressures and expectations are substantially higher these days. Applications written thirty years ago faced far fewer attacks, and with generally less consequence for failure, than they do today. Probably by orders of magnitude though that would be hard to actually measure. Increased patching to address this reality seems unavoidable, at least until we understand how to produce truly secure software on the first try far better than we currently do.
- adkadskhj 6y agoAlso applications written 30 years ago today were often self contained applications. Something you can test in a variety of environments as a reasonable proxy to the end user. Today with SaaS/etc offerings you have very different difficulty spikes. Imagine only rolling out an update once a year to 1B customers. Especially with all the big changes that might entail. I can't imagine the fear. Releasing often irons out small problems before they become massive problems. Or, at least, is a strategy to attempt that.
- pca006132 6y agoAccording to the post website, the Google Search app updated 27 times this year... is that really this insecure? And honestly, I don't get the idea of making an app for every service where a simple web app suffices. Why making a native app that requires installation when you can do it through the browser?
- falcolas 6y ago> is that really this insecure Depends on how many libraries there are. I have to deal with at least 2-3 different CVEs existing in our libraries or runtimes a month. And I’m dealing with a pretty small surface area compared to some of my peers. We rebuild our environment from scratch every week to reduce the manual work involved in resolving those CVEs.
- blunte 6y agoSurely some of those security vulnerabilities in underlying libraries could be avoided with a bit more careful, slower releases of the libraries themselves. There is no question that the current app reality is one or more orders of magnitude more complex than in "the old days"; but even so, I think the race to MVP (and perhaps the VC pressures that drive some of that?) have led to layers of rushed out, risky codebases.
- deleted 6y ago[deleted]
- Black101 6y ago> Google Calendar seems to do everything I need and more; same with Gmail. I don't want new versions of them unless there's a really compelling reason. I sure don't want < 2 month release cycles. We probably get the unnecessary updates because Google (and others) have a boat-load of engineers that need something to do and they aren't getting assigned to something useful.
- the_gipsy 6y ago> Google Calendar seems to do everything I need and more; same with Gmail. I don't want new versions of them unless there's a really compelling reason. I sure don't want < 2 month release cycles. It got there by doing short cycles
- johannes1234321 6y ago1) the fact they did short cycles doesn't mean, that short cycles were useful (while probably short cycles makes it simpler to carry users along) 2) it doesn't mean they are still benefitial to the users. At some point an app does "all" and new features are more likely to lead to bloat than improvements for 99% of the users. Thus "they got there due to that" isn't an argument.
- the_gipsy 6y ago2) is completely independent of short release cycles
- josefx 6y agoTo me it is almost surprising they still work. Every time Let's Encrypt comes up it seems people are in a rush to have security certificates invalidate within weeks if not days. A server backed app without updates for two months would turn into a brick.
- dtech 6y agoLE certificate renewal is server-side, client apps don't need updates.
- josefx 6y agoAh, forgot that the trust model is only based on having a valid certificate for the domain, not on the specific certificate. Which is only a problem if someone manages to hijack the domain long enough to get a valid cert. Google is probably less likely to loose control of its main domains than other groups that sometimes just forget to keep track of them.
- macinjosh 6y agoThis is a result of agile practices being more of the norm. Continuous delivery of code has been preferred over monolithic releases.
- cerved 6y agoI can't recall the last time I noticed an app upgrade