4 ms·

That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as we

That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. 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.

gajjanag 10y ago
> That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. > 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 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.
- mburst 10y ago
  Not that I'm arguing for or against auto-updating, but I'd say Windows XP fits the bill for a vendor maintaining an LTS and yet people are still on that. LTS versions need to die at some point too.
- illumin8 10y ago
  As another commenter mentioned, LTS for Windows XP and Server 2003 is very good - where else can you expect 15+ years of support? > 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.
Silhouette 10y ago
You make an interesting analogy, but I'm not sure it truly supports the point you were hoping to make. 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.
- illumin8 10y ago
  > 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.

gajjanag 10y ago

> That doesn't mean this is a good practice. In fact, I would argue that this type of thinking has created far more harm than good for both the IT industry as well as the companies that adopt this harmful practice. > 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 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.

mburst 10y ago
Not that I'm arguing for or against auto-updating, but I'd say Windows XP fits the bill for a vendor maintaining an LTS and yet people are still on that. LTS versions need to die at some point too.
illumin8 10y ago
As another commenter mentioned, LTS for Windows XP and Server 2003 is very good - where else can you expect 15+ years of support? > 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.

Silhouette 10y ago

You make an interesting analogy, but I'm not sure it truly supports the point you were hoping to make. 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.

illumin8 10y ago
> 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.