> 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.
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.
Sorry, but we seem to be talking completely at cross-purposes here.
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.
I agree that we're probably talking past each other, re: civil/software engineering.
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...
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.
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.
>The failure modes of software are not as well understood, but are rarely life threatening.
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?
I appreciate the idea, but in that case, it's simply a cost/benefit analysis. The benefit of not losing a few days worth of fees on credit card transactions a month is worth way more than the relatively minimal cost of good QA, testing, change control, and rollback capabilities.
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.