4 ms·

Via reddit/r/bestof https://old.reddit.com/r/flying/comments/zw5lsl/southwest_pilots_hows_it_going/j1tne9z/ https://old.reddit.com/r/flying/comments/zw5lsl/sout

by mtmail 4y ago

Via reddit/r/bestof https://old.reddit.com/r/flying/comments/zw5lsl/southwest_pilots_hows_it_going/j1tne9z/ https://old.reddit.com/r/flying/comments/zw5lsl/southwest_pi... "So the storm came and it impacted ground ops so bad that many many crews were now “unaccounted” for and the system in place couldn’t keep up. Then it happened for several more days. By Xmas evening the CS department had essentially reached the inability to do anything but simple, one off assignments. And to make matters worse, the phone system was updated not too long ago and it was not working well." "I used to work for a large company trying to fill the void [huge gap in the market for good aviation scheduling software], and our software was damn good too. SW was one of the airlines interested, we would demo it exactly like the scenario today, but it was "too expensive" and they stayed on their homebuilt stuff."

hrunt 4y ago
> "I used to work for a large company trying to fill the void [huge gap in the market for good aviation scheduling software], and our software was damn good too. SW was one of the airlines interested, we would demo it exactly like the scenario today, but it was "too expensive" and they stayed on their homebuilt stuff." This is a common situation in any industry. A company has a solution it self-developed in its infancy to support itself, and as it grows, it comes to rely very heavily on this software. At a certain point, everyone involved with the software -- from the developers to the users to the customers -- knows that it is not on par with third-party software developed by a team dedicated to all of its potential use-cases and pitfalls, but it is very difficult for the business to replace it because the ongoing cost is a relatively low maintenance cost, and the replacement cost is a one-time, relatively high purchase fee (with, usually, a similar if not higher ongoing maintenance cost). So the immediate reaction is to stay with the low ongoing cost, even though everyone "knows" that the long-term benefits of the third-party solution far outweigh the financial savings of keeping the in-house solution, whether those benefits might be avoiding a national week-long service outage or something simpler, like the ability for staff to get more done in other areas of the company that need attention when getting larger. I have been there. It can be very difficult to make the financial case when the future benefits are somewhat speculative or intangible. Accountants tend to devalue those benefits, relative to the hard numbers they already have. It does not help that system replacement projects often go over budget and introduce other problems that cost more money. Replacing home-grown systems is hard because they are not just software replacements; they typically also require reworking business processes.
- mark-r 4y ago
  The existing solution needn't even be home built. I worked for a company that replaced one ERP system with another. It was a medical manufacturer, so in many cases the new system had to warp to the established government mandated business practices. Over time and over budget, you bet - they weren't finished with the transition when I left.
- rektide 4y ago
  > and the replacement cost is a one-time, relatively high purchase fee (with, usually, a similar if not higher ongoing maintenance cost) i'd wager complex scheudling software is probably licensed, not sold outright. many many millions a year to license. but yeah, lot of good factors you cite.
- grantc 4y ago
  It can be cost-driven, but it's just as likely to be complexity-gated (w/ cost frequently being implementation driven and a proxy for complexity). The cost comes from actually unwinding a gnarly legacy system (that may be less than well understood) and making the successor system work. Also, Gall's law has entered the chat: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
  - kjellsbells 4y ago
    You just described the last 30 years of the US phone network.
  - unwise-exe 4y ago
    [dead]
  - cpeterso 4y ago
    For folks interested in legacy software systems (and managing the teams managing these systems), I highly recommend Marianne Bellotti's "Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)". The author worked at the United States Digital Service. https://nostarch.com/kill-it-fire https://nostarch.com/kill-it-fire

by mtmail 4y ago

hrunt 4y ago

> "I used to work for a large company trying to fill the void [huge gap in the market for good aviation scheduling software], and our software was damn good too. SW was one of the airlines interested, we would demo it exactly like the scenario today, but it was "too expensive" and they stayed on their homebuilt stuff." This is a common situation in any industry. A company has a solution it self-developed in its infancy to support itself, and as it grows, it comes to rely very heavily on this software. At a certain point, everyone involved with the software -- from the developers to the users to the customers -- knows that it is not on par with third-party software developed by a team dedicated to all of its potential use-cases and pitfalls, but it is very difficult for the business to replace it because the ongoing cost is a relatively low maintenance cost, and the replacement cost is a one-time, relatively high purchase fee (with, usually, a similar if not higher ongoing maintenance cost). So the immediate reaction is to stay with the low ongoing cost, even though everyone "knows" that the long-term benefits of the third-party solution far outweigh the financial savings of keeping the in-house solution, whether those benefits might be avoiding a national week-long service outage or something simpler, like the ability for staff to get more done in other areas of the company that need attention when getting larger. I have been there. It can be very difficult to make the financial case when the future benefits are somewhat speculative or intangible. Accountants tend to devalue those benefits, relative to the hard numbers they already have. It does not help that system replacement projects often go over budget and introduce other problems that cost more money. Replacing home-grown systems is hard because they are not just software replacements; they typically also require reworking business processes.

mark-r 4y ago
The existing solution needn't even be home built. I worked for a company that replaced one ERP system with another. It was a medical manufacturer, so in many cases the new system had to warp to the established government mandated business practices. Over time and over budget, you bet - they weren't finished with the transition when I left.
rektide 4y ago
> and the replacement cost is a one-time, relatively high purchase fee (with, usually, a similar if not higher ongoing maintenance cost) i'd wager complex scheudling software is probably licensed, not sold outright. many many millions a year to license. but yeah, lot of good factors you cite.
grantc 4y ago
It can be cost-driven, but it's just as likely to be complexity-gated (w/ cost frequently being implementation driven and a proxy for complexity). The cost comes from actually unwinding a gnarly legacy system (that may be less than well understood) and making the successor system work. Also, Gall's law has entered the chat: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
- kjellsbells 4y ago
  You just described the last 30 years of the US phone network.
- unwise-exe 4y ago
  [dead]
- cpeterso 4y ago
  For folks interested in legacy software systems (and managing the teams managing these systems), I highly recommend Marianne Bellotti's "Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones)". The author worked at the United States Digital Service. https://nostarch.com/kill-it-fire https://nostarch.com/kill-it-fire