It requires a lot of code because the rules that govern the use of fares on a ticket are insanely complicated -- literally beyond anything you could possibly imagine a priori. There are dozens of rule "categories", each larded up with tons of complexity. There's even "Rule Category 25: Fare By Rule" which is essentially a complete macro facility for fares, allowing carriers to literally take an arbitrary fare's rules, modify them in all kinds of random ways, and publish the result as a new "virtual" fare.

As for the GDSes, their code is primarily TPF assembly. So now add the LoC blow-up of using a very low-level language.

There are like 25 people in the world who understand this stuff, and half of them likely work at ITA/Google.

Also people at Sabre (worked there) and I presume Amadeus (those are two main players - surprised you seemed to "forget" to mention them?).

As to the "categories", people at Sabre working with them used to say in some cases you can not even be sure if the calculation (of a ticket price - "fare") will end in finite time, so the "macro language" is apparently Turing-complete!

I wasn't meaning to slight either Amadeus or Sabre, and indeed they have most of the other half of the people who understand this stuff between them. The others are at various airlines around the world and at ATPCO.

I've written elsewhere that I personally think the original Sabre system was/is one of the most impressive accomplishments in the history of computing. Using modern tools made things easier for us at ITA, though we compensated for that by trying to compute the entire (very large) solution space for every query, where prior systems used heuristics.

Just some random question. Can you give some insight on how "Greenspuns Tenth Rule Of Programming" apply in this 30million LoC? thanks in advance

Does all that complexity limit the amount of price competition airlines engage in?

Java boilerplate? Just kidding. :)