9 ms·

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or deve

I think this is a weak argument. The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. That has never been true. The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. If you roll your own software, you either commit to constantly updating it, or you commit to throwing a ton of money down the drain when its rots away to the point where it is no longer fit for your workflow or for the world it operates in. Software is never finished, only abandoned.

DougN7 10y ago
I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each office. Having their internal web app that everyone uses go down because of an auto upgrade could cost them hundreds of millions. They have a very different risk appetite.
- tomelders 10y ago
  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.
  - riprowan 10y ago
    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?
    - tomelders 10y ago
      I think we can all agree that NASA is a special case. Also, is it 100% true that they dont update software on actuve systems mid mission? What if they discover a critical bug?
      - DougWebb 10y ago
        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.
        tomelders 10y ago
        In this example though, your app is the mars rover and Chrome is the rest of the Universe. The Universe auto updates. So you need to update your rover when that happens.
      - raarts 10y ago
        NASA is not a special case. What about medical equipment, weapons , oil industry, stock trading, I bet other people here can think of more examples.
    - illumin8 10y ago
      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.
  - neiled 10y ago
    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.
    - tomelders 10y ago
      Thats called bad management.
      - tossedaway334 10y ago
        It is the reality of the situation in a vast amount of companies.
        fuck_google 10y ago
        And its only going to get worse by disabling automatic updates.
        CaptSpify 10y ago
        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
        tossedaway334 10y ago
        The only thing you do by "taking away their choice" is to force them to use alternatives that are not Google Chrome.
        CaptSpify 10y ago
        I would argue that's a good thing
    - johnward 10y ago
- nommm-nommm 10y ago
  They used to, this is no longer the norm though. The norm is moving to patching systems regularly.
- illumin8 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. 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.
- heartbreak 10y ago
  I'd say that this enterprise version of Chrome will finally fit in a financial institutions's baseline target for their patch management system. Take a look at page 45 (page 27 of the PDF itself): https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturity_June_2015_PDF2_c.pdf https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturit...
bmj 10y ago
It's not just engineering/R&D that makes this decision. IT departments generally have the last word on what applications (browsers, for example) will be supported. A real life example: 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.
- DougWebb 10y ago
  I had a similar experience. I was developing a customer portal website for one of my company's clients. Well into the project I found out that everyone at the company, including everyone who would be doing QA, had monitors that only went up to 800x600, they were all locked down to an old version of IE (8 or 9 I think), and they had a default-blocked web proxy in place so they needed special permission to even see the test portal I had running on my server. 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.
eddieroger 10y ago
> That has never been true. 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.
- homero 10y ago
  Definitely true, now video games on discs are manufactured completely broken or even mostly empty and they make you download 50gb on launch day
  - ggregoire 10y ago
    Are you talking about Final Fantasy XV? This case is ridiculous, they are even modifying the story after the launch day. It would be like releasing a movie and changing the end one week after the release because of the bad reviews. Hopefuly the sales of FFXV are relatively bad.
    - shandor 10y ago
      Sorry but why is that a bad thing? 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?
      - hfsktr 10y ago
        pretty quick we will end up with nothing but the worst graphics/story when you buy a game because you can just patch it and fix it later.
crispyambulance 10y ago
I wish I could paste a screenshot of my desktop with Oracle EBS (enterprise business suite) windows open-- it looks like something straight out of 1997. Horrifically bad interfaces that burn through users' time and patience with no end in sight and surly non-responsive staff running it. Efficiency be damned, and yes, people are perfectly happy to throw money down the drain to keep it running.
- compuguy 10y ago
  It could be worse. I worked for a company that still had VB6 apps in active use, and wanted to write new apps in VB6!
sangnoir 10y ago
> The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required 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.
qwertyuiop924 10y ago
>That has never been true. 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.
- fanf2 10y ago
  Let's have a look at maintenance activity on wc, shall we? https://svnweb.freebsd.org/base/head/usr.bin/wc/wc.c?view=log 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 http://git.savannah.gnu.org/cgit/coreutils.git/log/src/wc.c
  - qwertyuiop924 10y ago
    BSD wc hasn't been touched in a year. GNU wc's recent patches were either the addition of features, or bugfixes for what seem to be relatively new features. Or optimization. But you could pull in wc from V7 on modern computers, and it would still work. (assuming GCC can still compile K&R C).
    - groovy2shoes 10y ago
      Yup. Likewise, the version of `wc` from Kernighan & Plaugher's «Software Tools in Pascal» still compiles and runs with any ol' ISO Pascal compiler, and still does exactly what the manpage says it does. 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.
      - qwertyuiop924 10y ago
        >pretty sure K&R C is a subset of ANSI C, Not so, AFAICT. For one thing, K&R function declarations looked like this: int main(argc, argv) int argc, char **argv { ... } Ever wonder where 1TBS came from? Also, in K&R, function prototypes didn't list args.
Silhouette 10y ago
The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. 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.
tw04 10y ago
>The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. >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.

DougN7 10y ago

I question if you've worked with large enterprises. They freeze everything for a decade or more. Think about a bank with 500 offices, a dozen tellers at each office. Having their internal web app that everyone uses go down because of an auto upgrade could cost them hundreds of millions. They have a very different risk appetite.

tomelders 10y ago
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.
- riprowan 10y ago
  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?
  - tomelders 10y ago
    I think we can all agree that NASA is a special case. Also, is it 100% true that they dont update software on actuve systems mid mission? What if they discover a critical bug?
    - DougWebb 10y ago
      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.
      - tomelders 10y ago
        In this example though, your app is the mars rover and Chrome is the rest of the Universe. The Universe auto updates. So you need to update your rover when that happens.
    - raarts 10y ago
      NASA is not a special case. What about medical equipment, weapons , oil industry, stock trading, I bet other people here can think of more examples.
  - illumin8 10y ago
    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.
- neiled 10y ago
  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.
  - tomelders 10y ago
    Thats called bad management.
    - tossedaway334 10y ago
      It is the reality of the situation in a vast amount of companies.
      - fuck_google 10y ago
        And its only going to get worse by disabling automatic updates.
      - CaptSpify 10y ago
        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
        tossedaway334 10y ago
        The only thing you do by "taking away their choice" is to force them to use alternatives that are not Google Chrome.
        CaptSpify 10y ago
        I would argue that's a good thing
  - johnward 10y ago
nommm-nommm 10y ago
They used to, this is no longer the norm though. The norm is moving to patching systems regularly.
illumin8 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. 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.
heartbreak 10y ago
I'd say that this enterprise version of Chrome will finally fit in a financial institutions's baseline target for their patch management system. Take a look at page 45 (page 27 of the PDF itself): https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturity_June_2015_PDF2_c.pdf https://www.ffiec.gov/pdf/cybersecurity/FFIEC_CAT_CS_Maturit...

bmj 10y ago

It's not just engineering/R&D that makes this decision. IT departments generally have the last word on what applications (browsers, for example) will be supported. A real life example: 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.

DougWebb 10y ago
I had a similar experience. I was developing a customer portal website for one of my company's clients. Well into the project I found out that everyone at the company, including everyone who would be doing QA, had monitors that only went up to 800x600, they were all locked down to an old version of IE (8 or 9 I think), and they had a default-blocked web proxy in place so they needed special permission to even see the test portal I had running on my server. 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.

eddieroger 10y ago

> That has never been true. 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.

homero 10y ago
Definitely true, now video games on discs are manufactured completely broken or even mostly empty and they make you download 50gb on launch day
- ggregoire 10y ago
  Are you talking about Final Fantasy XV? This case is ridiculous, they are even modifying the story after the launch day. It would be like releasing a movie and changing the end one week after the release because of the bad reviews. Hopefuly the sales of FFXV are relatively bad.
  - shandor 10y ago
    Sorry but why is that a bad thing? 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?
    - hfsktr 10y ago
      pretty quick we will end up with nothing but the worst graphics/story when you buy a game because you can just patch it and fix it later.

crispyambulance 10y ago

I wish I could paste a screenshot of my desktop with Oracle EBS (enterprise business suite) windows open-- it looks like something straight out of 1997. Horrifically bad interfaces that burn through users' time and patience with no end in sight and surly non-responsive staff running it. Efficiency be damned, and yes, people are perfectly happy to throw money down the drain to keep it running.

compuguy 10y ago
It could be worse. I worked for a company that still had VB6 apps in active use, and wanted to write new apps in VB6!

sangnoir 10y ago

> The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required 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.

qwertyuiop924 10y ago

>That has never been true. 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.

fanf2 10y ago
Let's have a look at maintenance activity on wc, shall we? https://svnweb.freebsd.org/base/head/usr.bin/wc/wc.c?view=log 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 http://git.savannah.gnu.org/cgit/coreutils.git/log/src/wc.c
- qwertyuiop924 10y ago
  BSD wc hasn't been touched in a year. GNU wc's recent patches were either the addition of features, or bugfixes for what seem to be relatively new features. Or optimization. But you could pull in wc from V7 on modern computers, and it would still work. (assuming GCC can still compile K&R C).
  - groovy2shoes 10y ago
    Yup. Likewise, the version of `wc` from Kernighan & Plaugher's «Software Tools in Pascal» still compiles and runs with any ol' ISO Pascal compiler, and still does exactly what the manpage says it does. 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.
    - qwertyuiop924 10y ago
      >pretty sure K&R C is a subset of ANSI C, Not so, AFAICT. For one thing, K&R function declarations looked like this: int main(argc, argv) int argc, char **argv { ... } Ever wonder where 1TBS came from? Also, in K&R, function prototypes didn't list args.

Silhouette 10y ago

The hardware and software changes. The infrastructure it connects to changes. But most importantly, your workflows must evolve if you are to remain efficient. 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.

tw04 10y ago

>The problem here is that companies think that software can exist in some sort of "done" state, where no further updates or development is required. >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.