I can’t see the WSJ article. None of the mainstream articles I could find discuss Unimatic in any detail, including the Reuters and NYT articles.
I figure that there has to be a forum out there where the nature of the software glitch is the focus, but I couldn’t find anything. If this story is AI generated, then I would very much like to read the sources it’s lifted from.
I did find a 2007 article discussing another Unimatic glitch that caused a stoppage which mentioned that the software dates from 1988:
> The computer system, known as Unimatic, is essential to the airline's operation, providing flight plans for pilots, updates on maintenance information and crew schedules, among other flight information. United jets worldwide cannot take off unless it is operating. The original Unimatic system dates back to at least 1988, but it is updated "all the time," United spokeswoman Robin Urbanski said.
Lots of boilerplate platitudes, especially towards the end of the story.
Some of the quotes appear to be fabricated. I can't find the "aviation analyst" tweet, and I'm pretty sure Maria Cantwell hasn't commented (unless it was video/audio only, and this is the only outlet that printed it). She's also no longer committee chair, being a member of the minority party in the Senate.
I only skimmed the article and didn't catch it at first, but a deeper read shows overuse of "rule of 3" which to be fair is also something that hacks do.
But also factual errors, such as quoting the supposedly Democrat chair of the Senate Committee on Commerce, Science, and Transportation.
It seemed unlikely that a Democrat was left in that post, and I googled it, and indeed they weren't.
A frustrating thing about paywalls on news sites is that they discourage linking to, because what's the point of linking to something if you don't know if the people you share the link with will be able to read it?
Which sadly leaves a gap in the market for AI slop. A few times recently I've tried to find a good news article to link to and had to chose between paywall sites, obvious AI slop or second-tier publications plastered with ads. I usually pick the third category.
The outages, attacks, and meltdowns will continue until business leadership stops thinking they know more about IT than their actual IT Engineers, and start supporting them accordingly.
Nearly doubling the CEO's salary annually seems like there would be enough money to increase the budget of whatever department/team needing to update the company's software while still increasing the CEO's salary by slightly less.
I think it is the opposite. If you want to double the pay of your CEO every year then you're going to have to find that money somewhere, so it reduces the money available for other things. 'Slightly less' was never an option. That's why employees are often expected to work unpaid overtime and yet management gets ridiculous bonuses. And if it all goes bust: the taxpayer will make up the difference. These are all asymmetrical bets, CEOs pocket the gains and society ends up with the losses.
Yes, that's the cynical way of looking at it. I'm looking at it from another perspective saying it's even worse/more offensive as they could have given the software team a $1million increase, while still giving the CEO a nearly doubled salary. There's nearly double then slightly less nearly double? No. It's just nearly doubled no matter what at those rates.
Yes, that 'nearly' bit is the bit that matters. If 16M becomes 15M that is terrible for the CEO, better save some more on software (say another $10M) and pocket that extra million bonus based on higher profits for the shareholders. Because that's how it usually works.
Again, you're just pointing out what happens. I'm pointing out a reasonable alternative that gets both points achieved. If you're telling me that a CEO that is currently making $15 million but just won't be able to make it on $29 million instead of $30 million is just going to get no sympathy from me. None. At. All. The fact that you are on here just trying to use current logic on why the alternative I've proposed is the better solution is just preposterous and puts you in the part of the problem camp.
Not shockingly schools do the same thing. I had to buy a copy of Lord of the Flies for my high schooler’s English class, but the Super Intendant, who didn’t meet his performance goals, received a bonus that could have covered a good portion the English curriculum materials.
I don't know, everywhere I look I see IT staff who don't care that much and can't problem solve. One possibility is that the IT leadership is herding cats very effectively and that things could be much much worse.
Oh, don’t get me wrong, I’ve worked in plenty of organizations where politics takes preference over outcomes, and every middle manager and senior leader wants their pound of flesh before allowing the objectively right thing to happen. These people then promote each other into higher tiers, because modern shareholders couldn’t care less about business effectiveness when share buybacks will juice their earnings - and the C-Suite’s.
It’s a perverted reward hack by leadership, and nobody - governments, shareholders, boardrooms, regulators, etc - seems to give a shit.
Plenty of 30-year old cars can and do drive across the country. The analogy makes me wonder: in 30 years will 30-year-old cars be able to drive across the country? I suspect 60-year-old cars will still be able to make that trip, but will the current crop of cars with all of the electronics and onboard computers? I suspect they won't, but that's an opinion formed by bias and not facts.
New software system can be even less reliable. The old/new distinction is not really important, what important is if reliability is a priority whoever owns the system. If there is a sustained effort to find and fix bug and other issues.
Usually, for the old/new distinction the architecture and used algorithm are relevant. Old software is often designed for less workload and lower complexity, and can easier get stuck in certain situations for which it wasn't designed.
For example, because of a holiday, the system would be confronted with more customers than it can handle, and any little change (like a failing plane or changing flight-staff) could lead to a crash of the system. IIRC this was a problem they had some years ago.
There are large checklists that need to be completed prior to take-off, not sure how much of this is automated now but if that is no longer possible you're just not going to take off.
The 777 has automated presentation of some relevant electronic checklists but these definitely are NOT automated because the whole point is human-attended verification.
I've written fuel estimation software for 747 cargo planes for one particular airline. Pilot would relay all of the info about plane identity, route, load and destination, fuel estimate would be computed externally and then be sent back through text message or voice call, pilot would then do his own check. This is really not something you want to get wrong, having multiple go-arounds or a late abort to an alternate for whatever reason should never result in a low fuel condition.
Obviously planes already leaving the gates are fueled up so that's most likely not the case here but that's one example of how those systems can be still integrated. Now, today - with far more computing power - it is very well possible that that whole system runs on the plane side, but the amount of external data and various exceptions and almanac information that was pulled in for those computations was pretty impressive. Most likely that sort of thing is now done on an iPad or something similar.
You're right -- that's what I was trying to say. There are all sorts of external systems tied into flight planning and operations, but once the plane has left the gate the plane should contain everything important already.
Thus, the only reason to recall a plane that's pushed back already would be to avoid problems that would occur only after it has landed. I would be surprised if the external systems were needed for the flight itself.
Even if the weight balance and loading are OK, it might be because other flights at the destination are being delayed at their gates and there won't be any gate for the aircraft when it arrives.
There are several regulatory, financial, and other business processes that must occur for commercial jets to fly. They can't just put fuel, pax, luggage, and crew on-board and send them on their way without recording data in various systems.
As long as the planes don't leave, the airline will know exactly where staff and equipment are: right where they were when the system broke. Once things get moving it becomes really complicated to figure out where everything is again.
During previous similar outages it has taken days to track down staff and equipment once the systems are up again. During this time delays and cancellations continue. It's possible the system is much faster to bootstrap given correct locations of things from the start.
You seem to know more about this than me, so what about the "aircraft movement logs" part? I would think it'd be hard to copy that to the pilots ahead of time, given you haven't logged it yet. (Or am I misunderstanding the type of "movement logs" here?)
But your other comment seems more likely: keep the people/equipment where they are to reduce the recovery time down the road.
I would guess that refers to entering records when the plane takes off and lands, to keep track of where it is. I.e. not information that would be used in flight -- at least not critical information!
Obviously air traffic control wants to know the exact location of the plane but they have radar and the airplane has a transponder for that purpose. I don't know if the airline cares so much, other than the estimated arrival time to account for delays.
It's no longer possible to not be a nightmare. Companies no longer employ devs for life to keep the system functional and up-to-date, and (most probably) no devs would stay in such a role for their entire career.
When nobody knows how the system works, it can only be a nightmare: they keep it barely functional with marginal patches, accumulating debt until it finally crashes in such a way that it can't be fixed, then a new team comes in, designs and builds a new system, patches some major flaws, and then leave, and the situation repeats for another 10 years.
> “This is exactly what happens when billion-dollar companies refuse to modernize,” one aviation analyst tweeted. “You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
While i sympathize, the world does rely on high quality 30+ year old software. I think it's time, as an industry, to stop seeing software as disposable and start designing for longevity.
A well maintained 30-year-old car can drive cross country. There's a big difference between car thats old with a ton of known defects that the driver works around and a car thats old that had it's defects fixed when they came up.
I'll second this. If the hardware it runs on isn't literally dying, and it doesn't have glaring security vulnerabilities (ex. especially air gapped systems), and it's still doing its job well, it's fine to let it do its thing.
That being said, the reality is that requirements change. Load changes. The world around the software changes. Systems need to be resilient, yet flexible enough to be maintained but not replaced over decades.
The skills required to maintain old codebases atrophy and we are barely training new people to do it so the skills pool shrinks. That means it doesn't get regular maintenance and it means disaster response in situations like this is slow and expensive.
Whilst it would be a major upheaval to switch to a clean room engineered implementation using 2025 best practices it would at least increase the talent pool that can work on it effectively.
There does likely come a point where it is cost effective to rebuild it both in reduced unplanned downtime and reduced maintenance costs.
Eventually, yes. But considering I worked at a place as recently as 2018 that had COBOL systems (and I know it's not unique in this regard, I'm confident those systems are still there too) from the 80s still running in production, I think that time horizon can be long.
If someone was on the original team writing this software when they were in their mid 20s then they are now in their 70s. If we don't start rebuilding some of this software soon there won't be anyone alive that understands it intimately in the way only an original author could.
That implies that no engineer who isn't (one of) the original author(s) cannot learn a system, to which I vehemently disagree. New engineers can be trained up on old systems and languages. The trouble is few want to because it typically ties their skillset heavily to a particular place of work, which is risky with current business culture.
Yes they can be trained up but a mechanic working on a car will never understand all of the undocumented design decisions that went into its production. They understand the what but not necessarily all of the why. Not only that but like you say it isn't a popular path meaning you aren't getting a broad (or deep) talent pool.
Welcome to the world of large legacy systems developed for and used by organizations that don't understand IT, and don't know that they don't understand IT.
The good news is there's always a contractor willing to promise the world and deliver something that doesn't work in 5-10 years. Your internal team, who could have finished the original job in a couple years if they'd been funded, will be the ones that end up making that delivered system actually work. But you'll tell everyone that it was the contractor's high quality output that did the trick, because saying they failed would hurt your career. In 15-30 years the system will get replaced and your successor will hear about how great <contractor> did the first time, and they'll get another shot at failure.
Exactly, we need to fund the people that have the knowhow now to either document it fully so it can be replaced later or to replace it now. Before that knowledge of building and operating it for so long is lost forever.
Some of United's own aircraft are over 30 years old [1]. If you can rely on a well-maintained 30+ year-old aircraft to fly you halfway accross the world I think you can rely on a similar-aged car to drive across the country.
It's not a given that you can't run an airline without legacy software. There are other airline companies that have modernized. Or newer ones that don't have to. And also companies selling software.
The issue here is United penny pinching for decades and now they are stuck with their in house created mess. The right move for them could be to buy one of the smaller upstarts with less issues and then just roll out whatever the small company is using and retire the creaking old mess that just failed them.
Any project to slowly modernize or update that is doomed to fail.
You see the same in the fintech world where small relatively new banks are running circles around their older competitors.
In the energy world, a British company called Octopus is actually licensing their platform (Kraken) to lots of energy companies around the world. One of the interesting things about companies that move to that platform is that they become a much more attractive target for M&A as well; because the job of migrating all the old customers is easier if both companies that are merging use the same, modern platform. That's the hard risky part of any merger. Apparently, in some cases the decision to move to Kraken was motivated as a preparation for this.
I'm mentioning this because that's something that could work in the airline industry. Or United can just zombie on for a few more years and then end up getting absorbed into some other, more successful company.
This stuff must be costing them at all levels in the company. I can't imagine it's very efficient. And the airline industry is pretty cut-throat at this point.
> The issue here is United penny pinching for decades
United* was one of the first major airlines to embrace modern tech. Their phone app was lightyears ahead of anyone else (I haven't revisited others in the past couple years, maybe other airlines caught up, I dunno)
When I use to spend way too much time on frequent flyer boards it seemed United was the only one spending money and embracing their tech center to innovate and update old systems, both software and hardware. It takes time to modernize, some changes also have to happen in all the many airports they do business in, not to mention all of the other fragmented systems they were working to better integrate. Since they are not a tech company I don't expect -- or want -- them to "move fast and break things".
Singling them out as penny pinching on tech is simply disingenuous.
*United & the *A group are my preferred airlines; bias is likely as well as a keen interest in what they are doing.
> You wouldn’t trust a 30-year-old car to drive cross-country.
The main difference between software and physical objects like cars is that they degrade with the passage of time (due to wear, corrosion, etc...). If we would magically be able to get a brand new 30-year-old car, it would make absolute sense to use one for a trip where reliability is paramount, as the failure modes of such a car are better understood compared to a brand new design, and can be mitigated.
Not only do i agree with you...i betcha that if/when the circa 1995 Toyota needs fixing, it would likely be easier and lower cost for someone to fix. ;-)
EDIT: My comment was specific to the 1995 toyota being a far simpler vehicle than current models, hence likely to be easier to fix....but, of course, the flipside is that potentially the older the vehicle, the likely less availability of certain parts.
I could fix pretty much any problem in that 1995 Toyota with tools that I have in my workshop. Unlike my 2009 car which requires a computer interface to do basic diagnostics and needs to be reprogrammed after many repairs. Let alone a 2020+ car (I've never had anything that new) that probably come with the hood welded closed.
And if I had enough disposable income to upgrade to something with side airbags, it’d compensate for my lack of trust in others on that drive too! (little tongue in cheek here, just voting for letting some money leave a bank account for reasonably modern safety features—even some ultra-high net worth folks seem not to care at all about those)
This only works with proper liability in place though, as unfortunely not everything is high quality, and cutting corners with offshoring and low skill devs is relatively common.
In aviation, reliability and known failure modes often beat bleeding-edge innovation, which can introduce new, untested risks. That said, if billion-dollar companies are refusing to update critical systems due to cost-cutting or complacency, that’s a serious problem. But the framing shouldn't be “old = bad”; it should be “unmaintained or unadapted = dangerous.”
Let’s hold companies accountable for safety practices, not just the calendar age of their fleets.
I would trust a 30-year-old plane to fly cross-country. That is, if the plane had been in constant use by a reputable carrier that properly maintained its aircraft.
Constant use is a negative for airplanes where metal fatigue builds up over use. eventualy it is cheaper to scrap an old plane than to replace every part that might be nearing end of life.
One of the fun facts about airplanes is that they are made almost entirely aluminum. And, if you go, look it up or talk to a mechanical engineer, you will understand that aluminum has no “fatigue limit“. That sounds like a good thing, but it’s not. Aluminum will always fail eventually no matter how small the load. It’s just intrinsic in the material.
I don't disagree with the point, but I question if that person is an aviation analyst, considering commercial airframes will go up to 30 years. As others in this thread have mentioned, it's about maintenance.
Except maintenance of software looks more like continuous architectural review and operation of an electrical grid. Calling it maintenance is a little narrow.
Unfortunately, you can only do so much of that. The hardware it runs on will become more capable and your customer will want to exploit it; the threat landscape will change and some guy in a basement outside Moscow will eventually find a way in.
Lots have changed in the last 30 years; ie: processors are much different now. There are better ways to do stuff now. Just because some people messes things in front-end development doesn't translate in one becoming a Luddite. The issue is that these upgrades usually end up in a catastrophe of some sort. But that's not an unavoidable fate.
In the old days, airlines and power grids were incentivized by regulations to spend money to build extra capacity into their systems to increase reliability in times of crisis.
Now they're all deregulated and they are highly incentivized by their shareholders not to overbuild capacity because it costs money and provides zero return on investment.
The upshot is that these industries operate with zero excess capacity. They work fine when everything goes as planned, but the minute something breaks or a storm happens, everything cascades into a steaming pile of shit.
In the case of the airlines, competitive market forces previously provided some incentive to invest in reliability but so many airline mergers have been allowed to happen that there's effectively no airline competition in the US any more.
I think i once heard this referred to as *delicapitalism* (or maybe it was deli-capitalism)...which, if recall correctly, means capitalist incentives, behaviors/actions that over time result in a more delicate world/ecosystem, etc. Something like that i think.
> “You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
Because software doesn't show wear. On the contrary - a system that's been running stable for 30 years probably has fewer bugs than one that's been running since last week. They are running old software on new computers.
Is United the one suing Microsoft and everyone and pointing fingers everywhere else about how CrowdStrike broke them worse than the other airlines last year?
There is the design of the system, and there is the implementation of that system. And the design of those systems are moving really, really slow in the aviation-world. Usually, any enhancement is done by attaching some auxiliary-system, or putting a layer on top, leading to layers of layers on top of layers, with the ugly core buried somewhere below. And even if you would rewrite those layers, or even the core itself in something modern, you still would be forced to handle the fundamental constraints of the whole design.
This country bailed out this industry multiple times in the past 20-25 years. Yet they continue to ignore investment in their own operations, and instead use it towards executive bonuses and stock buybacks.
Anybody else tired of this broken hypercapitalistic system that only serves to benefit the few? Enshittification is a symptom of a much more disgusting disease.
This is not a reliable source. Reeks of AI-generated text and fake author bios.
There are plenty of real sources for this story:
https://www.wsj.com/business/airlines/united-airlines-halts-...
https://www.nytimes.com/2025/08/06/business/united-airlines-...
https://www.reuters.com/world/us/united-airlines-flights-res...
I can’t see the WSJ article. None of the mainstream articles I could find discuss Unimatic in any detail, including the Reuters and NYT articles.
I figure that there has to be a forum out there where the nature of the software glitch is the focus, but I couldn’t find anything. If this story is AI generated, then I would very much like to read the sources it’s lifted from.
I did find a 2007 article discussing another Unimatic glitch that caused a stoppage which mentioned that the software dates from 1988:
https://www.aviationpros.com/home/news/10387920/computer-fai...
> The computer system, known as Unimatic, is essential to the airline's operation, providing flight plans for pilots, updates on maintenance information and crew schedules, among other flight information. United jets worldwide cannot take off unless it is operating. The original Unimatic system dates back to at least 1988, but it is updated "all the time," United spokeswoman Robin Urbanski said.
Probably HN needs an automated verification for quality/legitimacy before accepting a submission.
I’m ticked off that I got duped and would have welcomed a rejection. It sucks that lots of great HN comments got tied to an AI slop article.
Wow. I couldn’t tell. How did you find out that it may be AI generated.
1. Poor writing quality
2. Didn't exist before 2023 (https://web.archive.org/web/20250000000000*/allchronology.co...)
3. Faces on https://allchronology.com/about/ look like they were taken from https://thispersondoesnotexist.com/
Not only the faces look like AI, their URLs look the part: https://i0.wp.com/allchronology.com/wp-content/uploads/2023/...
100k-ai-faces-3-1.jpg :)
Nice catch!!
The bios does not name the other "renowned" maganizes either they supposedly worked at.
Fo me, a few additional things:
Lots of boilerplate platitudes, especially towards the end of the story.
Some of the quotes appear to be fabricated. I can't find the "aviation analyst" tweet, and I'm pretty sure Maria Cantwell hasn't commented (unless it was video/audio only, and this is the only outlet that printed it). She's also no longer committee chair, being a member of the minority party in the Senate.
It very closely follows the AP article on this - like they copied their homework but changed some words - https://apnews.com/article/united-airlines-flights-grounded-...
I only skimmed the article and didn't catch it at first, but a deeper read shows overuse of "rule of 3" which to be fair is also something that hacks do.
But also factual errors, such as quoting the supposedly Democrat chair of the Senate Committee on Commerce, Science, and Transportation.
It seemed unlikely that a Democrat was left in that post, and I googled it, and indeed they weren't.
But if the training data cut off before January 2025...
The footer is literally just "wordpress.com".
It didn't have a date or range of dates for the occurrence, which is weird.
A frustrating thing about paywalls on news sites is that they discourage linking to, because what's the point of linking to something if you don't know if the people you share the link with will be able to read it?
Which sadly leaves a gap in the market for AI slop. A few times recently I've tried to find a good news article to link to and had to chose between paywall sites, obvious AI slop or second-tier publications plastered with ads. I usually pick the third category.
The outages, attacks, and meltdowns will continue until business leadership stops thinking they know more about IT than their actual IT Engineers, and start supporting them accordingly.
"United Airlines CEO Scott Kirby earned $33.9 million in 2024, compared to $18.6 million in 2023, and $9.8 million in 2022"
https://onemileatatime.com/insights/highest-paid-airline-ceo...
He must know something, right? And it seems he knows more and more as the years go by.
Nearly doubling the CEO's salary annually seems like there would be enough money to increase the budget of whatever department/team needing to update the company's software while still increasing the CEO's salary by slightly less.
I think it is the opposite. If you want to double the pay of your CEO every year then you're going to have to find that money somewhere, so it reduces the money available for other things. 'Slightly less' was never an option. That's why employees are often expected to work unpaid overtime and yet management gets ridiculous bonuses. And if it all goes bust: the taxpayer will make up the difference. These are all asymmetrical bets, CEOs pocket the gains and society ends up with the losses.
Yes, that's the cynical way of looking at it. I'm looking at it from another perspective saying it's even worse/more offensive as they could have given the software team a $1million increase, while still giving the CEO a nearly doubled salary. There's nearly double then slightly less nearly double? No. It's just nearly doubled no matter what at those rates.
Yes, that 'nearly' bit is the bit that matters. If 16M becomes 15M that is terrible for the CEO, better save some more on software (say another $10M) and pocket that extra million bonus based on higher profits for the shareholders. Because that's how it usually works.
Again, you're just pointing out what happens. I'm pointing out a reasonable alternative that gets both points achieved. If you're telling me that a CEO that is currently making $15 million but just won't be able to make it on $29 million instead of $30 million is just going to get no sympathy from me. None. At. All. The fact that you are on here just trying to use current logic on why the alternative I've proposed is the better solution is just preposterous and puts you in the part of the problem camp.
Not shockingly schools do the same thing. I had to buy a copy of Lord of the Flies for my high schooler’s English class, but the Super Intendant, who didn’t meet his performance goals, received a bonus that could have covered a good portion the English curriculum materials.
He knows how to save on software development.
Beatings will continue until morale improves.
I don't know, everywhere I look I see IT staff who don't care that much and can't problem solve. One possibility is that the IT leadership is herding cats very effectively and that things could be much much worse.
Oh, don’t get me wrong, I’ve worked in plenty of organizations where politics takes preference over outcomes, and every middle manager and senior leader wants their pound of flesh before allowing the objectively right thing to happen. These people then promote each other into higher tiers, because modern shareholders couldn’t care less about business effectiveness when share buybacks will juice their earnings - and the C-Suite’s.
It’s a perverted reward hack by leadership, and nobody - governments, shareholders, boardrooms, regulators, etc - seems to give a shit.
Plenty of 30-year old cars can and do drive across the country. The analogy makes me wonder: in 30 years will 30-year-old cars be able to drive across the country? I suspect 60-year-old cars will still be able to make that trip, but will the current crop of cars with all of the electronics and onboard computers? I suspect they won't, but that's an opinion formed by bias and not facts.
New software system can be even less reliable. The old/new distinction is not really important, what important is if reliability is a priority whoever owns the system. If there is a sustained effort to find and fix bug and other issues.
Usually, for the old/new distinction the architecture and used algorithm are relevant. Old software is often designed for less workload and lower complexity, and can easier get stuck in certain situations for which it wasn't designed.
For example, because of a holiday, the system would be confronted with more customers than it can handle, and any little change (like a failing plane or changing flight-staff) could lead to a crash of the system. IIRC this was a problem they had some years ago.
> The old/new distinction is not really important, what important is if reliability
Agreed.
Frequently the actual issue related to these big system outages is cost-cutting/outsourcing/lack of maintenance.
There's a lot I don't understand with this, but why pull back airplanes which had already left the gate?
There are large checklists that need to be completed prior to take-off, not sure how much of this is automated now but if that is no longer possible you're just not going to take off.
These aren't a concern to the business processes.
The 777 has automated presentation of some relevant electronic checklists but these definitely are NOT automated because the whole point is human-attended verification.
Checklists are surely not pulled from an external system while the plane moves. That would be a recipe for disaster!
I've written fuel estimation software for 747 cargo planes for one particular airline. Pilot would relay all of the info about plane identity, route, load and destination, fuel estimate would be computed externally and then be sent back through text message or voice call, pilot would then do his own check. This is really not something you want to get wrong, having multiple go-arounds or a late abort to an alternate for whatever reason should never result in a low fuel condition.
Obviously planes already leaving the gates are fueled up so that's most likely not the case here but that's one example of how those systems can be still integrated. Now, today - with far more computing power - it is very well possible that that whole system runs on the plane side, but the amount of external data and various exceptions and almanac information that was pulled in for those computations was pretty impressive. Most likely that sort of thing is now done on an iPad or something similar.
You're right -- that's what I was trying to say. There are all sorts of external systems tied into flight planning and operations, but once the plane has left the gate the plane should contain everything important already.
Thus, the only reason to recall a plane that's pushed back already would be to avoid problems that would occur only after it has landed. I would be surprised if the external systems were needed for the flight itself.
> The system manages flight information like crew scheduling, weight-and-balance calculations, and aircraft movement logs
You wouldn't want to fly an airplane whose weight and balance has been miscalculated (or maybe properly calculated but can't vet if it has)
https://en.wikipedia.org/wiki/Cubana_de_Aviación_Flight_0972
https://en.wikipedia.org/wiki/Air_Midwest_Flight_5481
Even if the weight balance and loading are OK, it might be because other flights at the destination are being delayed at their gates and there won't be any gate for the aircraft when it arrives.
By the time they have pushed out the weights are already accounted for. It's part of the checklists that come before taxiing.
There are several regulatory, financial, and other business processes that must occur for commercial jets to fly. They can't just put fuel, pax, luggage, and crew on-board and send them on their way without recording data in various systems.
As long as the planes don't leave, the airline will know exactly where staff and equipment are: right where they were when the system broke. Once things get moving it becomes really complicated to figure out where everything is again.
During previous similar outages it has taken days to track down staff and equipment once the systems are up again. During this time delays and cancellations continue. It's possible the system is much faster to bootstrap given correct locations of things from the start.
I'm guessing the system handled sensitive/critical flight information:
>The system manages flight information like crew scheduling, weight-and-balance calculations, and aircraft movement logs.
The relevant critical information would probably be copied to pilots already. I suspect it has more to do with what happens after landing.
You seem to know more about this than me, so what about the "aircraft movement logs" part? I would think it'd be hard to copy that to the pilots ahead of time, given you haven't logged it yet. (Or am I misunderstanding the type of "movement logs" here?)
But your other comment seems more likely: keep the people/equipment where they are to reduce the recovery time down the road.
I would guess that refers to entering records when the plane takes off and lands, to keep track of where it is. I.e. not information that would be used in flight -- at least not critical information!
Obviously air traffic control wants to know the exact location of the plane but they have radar and the airplane has a transponder for that purpose. I don't know if the airline cares so much, other than the estimated arrival time to account for delays.
Do any of the major airlines have a software stack that isn't a legacy nightmare?
You would prefer a cutting-edge nightmare?
It's no longer possible to not be a nightmare. Companies no longer employ devs for life to keep the system functional and up-to-date, and (most probably) no devs would stay in such a role for their entire career.
When nobody knows how the system works, it can only be a nightmare: they keep it barely functional with marginal patches, accumulating debt until it finally crashes in such a way that it can't be fixed, then a new team comes in, designs and builds a new system, patches some major flaws, and then leave, and the situation repeats for another 10 years.
> “This is exactly what happens when billion-dollar companies refuse to modernize,” one aviation analyst tweeted. “You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
While i sympathize, the world does rely on high quality 30+ year old software. I think it's time, as an industry, to stop seeing software as disposable and start designing for longevity.
I don't sympathize.
A well maintained 30-year-old car can drive cross country. There's a big difference between car thats old with a ton of known defects that the driver works around and a car thats old that had it's defects fixed when they came up.
Yea, the car analogy is pretty good, actually. You have to maintain things, not just milk them until they catastrophically fail.
I'll second this. If the hardware it runs on isn't literally dying, and it doesn't have glaring security vulnerabilities (ex. especially air gapped systems), and it's still doing its job well, it's fine to let it do its thing.
That being said, the reality is that requirements change. Load changes. The world around the software changes. Systems need to be resilient, yet flexible enough to be maintained but not replaced over decades.
The skills required to maintain old codebases atrophy and we are barely training new people to do it so the skills pool shrinks. That means it doesn't get regular maintenance and it means disaster response in situations like this is slow and expensive.
Whilst it would be a major upheaval to switch to a clean room engineered implementation using 2025 best practices it would at least increase the talent pool that can work on it effectively.
There does likely come a point where it is cost effective to rebuild it both in reduced unplanned downtime and reduced maintenance costs.
Eventually, yes. But considering I worked at a place as recently as 2018 that had COBOL systems (and I know it's not unique in this regard, I'm confident those systems are still there too) from the 80s still running in production, I think that time horizon can be long.
If someone was on the original team writing this software when they were in their mid 20s then they are now in their 70s. If we don't start rebuilding some of this software soon there won't be anyone alive that understands it intimately in the way only an original author could.
That implies that no engineer who isn't (one of) the original author(s) cannot learn a system, to which I vehemently disagree. New engineers can be trained up on old systems and languages. The trouble is few want to because it typically ties their skillset heavily to a particular place of work, which is risky with current business culture.
Yes they can be trained up but a mechanic working on a car will never understand all of the undocumented design decisions that went into its production. They understand the what but not necessarily all of the why. Not only that but like you say it isn't a popular path meaning you aren't getting a broad (or deep) talent pool.
Welcome to the world of large legacy systems developed for and used by organizations that don't understand IT, and don't know that they don't understand IT.
The good news is there's always a contractor willing to promise the world and deliver something that doesn't work in 5-10 years. Your internal team, who could have finished the original job in a couple years if they'd been funded, will be the ones that end up making that delivered system actually work. But you'll tell everyone that it was the contractor's high quality output that did the trick, because saying they failed would hurt your career. In 15-30 years the system will get replaced and your successor will hear about how great <contractor> did the first time, and they'll get another shot at failure.
Exactly, we need to fund the people that have the knowhow now to either document it fully so it can be replaced later or to replace it now. Before that knowledge of building and operating it for so long is lost forever.
Some of United's own aircraft are over 30 years old [1]. If you can rely on a well-maintained 30+ year-old aircraft to fly you halfway accross the world I think you can rely on a similar-aged car to drive across the country.
[1]: https://www.planespotters.net/airframe/boeing-767-300-n641ua...
It's not a given that you can't run an airline without legacy software. There are other airline companies that have modernized. Or newer ones that don't have to. And also companies selling software.
The issue here is United penny pinching for decades and now they are stuck with their in house created mess. The right move for them could be to buy one of the smaller upstarts with less issues and then just roll out whatever the small company is using and retire the creaking old mess that just failed them.
Any project to slowly modernize or update that is doomed to fail.
You see the same in the fintech world where small relatively new banks are running circles around their older competitors.
In the energy world, a British company called Octopus is actually licensing their platform (Kraken) to lots of energy companies around the world. One of the interesting things about companies that move to that platform is that they become a much more attractive target for M&A as well; because the job of migrating all the old customers is easier if both companies that are merging use the same, modern platform. That's the hard risky part of any merger. Apparently, in some cases the decision to move to Kraken was motivated as a preparation for this.
I'm mentioning this because that's something that could work in the airline industry. Or United can just zombie on for a few more years and then end up getting absorbed into some other, more successful company.
This stuff must be costing them at all levels in the company. I can't imagine it's very efficient. And the airline industry is pretty cut-throat at this point.
> The issue here is United penny pinching for decades
United* was one of the first major airlines to embrace modern tech. Their phone app was lightyears ahead of anyone else (I haven't revisited others in the past couple years, maybe other airlines caught up, I dunno)
When I use to spend way too much time on frequent flyer boards it seemed United was the only one spending money and embracing their tech center to innovate and update old systems, both software and hardware. It takes time to modernize, some changes also have to happen in all the many airports they do business in, not to mention all of the other fragmented systems they were working to better integrate. Since they are not a tech company I don't expect -- or want -- them to "move fast and break things".
Singling them out as penny pinching on tech is simply disingenuous.
*United & the *A group are my preferred airlines; bias is likely as well as a keen interest in what they are doing.
> You wouldn’t trust a 30-year-old car to drive cross-country.
The main difference between software and physical objects like cars is that they degrade with the passage of time (due to wear, corrosion, etc...). If we would magically be able to get a brand new 30-year-old car, it would make absolute sense to use one for a trip where reliability is paramount, as the failure modes of such a car are better understood compared to a brand new design, and can be mitigated.
Also I would totally trust a 1995 Toyota to drive cross-country.
Not only do i agree with you...i betcha that if/when the circa 1995 Toyota needs fixing, it would likely be easier and lower cost for someone to fix. ;-)
EDIT: My comment was specific to the 1995 toyota being a far simpler vehicle than current models, hence likely to be easier to fix....but, of course, the flipside is that potentially the older the vehicle, the likely less availability of certain parts.
I could fix pretty much any problem in that 1995 Toyota with tools that I have in my workshop. Unlike my 2009 car which requires a computer interface to do basic diagnostics and needs to be reprogrammed after many repairs. Let alone a 2020+ car (I've never had anything that new) that probably come with the hood welded closed.
Sadly, you're 100% correct!
Indeed.
And if I had enough disposable income to upgrade to something with side airbags, it’d compensate for my lack of trust in others on that drive too! (little tongue in cheek here, just voting for letting some money leave a bank account for reasonably modern safety features—even some ultra-high net worth folks seem not to care at all about those)
This was my first thought as well. Making software like a 1995 Toyota would be an admirable and useful thought process.
https://en.wikipedia.org/wiki/The_Toyota_Way
I'd drive my 1995 Toyota anywhere.
I wouldn't trust any car to fly a plane, tbh.
I bet the problem is not the 30+ year old software, but the less than 30 year old crap they've dumped on top of it.
Also, how old are the planes?
Also slightly ironic considering United has several planes that are themselves 30+ years old.
See Boeing 767-300:
* https://www.planespotters.net/airline/United-Airlines
* https://simpleflying.com/united-airlines-oldest-aircraft-202...
This only works with proper liability in place though, as unfortunely not everything is high quality, and cutting corners with offshoring and low skill devs is relatively common.
In aviation, reliability and known failure modes often beat bleeding-edge innovation, which can introduce new, untested risks. That said, if billion-dollar companies are refusing to update critical systems due to cost-cutting or complacency, that’s a serious problem. But the framing shouldn't be “old = bad”; it should be “unmaintained or unadapted = dangerous.”
Let’s hold companies accountable for safety practices, not just the calendar age of their fleets.
I would trust a 30-year-old plane to fly cross-country. That is, if the plane had been in constant use by a reputable carrier that properly maintained its aircraft.
Constant use is a negative for airplanes where metal fatigue builds up over use. eventualy it is cheaper to scrap an old plane than to replace every part that might be nearing end of life.
One of the fun facts about airplanes is that they are made almost entirely aluminum. And, if you go, look it up or talk to a mechanical engineer, you will understand that aluminum has no “fatigue limit“. That sounds like a good thing, but it’s not. Aluminum will always fail eventually no matter how small the load. It’s just intrinsic in the material.
This is like having software (and sometimes hardware) that is so old that most of the mechanics who know how to maintain the software has retired.
I don't disagree with the point, but I question if that person is an aviation analyst, considering commercial airframes will go up to 30 years. As others in this thread have mentioned, it's about maintenance.
Except maintenance of software looks more like continuous architectural review and operation of an electrical grid. Calling it maintenance is a little narrow.
Unfortunately, you can only do so much of that. The hardware it runs on will become more capable and your customer will want to exploit it; the threat landscape will change and some guy in a basement outside Moscow will eventually find a way in.
Lots have changed in the last 30 years; ie: processors are much different now. There are better ways to do stuff now. Just because some people messes things in front-end development doesn't translate in one becoming a Luddite. The issue is that these upgrades usually end up in a catastrophe of some sort. But that's not an unavoidable fate.
How do you design for longevity when the idiots in the C-level executives don’t give a shit and only care about quarterly numbers?
Stop trying to put blame on labor.
"You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
Why would a 30-year-old car be flying a plane? That makes no sense.
Sounds like they got Zucker, Abrahams and Zucker to write this article
I would love to see a ZAZ take on Tesla's AutoPilot.
In the old days, airlines and power grids were incentivized by regulations to spend money to build extra capacity into their systems to increase reliability in times of crisis.
Now they're all deregulated and they are highly incentivized by their shareholders not to overbuild capacity because it costs money and provides zero return on investment.
The upshot is that these industries operate with zero excess capacity. They work fine when everything goes as planned, but the minute something breaks or a storm happens, everything cascades into a steaming pile of shit.
In the case of the airlines, competitive market forces previously provided some incentive to invest in reliability but so many airline mergers have been allowed to happen that there's effectively no airline competition in the US any more.
> incentivized by their shareholders
Those shareholders are their actual customers. Air traffic is just an annoying necessity.
I think i once heard this referred to as *delicapitalism* (or maybe it was deli-capitalism)...which, if recall correctly, means capitalist incentives, behaviors/actions that over time result in a more delicate world/ecosystem, etc. Something like that i think.
"Capitalism" seems to be like "punk", a word one could slap onto anything. Fragility is just the natural result of any optimization.
> “You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
Because software doesn't show wear. On the contrary - a system that's been running stable for 30 years probably has fewer bugs than one that's been running since last week. They are running old software on new computers.
Is United the one suing Microsoft and everyone and pointing fingers everywhere else about how CrowdStrike broke them worse than the other airlines last year?
Delta was the one that was pointing the finger at MS.
"You wouldn’t trust a 30-year-old car to drive cross-country. Why are we trusting it to fly planes?”
Just wait till I find out how old this SABRE is!
https://en.m.wikipedia.org/wiki/Sabre_(travel_reservation_sy...
I think that SABRE has been rewritten at least twice, though the last time could have been over 30 years ago.
I interviewed to work on the C version about 35 years ago.
There is the design of the system, and there is the implementation of that system. And the design of those systems are moving really, really slow in the aviation-world. Usually, any enhancement is done by attaching some auxiliary-system, or putting a layer on top, leading to layers of layers on top of layers, with the ugly core buried somewhere below. And even if you would rewrite those layers, or even the core itself in something modern, you still would be forced to handle the fundamental constraints of the whole design.
This country bailed out this industry multiple times in the past 20-25 years. Yet they continue to ignore investment in their own operations, and instead use it towards executive bonuses and stock buybacks.
Anybody else tired of this broken hypercapitalistic system that only serves to benefit the few? Enshittification is a symptom of a much more disgusting disease.