Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk.

This is no different than a state or local government refusing to maintain critical infrastructure like bridges and tunnels. Negligence might be viewed as conservatism for a few years, but when the bridge collapses because routine maintenance wasn't performed, it becomes clear that the administration who neglected maintenance was at fault.

The sooner the cancerous idea, that IT software can be frozen in some golden state of perpetually providing business value with zero maintenance required, dies, the better.

Modern, thoughtful IT leadership realizes the value in a continuously updated, secure browser. Chrome is already winning the browser war in the Enterprise for this reason alone. This just provides additionally needed controls like white-listed extensions that are known to be safe.

> Case in point: many of these same companies that refuse to upgrade systems for a decade or more are still running Windows XP and Server 2003. Due to the negligence of their IT leadership, they are now vulnerable to all types of security vulnerabilities that won't be patched, and have put both their business and their customer's private data at risk.

There are legitimate reasons for this though. The way I understand it, a big chunk of the problem is that many software vendors refuse to properly separate security related updates from regular updates. Firefox at least has an ESR version, AFAIK there is no equivalent for Chrome. See also attitudes like that mentioned in: https://news.ycombinator.com/item?id=9164251

Similar examples can be given for MATLAB - I know of many professors who ask students to run some old and fixed version of MATLAB for many years - they do not want to waste their time dealing with the breakage that inevitably happens with newer releases.

If all vendors actually put in effort into maintaining LTS versions, the situation could be different.

I do agree that the idea of perpetual business value with zero maintenance in a frozen state doesn't make sense - but as a business, I would always be interested in minimizing my maintenance burden.

> but as a business, I would always be interested in minimizing my maintenance burden.

The argument that I'm trying to make is that by deferring maintenance until it is too late, you're actually dramatically increasing your maintenance burden in the long term. Testing and maintenance fixes for your app to support Chrome updates, which rarely break anything, will be much lower over a 10+ year (or probably even 5+ year) timeframe than just sticking your head in the sand and making someone 10 years from now pay an astronomical cost to refactor the app completely.

If maintaining critical infrastructure like bridges and tunnels worked like deploying software updates, every few weeks the bridge or tunnel would close itself to traffic in one direction for a while, without warning.

Every now and then when the tunnel reopened, it would feature a loop-the-loop hidden inside the mountain. While it looked the same from outside, it would therefore become completely impassable by large amounts of the traffic that used to rely on it, including ambulances, food supplies, and the CEO's limo.

Every couple of years, your world famous suspension bridge, used as a widely recognised landmark by millions, would be redesigned more like a Roman aqueduct. With traffic driving on the opposite side of the road. And a high speed railway line running right down one of the traffic lanes. With warning signals that are supposed to alert motorists to the danger, but in practice don't because none of the motorists know what the funny symbols mean.

When software engineering is at least on the same planet as civil engineering, and software updates are subject to the same standards of oversight and approval before being deployed, we can talk. Until then, organisations can and will see software as a tool that is there to do a job, and view updates to working software as a high risk that isn't worth taking if it might stop that software from doing its job. It might be inconvenient for the software developers, who naturally would prefer everyone to bend to their will and never to have to maintain anything older than five minutes, but those software developers are going to have to realise at some point that the world doesn't revolve around them.

They already do this by closing lanes, and even closing entire bridges at night during maintenance when required. The "without notice" part is only if you're doing it wrong - you should be giving your users advance notice of any maintenance activity.

> Every now and then when the tunnel reopened, it would feature a loop-the-loop hidden inside the mountain. While it looked the same from outside, it would therefore become completely impassable by large amounts of the traffic that used to rely on it, including ambulances, food supplies, and the CEO's limo.

I'm not sure I buy this argument. The failure modes of bridges are well understood and usually life threatening. The failure modes of software are not as well understood, but are rarely life threatening. If you're updating pacemaker software, yes, take extreme precautions and don't introduce defects, but the amount of testing and preparation should depend on the impact of a potential failure.

> Every couple of years, your world famous suspension bridge, used as a widely recognised landmark by millions, would be redesigned more like a Roman aqueduct.

This seems like a false equivalency. Suspension bridges take years or decades to design and build. Software can be built in weeks or even days. The frequency of major infrastructure changes is directly correlated with the time and effort involved in deploying them, in both civil and software engineering.

My previous comment was not really about the realities of civil engineering. It was about how absurd civil engineering would be, if the routine maintenance done in that context failed as often and as spectacularly as software updates do.

To be more blunt about it: Organisations don't want software that updates itself frequently and fallibly, because they simply can't afford to have basic functionality going out of service every few weeks, complete and possibly permanent loss of compatibility with critical services from time to time, and the design and UI changing at random in ways that are confusing to users.

The entire reason to do frequent, small updates, instead of large, spectacular updates is to avoid all the problems you mention in the last paragraph.

In that case, it actually does become quite a bit like civil engineering, in that if they keep relatively minor repaving a lane every year, without disrupting traffic completely, they can avoid the entire road failing spectacularly and having to be blocked off to rebuild. Of course I don't really know much about civil engineering...

Cheers, anyway.

So the theory goes, but I'm not sure there's really any such thing as a small update if you're talking about software used by hundreds or thousands of staff that provides the platform on which tens or even hundreds or important business applications are built.

If you're talking strictly about security updates, which are intended to address an identified vulnerability without making any other change, then I would agree there's an argument for making those more frequently.

Unfortunately, many of the key players, including those producing the evergreen browsers, make little or no distinction between essential security fixes and other changes, and at that point the risk/reward ratio of accepting frequent updates can change rather sharply.

Well, it's not life threatening, but what do you think will happen if every month your credit-card stops working for a few days because of a Windows/Linux regression?

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.

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?

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.

Also, is it 100% true that they dont update software on actuve systems mid mission?

What if they discover a critical bug?

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.

The Universe auto updates. So you need to update your rover when that happens.

The "risk adverse" nature, I can't belive I just said that about a bank, will become a problem.

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.

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.

Take a look at page 45 (page 27 of the PDF itself): https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturit...

Sure it has. When software existed on physical media and there was a real, material cost with distribution of software, there was absolutely a done state. Waterfall software development and actual requirement control would clearly define done states. That's not to say that there weren't bug fixes and updates, but it was (and is) possible to define what an application should do, code it to do so, test that it works, and ship it. But the world has changed, software has become easier to develop and distribute, and software development methodologies have shifted to where we don't have to have a done state in the same sense that we used to. I don't think it's a coincidence that we got agile development after the Internet.

The build that ends up on the disk is not "completely broken or even mostly empty"; it is what the development team and publisher were satisfied shipping as the finished game 2-3 months prior. Any software, and games moreso, can be improved with more time so the intervening time to release day is often taken up with development of a launch day patch to fix bugs that were triaged to be ok to ship with, and/or to add features/systems/content that just missed the cut before.

Launch day patch sizes is more of a symptom of the build pipeline (maybe there is some non-determinism that is introducing larger diffs than are otherwise necessary) or late optimizations (to build packing, asset management, etc) that can force you to download the majority of the game again.

...Well, then. Would you care to explain Assassin's Creed Unity, and Tony Hawk's Pro Skater 5? I suppose you classify them as "not completely broken"?

Tony Hawk Pro Skater 5 was a rushed project and generally poor game. It was buggy but that was the least of its problems. Many people considered it the worst, or at least one of the worst, major releases of that year. I don't think it is representative of contemporary games as your comment would imply.

I can understand that it's "bad" that their story was lacking at release, but isn't it awesome that they'd go to such lengths to serve fans and buyers and have a good product in the end, if not in the beginning?

To me this is not that uncommon. Let me tell you a story (I cannot provide a quotable evidence for a central point of the story except for multiple friends who independently had the same feeling after seeing Harry Potter and the Chamber of Secrets two times in few weeks when it came out in cinema in Germany).

At that time when this movie came out in Germany there was a law that "FSK 12" movies must only be watched by people who are at least 12 years old. The problem was: Harry Potter and the Chamber of Secrets was rated "FSK 12", while Warner would have liked it to be "FSK 6". So they cut some scene parts out of the movie to get this rating for the German cinema release (BTW: this incident lead to a change in the laws that now children under 12 years old may also go to "FSK 12" movies as long as they are accompanied by a parent). So far this is a story where for every claim I could provide strong evidence.

Now the strange part comes: (#) People who saw this movie shortly after release day and a few weeks after (in Germany) all could point out to some scenes (and they were the same) that they clearly remembered when they first saw the movie, but not the second time. So it seems to be that there were some cut alterings done afterwards and there were actually two different versions to be seen in German cinemas. I personally assume that this had to do something with the stated age restrictions (they forgot to cut some scene parts when they initially released the movie in the cinemas, so they hastily changed things afterwards and released a new version to the cinemas).

As I said: I can provide no independently verifiable evidence that (#) happened - but I deeply trust the independent persons that claimed so and I deeply trust their visual memory (I would only trust people who have a really good visual memory for such strong claims).

TLDR: changing a movie shortly after release is nothing that deeply surprises me.

I worked on a team that maintained a data portal website used by major pharma companies and clinical research organizations. It had to be IE7-proof for a very long time because many of our largest clients were still running very old browsers internally because of IT rules. Our R&D team would have loved to drop support for these antiquated browsers, but, shockingly, our sales and operations teams were not willing to tell multi-million dollar clients that they better upgrade their infrastructure or they couldn't use our software.

Happily we did convince them to get some hardware and software upgrades, so by the end of the project they were able to see their website the way most of their customers would. The proxy continues to be a nuisance; their developer can't access the cloud server where their production website is deployed; he has to rely on me to make any changes that are needed there.

>That has never been true.

That opinion is the exact reason we constantly have jr. dev's re-inventing the wheel with their great new idea. Nothing frustrates me more than someone thinking they should re-write applications just for the sake of re-writing it. If the software is feature complete, and lacks bugs, WHY WOULD YOU RE-WRITE IT?? To frustrate end-users with a new interface they have to learn? Because you're bored and want to deploy language of the month?

Your two options are ridiclous and show a very naive view of the world of software. There are literally pieces of code at likely every one of the fortune 100 that was written in the 80s for a specific task, still does that task flawlessly, and has absolutely no reason for anyone to touch it. That's a GOOD THING.

Counter-argument: software does exist in a 'done' state, or rather snapshots of it via releases. When version 1.2.1 is done, it is done.

Version numbers are a sane way to manage things for sys-admins and software engineers (think compatibility matrices and SemVer). I'm going to guess you are closer to the engineer side of that spectrum: can you imagine the insanity of having to maintain compatibility with a library that is self-updating and has an 'evergreen' API? The ability to pin versions is a God-send, falling too many versions behind is abusing that ability.

Some software does actually reach a "done" state, where there is nothing left to do, assuming no major platform changes.

wc will probably work as intended until UNIX itself shambles off the coil at this point.

https://svnweb.freebsd.org/base/head/usr.bin/wc/wc.c?view=lo...

http://git.savannah.gnu.org/cgit/coreutils.git/log/src/wc.c

But you could pull in wc from V7 on modern computers, and it would still work. (assuming GCC can still compile K&R C).

As an aside, I'm pretty sure K&R C is a subset of ANSI C, so any ANSI C compiler should be able to compile K&R C.

Not so, AFAICT. For one thing, K&R function declarations looked like this:

  int main(argc, argv)
  int argc, char **argv
  {
  ...
  }

Also, in K&R, function prototypes didn't list args.

    11:44:57 cory@tizona /home/cory/Workspace/test
    $ cat knr.c
    #include <stdio.h>
    
    main(argc, argv)
            int argc;
            char **argv;
    {
            int z = foo(3, 4);
            printf("foo is %d\n", z);
    }
    
    foo(x, y)
    {
            return x + y;
    }
    
    
    11:44:59 cory@tizona /home/cory/Workspace/test
    $ gcc -std=c89 -pedantic -o knr knr.c
    
    11:45:07 cory@tizona /home/cory/Workspace/test
    $ ./knr
    foo is 7
    
    11:45:11 cory@tizona /home/cory/Workspace/test
    $ gcc -v
    Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/specs
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-slackware-linux/5.3.0/lto-wrapper
    Target: x86_64-slackware-linux
    Configured with: ../gcc-5.3.0/configure [...]
    Thread model: posix
    gcc version 5.3.0 (GCC) 

All true, but in a larger organisation with all the overheads and co-ordination that entails, you're looking for a pace of change measured in years, not weeks. You have better things to do than constantly redoing work you already did because software changes, and IT systems that aren't set up accordingly are simply failing to meet one of the most basic business requirements for being useful.