Falsehoods programmers believe about aviation

Nature and Purpose of “Falsehoods” Lists

• Many comments see this as part of the broader “falsehoods programmers believe about X” genre: a way to surface hidden assumptions that quietly bake bugs into systems.
• Others stress they’re best used as design and test inputs: each bullet should suggest unit/integration tests or schema constraints to reconsider.
• There’s debate about tone: some perceive a “you’re dumb for not thinking of this obscure edge case” vibe; others argue the article is neutral and that calling out non‑obvious edge cases is important, especially for users off the “happy path.”

Aviation Is Messier Than Naive Models

• “Flights take off and land at airports” fails with bush planes, seaplanes, heliports, informal strips, rivers, lakes, golf courses, hospital pads, etc.
• Flights don’t always have schedules (private, charter, medevac, ad‑hoc returns) and can divert multiple times, even back to the origin.
• Gates, runways, and airports move, are renumbered (e.g., due to magnetic drift), or get reused identifiers. Bus stops and train stations can get IATA codes; even a Martian crater has an ICAO code.
• Altitude is not straightforward: barometric vs true, AGL vs MSL, negative airport elevations, and ADS‑B typically broadcasting only barometric altitude.

Identifiers, Codes, and Data Modeling

• No single time‑invariant aircraft ID exists; combinations like manufacturer + model + serial are used, but even those can be ambiguous or change.
• Tail numbers, registrations, and 24‑bit transponder addresses can all change or move between airframes; engines are separate, swapped components.
• Call signs can change mid‑flight (e.g., when the “Air Force One” condition ceases).
• Programmers discuss schema patterns: surrogate vs natural keys, UUIDs vs composite temporal keys, and modeling airport codes/names/locations as versioned time series.
• A prominent example: reassignment of a live IATA code between two active airports broke widespread assumptions.

Humans, Systems, and Edge Cases

• Several comments frame this as “map vs territory”: aviation practices evolved long before software, so real-world conventions don’t match neat schemas.
• Programmers tend to assume uniqueness and immutability because machines require strict rules, but human systems don’t reliably supply them.
• Some argue the real lesson is: assume “everything changes, nothing is unique,” be wary of over‑constraining data, and expect that rare cases will dominate support and debugging effort.