4 ms·

In 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 substant

In 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 ago
Also 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 ago
According 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 ago
    Surely 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.

adkadskhj 6y ago

Also 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 ago

According 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 ago
  Surely 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.