Case study? Where? This "analysis" is closer to: it broke therefore it was brittle.
What we'll eventually find out this: based on some investment / return, the system did what it was designed to do based on some set of profit-deliverable assumptions.
Southwest executives understood that they were running on borrowed time with their crew scheduling software. At the very least an alternate or secondary process should have been in place.
The US air traffic control network is a good example. In case of a primary failure, there exist secondary procedures adopted from before air traffic control radar was common.
Southwest had an awful week, no doubt. But while it is easy to jump on the bandwagon and point fingers at a train wreck, at the end of the day LUV has a market cap approximately equal to United and American combined, and just a touch below Delta's. While the 3 majors have all declared bankruptcy at some point in the past 20 years, LUV never has. It also recently re-instated its dividend, which the majors haven't done yet. The majors each rely on a mini-monopoly by dominating 3-4 hubs each where they have enormous pricing power (except when a JetBlue, Spirit, etc comes in to compete) while LUV is often reactionary, operating a large number of unique, convenient routes that are underserved by the majors and the hub-and-spoke model.
Of course LUV should spend some money and modernize their systems but a) there's probably not a single software developer who understands the full scope and difficulty of such a project (meaning you should dismiss any comment that sounds like "why don't they just...") and b) without hubs, what they are already executing every single normal day is likely a lot more complicated than what the majors ever attempt.
This isn't an excuse, or a waving off of LUV's serious issues. It's perspective, I guess.
It's a good perspective for sure. I also understand that the non-hub p2p model exposes LUV in ways it doesn't for other airline carriers.
I gotta say tho - it is extremely tiring to keep seeing "shit happened because bean-counting C-level decided to over-prioritize profits over product and the company rots from within" motif.
Happened with Boeing, GE, and now Southwest I guess.
As long as Southwest continues to allow not just one, but two free checked bags per person, I can't entirely buy into the "bean-counters maximizing profits" theme. They could EASILY start charging per bag, or at least for the second bag. Or for Wanna Get Away fares. But they don't. Ever. For anyone.
I think what the other commenter meant by bean counting CEO, is that they don't prioritize resilience and quality in their operations. In Boeing's case, they deprioritized the engineering culture with intense timelines and punished people who would want to take the time to ensure quality. This led to meeting targets, higher profits and reduced costs, but increased risk.
In Southwest's case, it seems (from what I've read) that over the past two decades of CEO's, they didn't prioritize improving their backend software systems. Which seems similar to Boeing: improve profits, but increase risk.
The problem is that IT investment is like buying insurance. You are paying now to avoid trouble later.
As an executive, I don't give one iota of damn about cost later past 36 months but I care a lot about cost in my budget now. Therefore, I will schedule any IT "upgrades" well past my 36 month point and leave it on somebody else's balance sheet.
Many people at Southwest knew this was coming. Southwest had various meltdowns before Covid that were flagging this. Covid gave them a reprieve. However, now that travel is ticking up, the problems came home to roost with a vengeance.
I don't think the blog article was really meant to be a topic for discussion -- it wasn't really a case study in brittleness per se: it was just some off the cuff opinions and musings that I don't think the author meant to be submitted as an HN article.
If we really want to analyze the Southwest failure from a complex systems perspective, Richard Cook's principles lend themselves to more substantive discussions.
9 comments
[ 3.2 ms ] story [ 33.8 ms ] threadWhat we'll eventually find out this: based on some investment / return, the system did what it was designed to do based on some set of profit-deliverable assumptions.
Then there was a black swan.
The US air traffic control network is a good example. In case of a primary failure, there exist secondary procedures adopted from before air traffic control radar was common.
Of course LUV should spend some money and modernize their systems but a) there's probably not a single software developer who understands the full scope and difficulty of such a project (meaning you should dismiss any comment that sounds like "why don't they just...") and b) without hubs, what they are already executing every single normal day is likely a lot more complicated than what the majors ever attempt.
This isn't an excuse, or a waving off of LUV's serious issues. It's perspective, I guess.
I gotta say tho - it is extremely tiring to keep seeing "shit happened because bean-counting C-level decided to over-prioritize profits over product and the company rots from within" motif.
Happened with Boeing, GE, and now Southwest I guess.
https://archive.is/5vXIZ https://www.reddit.com/r/SouthwestAirlines/comments/zxg6op/t...
In Southwest's case, it seems (from what I've read) that over the past two decades of CEO's, they didn't prioritize improving their backend software systems. Which seems similar to Boeing: improve profits, but increase risk.
As an executive, I don't give one iota of damn about cost later past 36 months but I care a lot about cost in my budget now. Therefore, I will schedule any IT "upgrades" well past my 36 month point and leave it on somebody else's balance sheet.
Many people at Southwest knew this was coming. Southwest had various meltdowns before Covid that were flagging this. Covid gave them a reprieve. However, now that travel is ticking up, the problems came home to roost with a vengeance.
If we really want to analyze the Southwest failure from a complex systems perspective, Richard Cook's principles lend themselves to more substantive discussions.
https://how.complexsystems.fail/