I have always really wondered how airline scheduling software works. Despite being pretty good with algorithms, I just have no idea how you'd make a system that's robust to weather and mechanical delays.
https://www.researchgate.net/publication/245236750_Airline_S...
https://www.sciencedirect.com/science/article/abs/pii/030504...
Another important component is disaster recovery. How quickly can the system recover from missed flights? What is the game plan for dealing with crews/airplanes that are out of place. How will they return to normal operations? Often times having a play book everyone is working from can lead to faster recoveries than dealing with each individual crisis as it happens, often with either too much micromanagement from leadership or too little coordination between departments. The play book generates a conciseness before the system is stressed.
Airline pax are probably not willing to pay for spare standby aircraft and flight and cabin crews at every airport every airline operates from.
Southwest’s original low-cost carrier business innovation was to run an all-737 fleet and make business-wide efforts to optimize for fast ground-turns, in order to get more flights out of each aircraft.
This is partly because airlines are still externalizing a good portion of the cost onto their customers, who need to rebook at short-term pricing. I'd love to see legislation to address this loophole.
Southwest used to be a budget-friendly airline with decent service. Now they're priced as much or more than the other major carriers with the added friction of having to book search flights only on their site.
4. Taxes/fees set by the city and the airport
> My airline ticket pays for ... All that for $99?
Well, if you'd split the Uber with a hundred passengers or so, it would have been a lot less than $149.
Compare the Uber (personalized, on-demand) transport to a private airplane more than a bus-in-the-sky.
The costs are fairly equivalent, oddly enough.
Good luck finding pilots to be “on-call” to fly anywhere in the world (and most commonly to small US cities) on a moments notice, with a jump seat return flight as their way home (after a night in a small city hotel).
Maintaining right sized and right placed operational buffers is an entire sub-category of within airline scheduling software/consultancy.
Those buffers will never cover a major disaster of course. They should let you hit your on-time and cancellation targets at smallest possible cost, though.
Airlines have crew on "reserve" at all times near bases to handle this problem. They are being paid to sit around and not actually work unless called in. Pilots love to try to get on the reserve list for obvious reasons.
I don't know how Southwest handles reserve, since they don't have "bases" like other airlines do.
The two classes of solutions that I considered where optimization solvers (see Gurobi Optimization for example), and meta-heuristics (see the book Metahueristics: From Design to Implementation). If I remember correctly, the people at Gurobi started at a previous company which was spun out of an airline, but I might be confused. All the algorithms in both classes of solutions are so nuanced that it can take years to begin to grasp how their strengths and weaknesses interact with your particular scheduling challenge, and how the way you formulate the problem interacts with the ability of the algorithm to solve it.
All that said, the real problem for me was a human one: If you produce a viable schedule X, the organization involved will always want to alter the rules to stretch the available resources to cover more, and simultaneously all the schedule staff will want more flexibility and nuance in expressing their preferences. You, as the author of scheduling software, are caught between them. Neither side is ever happy with the result.
I occasionally daydream about revisiting resident scheduling (I don't recommend it, the people who use your software leave every year, are not business oriented, and don't understand the complexity of the task until they've tried it on their own their first and only attempt). If I did, I would focus less on algorithms, and more on incentives to reconcile the tension between the organization, which wants to cover the most shifts with the fewest people at the cost of flexibility and preferences, and the staff, who want more flexibility and more preferences satisfied. I think that is the core problem at a business level.
Of course this all works best when you have more employee time than you need - it’ll never solve a true shortage.
It is not about code or algorithm quality, it is about procedural side of things -- how the organisation is "programmed" to respond to failures. I use the word "programmed" in a very broad sense -- for me setting up a paper checklist and being able to rely on people to follow it is the same as programming.
I suspect the main difference between airlines and banks is that banks can afford to throw money on the problem and just get things done regardless of how inefficiently.
Airlines are in the much worse position -- they were able to afford being inefficient and throwing money at the problem in the past but can't do it anymore. They work with old, outdated software that wasn't built with efficiency in mind but now don't have funds to change it and are forced to maintain what they have. This may also be the answer to why sometimes they just don't have capacity to react to problem and let it cascade to bring everything to a halt.
I can only speak about the forces that act on development teams and what could most likely in my mind explain the current situation.
You can poke around at the website for SlickOR (https://www.slickor.com/) to get an idea of the surface level work that goes into this.