Ive actually been working in banks mainly. But on the business side.
At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back.
But even the board can only affect so much.
The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance.
But if dev has stopped, then yes, you will have a problem.
Dev stops. That's reality. If you hand-wave it away, your tellers go down, and you, the CIO, lose your job.
Not all software is under your direct control. Once business processes achieve a stable working state, it is imperative that they maintain uptime, sometimes in excess of six-sigma uptime.
Imagine your business is NASA. Are you going to let mission systems auto-update 18 secs before launch?
The dirty truth is that every piece of software or infrastructure you deploy immediately becomes "technical debt," and you know the thing about debt is that it charges interest.
You can choose to neglect paying on your debt for some period of time, but it always comes back, more expensive, later. Case in point: the IT leaders that refused to upgrade from Windows XP and Server 2003 are now paying astronomical prices for "extended support" and "migration/rehosting." If they would have simply invested in maintenance to ensure compatibility with newer OS/browser combinations, they would not have this problem.
Pay now, or pay much much more later. Tech debt is a huge problem in IT, and ignoring it won't make it go away.
I think the point here is that there is no such thing as a stable state in software. Maintaining old infrastructure to support old applications is not a steady-state, it is a degrading state. As bugs and exploits are discovered and patched in new versions of windows/browsers/databases/frameworks/libraries/etc the old systems degrade to a vulnerable, un-maintainable, unsupported and often un-upgradeable state.
Of course NASA updates software mid-mission; they're famous for sending software updates out to deep-space probes and rovers to fix things as critical as communication issues, which is quite a neat trick.
What they don't do is allow updates to happen automatically. They're carefully pre-tested, and the update is carefully planned and scheduled. Their goal, like most enterprises, is to minimize risk, and bugs that you know about and understand the impact of are much less risky than updated software you haven't been able to test yet.
Not only does Dev stop, but the people that built the app, agreed on the specs and really understood it, all left too.
Auto update is unfortunately something that's just not worth the risk in a lot of cases.
With web apps there should be very little risk if you followed standards. The problem is most of these places chose to follow IE6 instead of standards. They will put this off until it becomes a major issue or someone else takes their business. By know I've left banks of terrible client facing systems but internal enn efficiencies are even obvious. It took almost 8 weeks, multiple in person visits, and a freaking typewriter to get my HELOC. It might take another bank a visit and home appraisal and you get a check.
The "risk adverse" nature, I can't belive I just said that about a bank, will become a problem.
With web apps there should be very little risk if you followed standards.
There should be very little risk, but the fact is, there is actually a great deal of risk. With my professional web developer hat on, the "evergreen" browsers are the best advertisement in the history of computing for why organisations that need reliability in their IT systems should be wary of automated updates controlled by outside parties.
Browser updates break stuff all the time. And not just obscure things, though there are plenty of those. On the small scale, I've seen Chrome updates break basic page layout, and rendering styles as simple as rounded corners or shadow effects. On the larger scale, Chrome sometimes removes entire chunks of functionality, like support for important plugins. New features are often the worst, and it's particularly insulting to be told we should all use HTML5 feature X or JS feature Y instead of plugins, when the reality is that the new version still isn't up to doing what the plugin did a decade ago.
Businesses don't care that it's more convenient for the browser developers if everyone rearranges their entire work schedules to keep up with the latest "living standards". Businesses just want software that works, and having found it, they will go to extraordinary lengths to continue using it rather than playing the upgrade lottery. And given the track records of most of the upgraders in this game, frankly, it's hard to blame them.
> With web apps there should be very little risk if you followed standards
You might be surprised by the number of subtle bugs lurking in corners left out as "implementation detail" by standards.
I've learnt to treat browsers as capricious genies that stick to the letter of the standards, but inevitably screw you over by inconsistently doing the opposite of what a sane person would have regarded as implicit.
Only because we let them. I'm very much against auto-updating software, but I still don't see this as a good argument against them. It's not that companies can't keep up, it's that companies choose not to keep up. In this aspect, taking away their choice is the winning move, imo
At the upper echelons there is a real appetite for change. Banks realise that they have become software companies, but that their businesses are groaning under the weight of antiquated systems and processes and it is holding them back.
But even the board can only affect so much.
The only reason an auto update would take down an app is if all development has stopped. As part of the process you should be testing against upcoming releases of chrome so you spot these problems well in advance.
But if dev has stopped, then yes, you will have a problem.