But even the stripped version is way way too much for an app like this. I can imagine it's layers upon layers of poor, bad and terrible architectural and organizational decisions.
I’d like to approach this differently, and think about what it would have cost United Airlines to do it “the right way”, versus what value it brings them.
I’m the first to say that this utter bloat is terrible, but most people aren’t really bothered by it. And I can only imagine that they outsourced their app development completely and like to keep costs low.
From that perspective, it’s probably much more pragmatic to fix the problem at the root(s): Apple may want to mandate stripped binaries (I think this is also what RPM does by default, just strip everything), and/or god forbid these Electron-type frameworks should make things more efficient.
Contrarian opinion here; I understand their logic. It looks like a rational trade-off that the engineers have done.
Increase developer productivity at the expense of hardware.
In this case, engineering is more expensive than hardware (because hardware is at the cost of the user).
The smallest iPhone starts at 128 GB.
This means the application takes 500/128000 blocks: 0.4% of the total device storage.
Over time, the iPhones are going to have more and more storage.
So, if app size is a problem, and over time, the problem is fixed by itself, why would you invest engineering resources into that ?
You have X engineers with Y amount of working hours, and tons of important things to do.
Yes, probably fixing a problem that brings a low amount of complains from end users at the cost of productivity isn't high on the list for them.
This bizarre reasoning puzzles and infuriates me so much. The linked post shaves more than 40% of an app's size in 5 minutes, by doing nothing but being curious about the half-gigabyte app and knowing how to use a couple of tools.
This is not a case of "I have plenty of water so let the kids splash some in the playground to have fun", this is a case of "I have plenty of water so I will load 10000 liters in a truck and drive 1000 kilometers and back just to dump them in the desert for no fucking reason".
Seriously, 5 minutes? I spend more than that in the bathroom. How many 5-minutes is a "Scrum standup"? a "progress meeting" ? a <insert bullshit corporate activity here>? Do all of those things not waste the engineers' time?
I'm trying to imagine the world if every profession and craft tried to justify this disgustingly irresponsible mindset :
"
- This combustion engine uses an inferior injection mechanism that wastes 40% more fuel compared to latest...
= Don't waste my time!!! I have more important things to worry about.
-.... It would take 5 minutes
to fix
= Customers don't notice the fuel consumption anyway, so that means robbing them out of money with inferior engineering is okay. Now hurry up, we'll miss the daily 3-hours progress meeting.
"
If only Donald Knuth knew what " Forget about the small efficiencies" would be used to justify.
I share your feeling. Day by day I feel more guilty of belonging to that industry because of the laziness, sloppiness, negligence, acceptance of spying, of dark patterns, etc, and I do not disclose what I'm doing for a living more readily than I would if I worked for some mafia.
There’s a parable about a mechanic that spends a couple minutes finding a screw to tighten and charges a large sum once they’re done. It was a few minutes of work for them, yes, but it took a lifetime for them to get to the point where it’s a few minutes of work. Of course, the situation here is not quite that extreme, but acquiring the skills needed to know where problems are is uncommon and nontrivial.
There’s probably an observability bias here. It could be that the app sizes would be 3x worse, if no one ever tried. You would never know, because you only see the app sizes after people have done the work.
This is in response to someone who’s clearly infuriated by a wide variety of inefficiencies they see. The point is, no one is praising the people who do optimize their <whatever> because you would never know it was even an issue that got solved.
Oh, nobody is praising the other apps? That's true but these are very basic expectations. If you're a chef and you burn every tenth meal then either you or your management are making very bad decisions, even if the other 90% are fine. And app and website bloat seems to be significantly more widespread than that.
The idea isn't that nobody ever tries, it's that the typical amount of trying is really bad.
When eating a meal, how the meal tastes (burnt) is at least #2 on my top priorities (just below whether it will lead to illness). When consuming an app though, bundle size has got to be at least #5, far below something like "Does the app do what I want?" and "Is it performant" etc.
While it would be nice if everything was optimized, it's really not comparable to a meal tasting good, since that's basically the main reason to have a meal in the first place. Most people don't care about bundle size, especially when it's tens of megabytes versus gigabytes.
> the typical amount of trying is really bad
Again, we really have no way of measuring just how bad it could be. IMO it feels like everything could be way, way worse.
> When consuming an app though, bundle size has got to be at least #5, far below something like "Does the app do what I want?" and "Is it performant" etc.
This much space is a pretty big cost. It represents wasted dollars, or shuffling data, or not getting it downloaded in time, or not having room for the pictures you want, etc.
> Again, we really have no way of measuring just how bad it could be.
If five minutes did this much, and this is within a couple orders of magnitude of typical, then we can conclude that the typical effort is really bad.
How much worse it could be might be an interesting thought experiment, but doesn't affect the above conclusion.
It could probably get almost infinitely bad if there was zero cleanup effort. But that's the difference between 1/10 effort and 2/10 effort. If I'm demanding 6/10 effort for a professional product, the difference between 1/10 and 2/10 doesn't matter to me.
The smallest iPhone sold now is 128 GB. The iPhone 5C, sold in 2015, had 8 GB internal storage with no expansion options. 439 MiB is a full 5% of the total storage capacity of the iPhone 5C, completely ignoring the amount reserved for the OS that's completely unusable to the user.
The logic used here hurts lower-income people and contributes to climate change by encouraging poor use of device resources -> shorter device lifetimes -> more e-waste and wasted energy.
And even 2 of those 8 GiB were taken up by the OS. So that leaves just 6 GiB. Now we’re already at 7%. That’s valuable storage that you cannot use to fill with holiday pictures.
Perhaps not but everyone saying this is what kills accessibility for those who need it. This is the same argument made by companies to not support deaf/blind people.
Requirements are often above average in some dimensions and below average in others.
If we optimize for people who are wealthy, always in high bandwidth areas with new phones, etc etc soon we will have left most people behind.
I don't know if you're trying to make a point about global living standards (irrelevant) or the non-necessity of air travel (true, but also irrelevant), but the fact is that budget airlines have existed for decades, and are often comparable in price to a bus trip.
For a lot of trips, Amtrak is about the same as flying. Looking at a round trip from NYC to Chicago, on the arbitrary dates of March 26 to April 9, Amtrak costs $180 while Kayak shows the cheapest flights at $159. Of course, Amtrak takes much longer (20 hours) but is less hassle, and at that price the flight only lets you take one carry-on while Amtrak lets you bring two checked bags and two carry-ons. Adding checked bags will add $60 for the first and $80 for the second. Amtrak is also better for the environment if that matters to you, and the price difference is about the same as the cost of the carbon offset for the flight.
Overall, choosing Amtrak or flying is perfectly reasonable in different situations. Amtrak could definitely be improved a lot though!
NYC to Chicago probably has a decent customer base to support that price point. For amusement, try Miami/Seattle via Amtrak. It's possible, since I looked up the route [1]. One week transit time one way, at $2,000 (I don't recall if the price was round trip or just one way). And trying to work on the train was fun (too "swishy" to use the computer: http://boston.conman.org/2015/08/05.2). Totally not worth it for me. Sadly [2].
[1] For reference, I live near Miami (technically, I live in Boca Raton, but Miami is "close enough" at this scale). The company I work for is based in Seattle. I refuse to fly anymore for a variety of reasons.
I don't think I kept it, but a couple of years ago I made a video of a £1 coin (as thick as two US pennies) balanced in a shallow groove in the table on a long distance train in Denmark. It was about 30km before it fell over.
(But maintaining the track to this quality would be even more expensive if there was as much freight on it as tracks in the USA carry.)
That's somewhat a different definition than the comment I was replying to. There are plenty of people who may want to fly somewhere who aren't going to upgrade their phone to the latest and greatest every two years (which is what the comment above was implying: that since flying is supposedly a 'luxury' item it can be assumed that the customers have the latest and greatest phones).
Southwest is not really the equivalent of Ryan. Spirit airlines has plenty of $22.22 flights (for two's-day, I guess), glancing at their page today. This includes e.g. Chicago to Tampa, Texas to NJ, and other flights longer than most European flights.
They look very much in the style of Ryanair with the garish website. $22 for three hours (Boston-Miami) is priced between the two Ryanair flights, so I expect the "service" is similar.
I'm sure the average distance of a flight within Europe is lower than in the USA, since the USA is a bit empty in the middle and Europe has more water in the way, but routes like Scandinavia to the Mediterranean (Stockholm to Zagreb is 3½ hours and $14), or Britain to eastern Europe (London - Cluj, 3 hours $13) aren't far off, and the budget airlines also have flights to tourist destinations in Egypt, Israel, Jordan etc, which are as long as a US coast-to-coast flight.
I’ve been on a flight between Berlin and London that cost less than an Amtrak return ticket from Davis to Sacramento, and I’ve also been on a multi-day road trip from Davis to Salt Lake City that, while fun, was only a good financial choice due to four people squeezing into a Prius.
While I enjoyed camping and seeing bits of the US that foreigners like me don’t normally see, it’s not entirely clear that the difference between that and flying makes flying the luxury.
In general flying is more expensive in NA because of less competition and bigger distances. That's what I noticed when I moved from Europe to here. Now you have to take expensive tests to fly international both ways. That's why I consider it a luxury.
Downvotes because you seem to think there is something special about flying in Europe? lol. It is a similar size to the US within a reasonable estimation, let alone the whole of NA, which is probably what 3x as big?
The assumption here is that a luxury-oriented audience would always want the latest phone. I disagree with that. If I'm rich, I might just not care about upgrading because I have better things to do. Or I like this particular 7 year old phone, so I keep it.
The iPhone is not a luxury product; not in America, anyway.
More than half of American smartphones in 2021 were iPhones. The iPhone is price-comparable to its Android contemporaries. The Android downmarket in the U.S. is a minority by a wide margin.
I don't know why this downvoted. Apple dropped latest iOS support for 5c in 2017.
But 5c is most unloved device so not a good sample. It was released at the same time as 5s that introduced ARMv8 by A7. It was the worst time to release it with old chip.
I'd pick iPhone SE 16GB in 2017 that's still in support.
This is not the most relevant tradeoff. The United App is the only way to watch in-flight entertainment on many United Flights (esp. on newer planes without seatback screens). Every time I fly United, they make an announcement that says "Make sure to download the app before we take off because you can't do it once we're in the air!" and then I see everyone whip out their phones and tablets. Usually that's 10m or so before we lose cell reception and it's often not enough time to fully download the app.
I've often thought that they either need to cache the app locally on the plane itself or provide a special free passthrough on the in-flight wifi, but so far they haven't provided either. In any case, app size is crucially important for the key use case that many (most?) people use the United App.
Maybe Apple could provide some way to cache apps on a local network without needing a Mac. (macOS has a content caching option in the Sharing prefpane.) They could add the same thing to iOS/tvOS to make it cheaper and more widely available. Ideally there would be a containerized version of the service that could run on any Linux-ish device...can't imagine Apple doing that though.
But this company can't even be bothered to even strip symbols. Having Apple allow caching + putting this in every single airplane is a way more difficult (and certainly more costly than spending 5 minutes stripping symbols and other things).
Maybe we as an industry should start doing the boring parts instead of jumping into shiny tasks that take 10x, 100x, 1000x the time it would take to solve the original issue...
Most airlines won't let you order adult beverages in economy, certain United flights (SFO to IAD (D.C.)) appear to be an exception. But yes. And you need to re-fill in, manually your flight info and seat number. It's a whole process. This is after connecting to their in-flight wifi, which has it's own hurdles.
> what it would have cost United Airlines to do it “the right way”, versus what value it brings them
It may depend on the app, but Uber noticed that the bigger the app, the fewer people install it, unsurprisingly.
I also had friends who wouldn't install Signal because they don't have any space left on the device, and they stick to Whatsapp/Messenger which they already have.
> App-download-size restriction means first-time users cannot download the app ... when they are not on Wi-Fi.
> We established a correlation between the Uber Rider app size and customer engagement — when the app size crosses the download size limit, and it leads to a 10% reduction in app installations, 12% reduction in sign-ups, and 20% reduction in first-time bookings, resulting in revenue loss.
> Over the past three years, the Uber Rider app’s size has often approached the App store’s over-the-air download limit, and staying below it is a clear priority.
> Increase developer productivity at the expense of hardware
Only this is almost never true.
If it's possible to do something unnecessarily complicated, someone will inevitably do it. Maintenance costs are often greater as complexity and bloat goes up.
Longer compile times and generally greater development cycle latency also tends to decrease developer productivity more than the small time differences might suggest.
>Contrarian opinion here; I understand their logic. It looks like a rational trade-off that the engineers have done.
This is not a contrarian opinion. This is the default attitude in web, cloud hosted, and mobile app development.
>looks like a rational trade-off that the engineers have done
What are your back-of-the-envelope numbers? Or are you just shrugging and assuming that performance has zero impact on the development loop, so therefore no development effort should be expended on it?
When someone starts looking into why it's so big and they immediately discover a huge dumb mistake (the example in the post), why do you assume that the rest of the app size is because of rational tradeoffs, instead of being more dumb mistakes?
Yep. Airlines are one of the few brand apps where there probably is a significant business case for spending developer time optimising an app for download size, since customers who make the decision to try to download United's app on slow or metered connections at the airport or overseas are probably customers ready to be upsold stuff via the app.
> So, if app size is a problem, and over time, the problem is fixed by itself, why would you invest engineering resources into that ?
You are assuming apps won't scale larger over time. The old addage about software expanding to consume all available resources comes to mind. I remember thinking I'd never be able to fill my first 1 GB hard drive with software. And now it takes half that for the simplest things. As the bytes get cheaper we ration them less.
Here is today's car analogy : well sure, they pollute, but if nobody complains why would car makers invest in cleaner, more efficient motors? Oil is cheap anyway and will be cheaper in the future (that's probably what they thought in the '60). Oh, wait...
A friend of mine told me their company is trying to downsize their flash storage in order to come back to the unit prices of before the shortages.
you didnt factor in the mobilw bandwidth to download this oversized crap constantly. with 1gb plans in mind how many downloads a month do you get to instagib a plan like that? and for what, no actual patch notes ever?! at least most apps dont hard lock you out when they detect being behind
Yeah no, clearly false, because my iPhone has 8 GB and that ought to be plenty. Hope your web app works on my phone, ‘cause I’m not installing a bullshit app with that much bloat.
> I’d like to approach this differently, and think about what it would have cost United Airlines to do it “the right way”, versus what value it brings them.
For a 5-screen 50MB app, sure. For a 5-screen 500MB app that falls pretty flat.
[edit] You could fit all of Tony Hawk's Pro Skater 2 or Final Fantasy VII for PS2 in the same amount of space.
Exactly - badness of waste is non-linear. An application that's 4x as large as necessary is more than twice as bad as one that's 2x as large as necessary.
A candy bar which is 5% packaging and 95% candy by mass is alright. A candy bar which is 50% packaging and 50% candy is horrifying.
"The Right Way" involves running the strip command before sending the app off to Apple for publishing. It's 5 seconds of effort and saves almost 200MB for literally thousands of users.
I'm willing to bet that the devs who made this app have never worked with a decompiler and have no idea what "symbols" are. Source: I am one of those people (well I have a vague idea, but certainly wouldn't think to check if that was causing bloat in my iOS app).
You’d think the right way would involve Apple refusing your app if it is wasting users storage because you couldn’t be bothered to strip your binaries.
Taking the shortest path to achieve a goal often seems like the good idea, but it leads to bloat and inefficiency. It'd take longer to "do it right" so you never do it right.
But you ignore the fact that all that bloat actually costs you to maintain it. "Not fixing it" is always faster and will always be the shortest path to the next feature... but that next feature gets harder and harder to achieve as the bloat grows. The bloat makes the fastest thing slower and slower while the fastest thing is always ignoring the bloat.
When you appropriately choose when to fix, when to focus on efficiency, everything becomes faster.
The concept is slowing down to move faster.
There's avoiding premature optimization and then there's ignoring optimization forever except for extreme emergencies.
Last time I had to download an airline app was at an airport via the public wifi. You better make it small if your users are people that might be on the road in a foreign country.
This is maybe part of it, but having shipped a macOS app that’s stripped of symbols, crashes can still be debugged as long as I’ve got the dSYM file that was made at build time, so I don’t think it’s a super strong argument. Tools like Sentry will catch the crashes and symbolicate them for you, if you’ve provided them with the dSYM. It can be done on the local machine too.
> And I can only imagine that they outsourced their app development completely and like to keep costs low.
From my experience being on a mobile development team for a competitor. Last time I checked like most major airlines their team is in house and I’d be in shock if that changed.
If Apple would allow web notifications, most apps wouldn't need to be apps at all, but could simply be webpages that get bookmarked to the launcher. The UX for the user would be, for most non-game apps, identical.
The problem is that purchases would no longer be subject to Apple's 10x industry standard (30% instead of 3%) captive credit card payment processing service (for apps), so no web notifications in MobileSafari that might undermine platform control and payment processing monopoly. Apple, of course, will say this is about protecting users from notification spam, and sidestep the inconvenient facts that it protects an Apple cash cow and locks developers and users into a closed and proprietary platform.
I strongly suspect the bulk of this 500MB is DRM frameworks for their in-flight video playback that they can't or don't want to support in-browser. Safari kicks video playback over to the United app each time you select something to watch and it does what appears to be a multi-stage hand-off dance.
"The UX for the user would be, for most non-game apps, identical."
In theory, this is true. In practice, it's just hit or miss. I think it's just hard to maintain web across all the different platform and screen sizes. It's probably due to the fact that an iOS developer specializes in one platform and most web development shops will have to support all platforms.
"If Apple would allow web notifications"
I do not use apps because of notifications. I use apps because in general, the performance and experience is much better.
It's also hard to maintain two entirely separate apps in two entirely different languages for two entirely different platforms/APIs, all while giving up nearly a third of your CLV to a rentseeking middleman.
What we need is better support "native hybrid" apps.
For example, you can create "app" that is just a link to browser. There are plenty of action you don't want random web-apps to perform due to security/sandboxing issues, but if you can grant explicit permissions that issue goes away. It is one of the reasons think like election exist. But could apple/goog provide a better electron that was built into the OS?
As a frequent and mostly non-loyal flier, I can say despite all its faults the United app is far and away the best airline app in the US: fast, easy to navigate, powerful, useful and often pleasantly surprising. American is the only other app that compares, I can't stand to use any other airlines' apps.
In this case, shipping symbols with the app is almost certainly an oversight. Stripping symbols of shipped binaries is standard good practice.
That said, I don't think the difference between a 40MB app and a 400MB app is all that critical these days. Optimizing for development speed and user experience over an absolutely minimal download size is a reasonable choice.
Shipping a 40MB app instead of <10 MB is questionable except for large apps; Dolphin on Android emulates an entire GameCube/Wii, yet the APK is only 16 MB (34.7 MB extracted). Shipping a 400MB app is shameful.
Not to mention the surface area of the app is often larger than it appears to a single user, especially for companies this large whose customer bases are this wide.
It's tempting to think about the United app as something very simple:
- Search for flights
- Run through the booking flow for flights
- Look up existing bookings
- Change existing bookings
But this ignores a lot of scope that's actually critical for a company whose products are very complicated:
- ID verification for international travel
- Custom functionality for large institutional cu
stomers (government, corporate)
- Functionality for ancillary services: in-air streaming entertainment, in-airport services like lounges and baggage checks, loyalty program, loyalty-tier-specific functionality like priority connections.
- ... etc.
In this case the lack of stripping symbols seems like a very easy win and definitely is an example of sloppiness, but the idea that the binary should definitively be < 100MB seems to ignore a lot of scope.
Not just good practice, it's default with Xcode. Someone must have messed up some configuration/flags while they were breaking the frameworks up maybe?
As a long time united frequent flyer, while I have many gripes, they have consistently made the app better and better without useless "redesigns for the sake for redesigns"
> I can imagine it's layers upon layers of poor, bad and terrible architectural and organizational decisions.
Or are they trade-offs?
Do these 'bad decisions' actually impact their business or are they manageable, allowing them to achieve their mission, focusing on other things that are more important?
I've worked on one of these apps (healthcare space, just checked and the size sits at 350MB). Here's the problem as I saw it firsthand:
* Far too many hands in the pot: My rough calculation is at any given time, there are around 1000 contributors to this app, across various teams. This itself is not a problem, but leads to issues.
* Tech Debt Racks up Quick: Again because there are so many hands in the pot, tech debt racks up unbelievably quickly. And furthermore it's almost impossible to address because it cuts accross so many teams and orgs.
* The Solution? More Hands in the Pot!: With tech debt racking up quick and not being resolved, productivity grinds to a halt. App has constant errors, crashes, and things like hot reloading are just totally broken because of all the underlying issues. So what do you do when faced with this problem? More engineers! Rather than addressing the problems that face developers, they just throw more labor at the problem, compounding the previous issues.
* Code Duplication: With so many folks working on the project but not talking to one another, code duplication becomes a MAJOR issue. Say you have a "Button" component that needs to be modified. Well, modifying that component means going through 5+ teams to get approval. So to sidestep you create "Button2", and the next guys creates "Button3". The result is you pull up the fuzzy finder and search "Button", only to get 15 results with subtle differences.
This is just my experience. Currently this app is top 20 in healthcare on the Apple Appstore. The company also has a number of other apps and when I was leaving the company, there were talks to merge all the apps into the "main" app (good fucking luck).
Without diving into specifics we'll never know of course. But consider the opposite: would good decisions positively or negatively impact their business? Would they prevent them from achieving their mission or focusing on other things?
I can think of how bad decisions could negatively impact their mission and focus:
- App is slow and buggy, pressuring users to choose a different service altogether
- A much larger support staff is required to handle customer issues
- Bugs are painful to address and require weeks or months to resolve
- Developers spend more time fixing bugs and less time working on features, resulting in delayed features and an increased team size to allow more parallel development
Just checked the other day: one of my favorite apps this year, Hyperweb, is just 18.2 MB. Granted, it's only a browser extension for adblocking, styling, etc (sort of a replacement for all of the various Firefox addons I wish I could use on iOS), but the competition, AdGuard, clocks in at nearly 500 MB.
I really wonder what some of these apps are doing with this space. My banking app clocks in at 400 MB as well.
Just for some perspective, the entire installer package for the Shareware version Doom took up about 2.39MB of space. This included the EXE and all art assets. The installer for WordPerfect 5.1 (DOS) was about 3.6MB. The full on-disk footprint of Microsoft Office 95 was less than 100MB, including all documentation, Word, Excel, and PowerPoint.
I'm not entirely convinced value-per-byte is a measure of software quality that a lot of users care about, but it undeniably trends down every year.
DOOM2.WAD has always been my measuring stick for software size, as I remember how frustrating it was to download such a huge file (15MB!) in the dial-up days. I never did get it to complete - I couldn't justify to my parents that the phone line would be busy for a whole day :)
Keep in mind that even on the free version, you can add (unlimited?) adlists. I've added some of the most popular uBlock Origin default lists to mine to make the ad blocking even better. It is absolutely insane how many apps Hyperweb replaced for me, too!
Strange, the download from the app store (https://apps.apple.com/us/app/adguard-adblock-privacy/id1047...) is 100 MB, but my install somehow crept up to ~400 (logs, maybe?) over a couple of years of use. I don't have it installed any more, but it's wild how much this varies across devices. What phone do you use? I use a 2016 SE, I wonder if there's a bug that's consume extra space on a device as old (and likely untested by AdGuard) as mine?
I don't think the Stripe app is a good comparison. Airline apps have to cover shopping, booking, cancellations, seat selection, loyalty programs, check-in, bar code generation and scanning, and so on. Typically with broad support for different currencies, languages, etc, etc. 439mb is obviously not right, but I would expect the app to be fairly large.
> Airline apps have to cover shopping, booking, cancellations, seat selection, loyalty programs, check-in, bar code generation and scanning, and so on.
That may be true for some airlines (webviews vs native), but it is not true for many. Boarding passes are probably a good example. It's very typical for that functionality to use something like Apple Wallet integration, and also native widgets to upsell cross-sell boarding/seat upgrades, etc.
Passes already in the wallet don't require you to be online. But, what I meant was that there was additional code, thus additional size for all the functionality and ui related to boarding passes, whether or not parts of it don't work offline.
At least the airlines I've worked with prefer native code and UIs for any flow that's either revenue-producing, or likely to create issues on day-of-travel. They tend to use webviews only for things that don't have to be working to sell a ticket or board the aircraft.
I think one needs to understand the mentalities of the project managers and programmers/contractors who actually work for those behemoth corporations to understand the quality of their work.
This seems like a huge market opportunity for a service where you upload your "final" binary and some app goes through the thing and shows you all the stupid you are doing and how to fix it.
This would have really pissed me off if I had to download it over my cell plan. I have one phone with minimum apps on it which I use for day-to-day, and then another with all the scummy bloated apps on it, but the data plan on that phone is small and 500MB would be a huge chunk out of my monthly quota.
Couple bad development practices with archaic technology for ticketing and we get the worst of both worlds. I've worked with two airlines and it was fairly frightening to see what type of BS they're working with and against.
