6 ms·

> Other reason, they are gaining money mainly because there are enough fools around running big corps, who can conveniently pass the buck if something goes wron

> Other reason, they are gaining money mainly because there are enough fools around running big corps, who can conveniently pass the buck if something goes wrong. Similar is true for MS too. This is also the sole reason IBM still exists, at least in services. "Oh our system is an overengineered pile of garbage that takes two weeks to deploy an update to a static asset? It's (cue dramatic music) their fault!" CTO proceeds to get bonus IBM Consultants are brought in

abakker 10y ago
For many people in IT, generally not the Hacker News crowd, but the guys in the trenches of [insert corporation name here] with ops in many countries, The Money is NOT really the important thing. Risk mitigation by having a passthrough to the big IT vendors is what they are paying for specifically. I work in the IT consulting / business research space. In our surveys, "vendor viability" is a frequent concern, and the more critical the workload, the more weight is given to wondering whether the vendor will be around, unchanged, in the next 3 years. The risk mitigation factor from large vendors comes not from performance but from reliability. You can trust that old mainframe code will continue to be supported for many years. You can trust that your COBOL workload will be continue to run, and that the 20 years of updates, patches, and tweaks have made it reliable and predictable in a way that precludes rip and replace in all but the most extenuating circumstances. IT budgets tend to be governed by an 80/20 rule - maintenance vs innovation. Sometimes, its more of a 95/5 in practicality due to shrinking budgets. My experience says that the innovation side is drastically shifting away from these big vendors, but that the maintenance side has a lot more riding on it still.
- oblio 10y ago
  Well, thing is, Open Source is changing that proposition. As long as you're prepared to be conservative in your choices, something like Debian + Apache + OSS programming language will likely be around 20-40 years from now. When is the last time an OSS programming language that took off actually died? For example, even though it's not as popular Perl 5 is still used professionally in many environments and as far as I know the ecosystem actually went through a sort of renaissance a few years back. And these days I think it's even easier for OSS ecosystems to achieve critical mass and sustain themselves for decades since communication is easier (a lot more broadband internet in the world) and there's a lot more programmers around. Python, Ruby, PHP & co will probably be around long after I'm dead.
  - abakker 10y ago
    Open source may perpetuate, but it is the on-call, active support that enterprises value. You can't exactly demand prompt action from the support forums, can you? Now maybe open source like Red Hat works that way, but it is very much the commercial terms and operating models that businesses are interested in. Again, for innovative new projects, this is changing.
    - DashRattlesnake 10y ago
      You can't necessarily demand prompt action from a big vendor like Oracle, either. Years ago, I worked on a project that used Oracle's BPM product. It was the only time I've worked on something where the team had a direct line to vendor support. When we had issues, all they ever seemed to do was ask for more logs, over and over again. I think they were hoping we'd give up and close our SRs. Luckily, I got off that project pretty quick. I later learned that they 1) rewrote their BPM product and did not offer a clear upgrade path to the new version, and 2) planned to end support for the old version in a few years. As a developer, the promise of vendor support doesn't ease my mind very much.
      - abakker 10y ago
        This is, of course, how oracle and others earned its reputation. These things and worse really happen. Obviously nobody wants this when they pay for better. I agree with another commenter that in the long run, it'll end up as OSS + support from a 3rd party consultant or vendor that is commercially aligned with your success. It has taken a very long time to convince most IT to behave like a branch of business that can create new value. Once that shift happens fully, we'll see the "keep the lights on at all costs" mindset change a bit in favor of truly measuring ROI and true total cost of ownership. For most large companies this has never been done.
  - ubercode5 10y ago
    I agree. However one additional thing to keep in mind in the COTS vs FOSS is if there is some bug that affects the company and requires attention. The company doesn't generally have the engineers on staff to actually change that software, and there's no guarantee that the associated FOSS community will prioritize the bug. With a COTS solution, you can pick up the phone and call the support team. Generally my company chooses COTS over FOSS because they want guaranteed support even if it costs more. Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner. Edit: Looks like abakker posted the same idea simultaneously.
nickpsecurity 10y ago
Don't forget the original reason: backward compatibility with complicated, mission-critical software on weird hardware nobody can legally clone. These businesses would have to port all their stuff to avoid IBM. They probably don't even know what it does. So, they stick with them to mitigate that risk.
- scholia 10y ago
  Plus, the time to transition off it is far longer than the next quarterly results. It may well be longer than the expected tenure of the CEO....
  - nickpsecurity 10y ago
    Great point. They are short-term focused most of the time.
kens 10y ago
Being able to pass the buck to IBM if things go wrong was actually the theme of IBM's ads in 2001. In a typical ad, the CEO is getting blamed because the system is down / can't be upgraded. CEO: "And whose job is it to make sure all this stuff works the way it's supposed to?" Assistant: "That would be yours." Tagline: "And that's when it hits you, you are so ready for IBM.” (Of course I have to admit they were successful ads if I remember them 15 years later.) Links to the ads: http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/888 http://www.landscapesofcapital.com/items/show/888
- TeMPOraL 10y ago
  Honest ads describing the business value directly. I like that. We could use more of that these days.
  - toomuchtodo 10y ago
    Feels strikingly similar to patio11s blog post: http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro... Someone is delivering business value; whomever that is is the one who is getting paid.
    - TeMPOraL 10y ago
      Thanks for linking to that post, it's great! > Someone is delivering business value; whomever that is is the one who is getting paid. I was going to respond to this by pointing out some common exceptions, but patio11 actually covered this issue in his post too: "Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.)" EDIT: "Their [Salesforce's] motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)" Holy shit. That hits hard.
hinkley 10y ago
IBM Global Services seems to prefer hiring masochists. They will deploy the most complicated solution they can (almost) keep running and then ask for more time and materials when they miss. The FTEs at the company will want nothing to do with their Rube Goldberg sparkly bullshit and are all too happy to walk away and work on something else. Nobody can make XML impenetrable like IBMGS can. It is both fascinating and horrifying to watch.
- tracker1 10y ago
  This is part of why my initial and strong reaction against most "Enterprise" patterns and libraries... It often leads to so much indirection and complexity, that those working with it don't ever stop to thing "why" they are doing things a certain way, and when new people come in to support said solution, they face a mountain of difficulty. In the end, I tend to prefer discoverable code (hate angular because it is anti-discoverable), and when there are abstractions, prefer to keep them isolated and clean in purpose. It sometimes requires changes as requirements evolve, but then again, I've been in touch with enough people who've worked on projects I've started/built and haven't gotten any extreme WTFs about it.
  - hinkley 10y ago
    We had a good convention for our Angular project that wasn't too bad. Certainly a lot more discoverable than the rails project I worked on before it. I'd like to see a lot more formal work on discoverability. There are a lot of libraries being written by "smart" people who are behaving very stupidly right now.

abakker 10y ago

For many people in IT, generally not the Hacker News crowd, but the guys in the trenches of [insert corporation name here] with ops in many countries, The Money is NOT really the important thing. Risk mitigation by having a passthrough to the big IT vendors is what they are paying for specifically. I work in the IT consulting / business research space. In our surveys, "vendor viability" is a frequent concern, and the more critical the workload, the more weight is given to wondering whether the vendor will be around, unchanged, in the next 3 years. The risk mitigation factor from large vendors comes not from performance but from reliability. You can trust that old mainframe code will continue to be supported for many years. You can trust that your COBOL workload will be continue to run, and that the 20 years of updates, patches, and tweaks have made it reliable and predictable in a way that precludes rip and replace in all but the most extenuating circumstances. IT budgets tend to be governed by an 80/20 rule - maintenance vs innovation. Sometimes, its more of a 95/5 in practicality due to shrinking budgets. My experience says that the innovation side is drastically shifting away from these big vendors, but that the maintenance side has a lot more riding on it still.

oblio 10y ago
Well, thing is, Open Source is changing that proposition. As long as you're prepared to be conservative in your choices, something like Debian + Apache + OSS programming language will likely be around 20-40 years from now. When is the last time an OSS programming language that took off actually died? For example, even though it's not as popular Perl 5 is still used professionally in many environments and as far as I know the ecosystem actually went through a sort of renaissance a few years back. And these days I think it's even easier for OSS ecosystems to achieve critical mass and sustain themselves for decades since communication is easier (a lot more broadband internet in the world) and there's a lot more programmers around. Python, Ruby, PHP & co will probably be around long after I'm dead.
- abakker 10y ago
  Open source may perpetuate, but it is the on-call, active support that enterprises value. You can't exactly demand prompt action from the support forums, can you? Now maybe open source like Red Hat works that way, but it is very much the commercial terms and operating models that businesses are interested in. Again, for innovative new projects, this is changing.
  - DashRattlesnake 10y ago
    You can't necessarily demand prompt action from a big vendor like Oracle, either. Years ago, I worked on a project that used Oracle's BPM product. It was the only time I've worked on something where the team had a direct line to vendor support. When we had issues, all they ever seemed to do was ask for more logs, over and over again. I think they were hoping we'd give up and close our SRs. Luckily, I got off that project pretty quick. I later learned that they 1) rewrote their BPM product and did not offer a clear upgrade path to the new version, and 2) planned to end support for the old version in a few years. As a developer, the promise of vendor support doesn't ease my mind very much.
    - abakker 10y ago
      This is, of course, how oracle and others earned its reputation. These things and worse really happen. Obviously nobody wants this when they pay for better. I agree with another commenter that in the long run, it'll end up as OSS + support from a 3rd party consultant or vendor that is commercially aligned with your success. It has taken a very long time to convince most IT to behave like a branch of business that can create new value. Once that shift happens fully, we'll see the "keep the lights on at all costs" mindset change a bit in favor of truly measuring ROI and true total cost of ownership. For most large companies this has never been done.
- ubercode5 10y ago
  I agree. However one additional thing to keep in mind in the COTS vs FOSS is if there is some bug that affects the company and requires attention. The company doesn't generally have the engineers on staff to actually change that software, and there's no guarantee that the associated FOSS community will prioritize the bug. With a COTS solution, you can pick up the phone and call the support team. Generally my company chooses COTS over FOSS because they want guaranteed support even if it costs more. Note, some FOSS products also provide a strong support team to handle this exact thing, and in those cases they were usually the winner. Edit: Looks like abakker posted the same idea simultaneously.

nickpsecurity 10y ago

Don't forget the original reason: backward compatibility with complicated, mission-critical software on weird hardware nobody can legally clone. These businesses would have to port all their stuff to avoid IBM. They probably don't even know what it does. So, they stick with them to mitigate that risk.

scholia 10y ago
Plus, the time to transition off it is far longer than the next quarterly results. It may well be longer than the expected tenure of the CEO....
- nickpsecurity 10y ago
  Great point. They are short-term focused most of the time.

kens 10y ago

Being able to pass the buck to IBM if things go wrong was actually the theme of IBM's ads in 2001. In a typical ad, the CEO is getting blamed because the system is down / can't be upgraded. CEO: "And whose job is it to make sure all this stuff works the way it's supposed to?" Assistant: "That would be yours." Tagline: "And that's when it hits you, you are so ready for IBM.” (Of course I have to admit they were successful ads if I remember them 15 years later.) Links to the ads: http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/893 http://www.landscapesofcapital.com/items/show/888 http://www.landscapesofcapital.com/items/show/888

TeMPOraL 10y ago
Honest ads describing the business value directly. I like that. We could use more of that these days.
- toomuchtodo 10y ago
  Feels strikingly similar to patio11s blog post: http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro... Someone is delivering business value; whomever that is is the one who is getting paid.
  - TeMPOraL 10y ago
    Thanks for linking to that post, it's great! > Someone is delivering business value; whomever that is is the one who is getting paid. I was going to respond to this by pointing out some common exceptions, but patio11 actually covered this issue in his post too: "Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.)" EDIT: "Their [Salesforce's] motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)" Holy shit. That hits hard.

hinkley 10y ago

IBM Global Services seems to prefer hiring masochists. They will deploy the most complicated solution they can (almost) keep running and then ask for more time and materials when they miss. The FTEs at the company will want nothing to do with their Rube Goldberg sparkly bullshit and are all too happy to walk away and work on something else. Nobody can make XML impenetrable like IBMGS can. It is both fascinating and horrifying to watch.

tracker1 10y ago
This is part of why my initial and strong reaction against most "Enterprise" patterns and libraries... It often leads to so much indirection and complexity, that those working with it don't ever stop to thing "why" they are doing things a certain way, and when new people come in to support said solution, they face a mountain of difficulty. In the end, I tend to prefer discoverable code (hate angular because it is anti-discoverable), and when there are abstractions, prefer to keep them isolated and clean in purpose. It sometimes requires changes as requirements evolve, but then again, I've been in touch with enough people who've worked on projects I've started/built and haven't gotten any extreme WTFs about it.
- hinkley 10y ago
  We had a good convention for our Angular project that wasn't too bad. Certainly a lot more discoverable than the rails project I worked on before it. I'd like to see a lot more formal work on discoverability. There are a lot of libraries being written by "smart" people who are behaving very stupidly right now.