[mtmail]

Via reddit/r/bestof 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]

> "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.

[grantc]

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.

[cpeterso]

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

[kjellsbells]

You just described the last 30 years of the US phone network.

[marcus0x62]

> It does not help that system replacement projects often go over budget and introduce other problems that cost more money.

If justifying speculative future benefits to the CFO is the first strike against these sorts of projects, this is the second strike — the operations team has likely been burned by failed IT modernization projects before. How hard are you going to fight for something you aren’t 100% sure is even going to work?

[CoastalCoder]

> How hard are you going to fight for something you aren’t 100% sure is even going to work?

Tangent: maybe I'm just tired of this industry, but I have trouble imagining myself "fighting" to convince a CxO to do anything that benefits the company but not me.

My attitude is like, here's my advice and reasoning. Listen to me or don't. I'm not going to participate in some budgetary cage match just because the CxO likes drama.

I wonder if this shows my age :)

[rektide]

> 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.

[srmarm]

> 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

Although it's also a regular occurrence that the replacement of an old 'just works' system brings about a week of downtime, mass disruption and still basic features missing.

[mark-r]

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.

[markus_zhang]

Onr big problem of this kind of upgrades is few in the trench would be able to provide feedback or recommendation. It would be lucky if some managers in trench gets consulted.