Skip to content(if available)orjump to list(if available)

Falsehoods programmers believe about aviation

sixdimensional

Here's a fun true story..

Aircraft do not have a singular unique identifier that is time invariant.

While it is true that aircraft have serial numbers issued to their airframe, by itself, aircraft serial numbers are not unique.

The only unique identifier for an aircraft across its lifecycle from production to end of life is a combination of the manufacturer, make and serial number.

I know this because I am on (for better or worse) the patent that involves defining that as a unique identifier for aircraft.

The combination of ICAO aircraft type designator + serial number approximately is the most permanent identifier for an airframe - and even then - if an airframe is modified significantly enough that it no longer is the previous type - even then this identifier can change.

Personally, it boggled my mind that something as big as an aircraft did not have a simple time invariant unique identifier.

P.S. For those who might ask - aircraft registration numbers are like license plates, so they change - tail numbers can be ambiguous and misinterpreted depending on what is painted on the aircraft where, and ICAO 24-bit aircraft addresses are tied to ADS-B transponder boxes, which technically can be moved and reprogrammed between aircraft also.

Too

> combination of the manufacturer, make and serial number.

> patent that involves defining that as a unique identifier for aircraft.

Now i got mighty curious what makes this novel enough to be a patent.

dmd

Go work at a big company. The patent lawyers come around and ask what you've been working on, and a month or two later, your name's on 10 patents, none of which make any sense whatsoever. If you're very lucky you might get a dollar bill for each.

tux3

You burrow this simple idea in pages and pages of obfuscated tedium, and that's good enough that everyone is happy. Patent office gets their fee, lawyers get paid, company can say it has a supercharged patented innovation.

amelius

It's a unique identifier but now "not on a computer".

Tostino

I was wondering the same thing. I've had to derive unique identifiers from hundreds of different data sets over the years. What makes it special when it's a plane?

jajko

Maybe its right-click level of patent.

pyuser583

The “real” unique identifier is such a common problem. And the solution is almost always “model, make, and serial number.”

Plus year of production if necessary.

I’ve seen programmers attempt deduplicate humans by language spoken.

bombcar

> And the solution is almost always “model, make, and serial number.”

If you've ever spent time in old car forums, you learn that even this isn't enough because of production-line sloppiness.

Serial number re-use is rare, but it happens. Usually because a product had something detected that resulted in remanufacturing, but sometimes other things slip.

thaumasiotes

> I’ve seen programmers attempt deduplicate humans by language spoken.

How is that supposed to help? If two people have the same name, it's overwhelmingly likely that they also speak the same language.

oflebbe

I know about systems who had two types of serial numbers which ought to be the same, but weren‘t because they had been programmed at different eol stages, when daylight savings time kicked in. One of the system run in utc the other in local time. Date was part of the serial.

fho

How does "model, make and serial number" translate to humans?

(No racist intentions here, but you bring up both points and I thought that to be interesting)

godelski

Johnson Smith

The son of John who is a smith

I'm only joking a little. Funny thing, surnames aren't actually that old for Europeans. Most of history there'd be maybe two people with the same name. They solved it back then very much the same way we solve it now.

https://en.wikipedia.org/wiki/Category:Occupational_surnames

https://en.wikipedia.org/wiki/Patronymic

Xevion

Aircraft of Theseus

null

[deleted]

sixdimensional

Exactly!

Dylan16807

The full Theseus treatment would need you to take [part of] the airframe that first plane discarded, then recertify it for use under its original serial number.

Is that allowed?

genocidicbunny

> Personally, it boggled my mind that something as big as an aircraft did not have a simple time invariant unique identifier.

It boggles my mind that despite not having some sort of universal system things work as well as they do.

Aviation grew up relatively insular, and each country that had any sort of aircraft manufacturing did things their own way until fairly recently. Arguably, the first half of the history of aviation is a kind of free-for-all. The fact that we now have a globalized airline industry that mostly follows some kind of standards is the mind-blowing part to me. And I suspect if we weren't mostly down to a dozen or so manufacturers for the vast majority of airliners, even that wouldn't be the case.

amelius

Yeah but at some point countries started buying larger planes from only one or two manufacturers. At that point the manufacturers could standardize things.

Aardwolf

> combination of the manufacturer, make and serial number

What if a new aircraft were made 50/50 from the parts of two older aircraft

dmd

It would depend on which side got the data plate.

null

[deleted]

rootsudo

I would also say engine too.

genocidicbunny

Engines are actually changed fairly frequently because they're a wear component on most airplanes. They are also sometimes updated to a newer version or even an entirely different manufacturer. And often it's faster and cheaper to swap in a new engine that's ready to go rather than wait for the one that's attached to be overhauled, so the same engine might see service on multiple airframes.

NoboruWataya

Engines are treated as their own thing separate to the airframe, with their own serial numbers.

alphazard

A lot of these so called "falsehoods" are just design failures on the part of programmers. Someone did it badly first, and it stuck, and a second person came in later and is surprised by the bad design. That's not really interesting, it happens all the time in software. So much so that seasoned engineers have come to expect poor design until proven otherwise.

Things like flight numbers not having reasonable semantics, or conceptual pollution of what a flight is to include multiple take offs and landings are bad design, plain and simple. Just model the problem correctly e.g. maybe a Trip is multiple Flights, or Flights have multiple Legs. This isn't aviation specific. These are generic problems that programmers can and should get right.

Some of it is intrinsic to the domain, like flights not all having gates, or not landing at airports. That was a new tidbit for me.

FabHK

As usual with these lists, they would much benefit from more in-depth explanation. This list at least deigns to link to examples for many of the claims (like a flight that leaves on time but arrives 40 hours late [1]), but doesn't explain what happened.

Having said that, many of the links are very informative. For example the crater on Mars that has an ICAO airport code [2]: "On 19 April 2021, Ingenuity performed the first powered flight on Mars from Jezero, which received the commemorative ICAO airport code JZRO."

[1] https://www.flightaware.com/live/flight/PDT5965/history/2025...

[2] https://en.wikipedia.org/wiki/Jezero_(crater)

freeone3000

This is often for boring reasons - the two week flight was a Google Balloon, the flight was delayed for 40 hours due to bad weather, ADS-B is set by the pilot and many pilots simply set it wrong, and so on.

jmward01

Adding to the list: Runway numbers never change [1]

[1] https://www.ncei.noaa.gov/news/airport-runway-names-shift-ma...

bnycum

I develop software for flight data analysis at a company that makes flight data recorders. Our focus is mainly helicopters, but some fixed wing. Dealing with aircraft that may takeoff or land at a base, hospital, roof, parking lot, football field, airport, golf course, etc I feel like most of my days are spent on all sorts of falsehoods about aviation.

djoldman

Falsehoods people believe about programmers:

* Programmers believe they are handling all possible configurations of the universe when putting something into production.

* Programmers don't handle all possible configurations of the universe when putting code into production because they don't know any better.

Falsehoods people believe about the universe:

* There exists a constant.

* SI units are constant at all times or everywhere.

amelius

Falsehoods people believe about programs:

* When a new corner case appears, it is easy to adjust the program to handle it.

genocidicbunny

Funny how the common thread through many of these 'Falsehoods...' posts is that many programmers think that systems designed by humans, for humans, and kept running by humans will rigidly adhere to a set of rules and don't have edge cases.

grishka

Us programmers like to distill everything down to rigid sets of rules because that's how our mind operates. The fewer probabilistic "analog" parameters, the better. Of course the real world doesn't work this way.

astrobe_

> because that's how our mind operates

It is by no mean specific to programmers. Ask to someone who learns French, for instance. Rules with too many arbitrary exceptions.

What is specific to programmers is that their tool performs at its best with simpler rules, so their job is to find the necessary and sufficient set of rules - and will dismiss most of the cases pointed by this article as unimportant exceptions the software won't handle.

genocidicbunny

> Ask to someone who learns French, for instance. Rules with too many arbitrary exceptions.

I took French in middle school, and it was always a running joke that the teacher spent the first 5 minutes on the rule, and the next 40 minutes on the exceptions.

quonn

In the end the data has to fit into structures or tables that can be processed by some algorithms. If the system is not rigid to a certain degree it would become unmaintainable or full of bugs or both.

scbrg

Not really. It's just that software by definition must create a model of the domain it attempts to handle. And a model is, in the end, a set of rules. With an absence of rules, the software can't really do anything, as would be pretty pointless for actually solving any problem. The alternative is to hand the users Notepad and say "knock yourselves out".

I'd argue that programmers are indeed much more aware of how many exceptions and edge cases most real world domains have. Ask a lay person about such a simple thing as leap seconds, for instance, and they'll often believe you're making shit up.

wat10000

The profession of programming is fundamentally about the interface between squishy human systems and rigid rule-based machines. No surprise that keeps coming up.

constantcrying

It is the classic scenario of confusing the map with the territory.

In the map everything is clear. It is clear what a "plane" is what "airports" are and what their relationship is. And transferring that into a computer program is straight forward.

In the territory everything is fuzzy. None of the definitions are without edge cases and the expected relationships are often violated in surprising ways.

Aviation isn't unique here, every system suffers from the distinction between its actual function and the abstract description of that system.

null

[deleted]

Spivak

I think it's more, "you might think as a programmer writing software that models the world of aviation that you could assume the following things— but alas."

Software unfortunately follows rigid rules so the challenge is finding a set of rigid rules that can encompass reality. It would be pretty natural if you were writing a database schema that a flight would have a departing airport and an arriving airport— but alas.

genocidicbunny

Well what I'm speaking to more is that most systems that you model, most of the model is already assumptions. So natural or not, that database schema is already invoking assumptions which may or may not be false. Especially when dealing with any system where humans are directly involved in it. For many things, there's no exhaustive list of rules that will cover all the cases. As they say, if you make something idiot-proof, they'll invent a better idiot.

bruce511

And this is why I much prefer Suurogate values for primary keys over natural values. And why I've gravitated to using UUID values for surrogates, not integer identities.

A theme running through the article is "this value is unique " and "this value does not change". And of course those are both wrong.

So when designing databases now I assume "everything changes, nothing is unique " (even when the domain "expert" professes it is.)

This approach solves so many problems and saves something time later on when it turns out that that "absolutely, positively, unique for ever" natural key, isn't.

kqr

I find this list strange. I have only a passing interest in aviation and I would not believe very many of these.

What made the corresponding lists for names and time interesting were that it was genuinely surprising to realise that their statements were actually false. I don't get that feeling with these.

Like the top level comment about identifiers for airplanes -- why would they have them? That sounds baffling to me. With ownership changes, continuous upgrades, extending airframes, repurposing etc. I would be surprised if there was a stable identity.

n4r9

Yeah. This list is more like "model simplifications you should think twice about making".

amelius

Yes, this list is insulting to programmers.

ryandrake

I always look at these "Falsehoods Programmers Believe..." lists as a source of tests. Each item should spawn a number of unit or integration tests that will help to uproot any of these assumptions that were incorrectly baked into your software.

jpgleeson

Each of these did indeed spawn tests. I used to work there and at the time there were over a thousand ranging from humdrum to David Blaine skydiving. They’re a crowd who really put a focus on good engineering

KingMob

Uhh, and how often were you able to run the Blaine skydiving test? :D

Titan2189

Great Summary of how messed up Airport Codes are by CGP Grey

https://www.youtube.com/watch?v=jfOUVYQnuhw

including (attempts at) a few in-depth reasons for why these quirks exists

marcosdumay

> Flights take off and land at airports

My impression is that every single older (pre-2010) computer system that manages the Brazilian aviation felt for that and fixed it in a hack.

> Airports never move

Also, Runways never move. Also, if runways move, they don't change direction. Also, if airport or runways move, there will exist some construction work before.

I'd add "aircraft only land in runways" there too. And "ok, aircraft only land in runways and heliports".

phantomathkg

> My impression is that every single older (pre-2010) computer system that manages the Brazilian aviation felt for that and fixed it in a hack.

Can you elaborate more?

genocidicbunny

I would assume it's somewhat speaking to the prevalence of many informal landing strips, and also that river landings are probably fairly common too. I'd have to imagine places like Alaska might also have to deal with that, especially if you have small local 'airlines' (which are probably just a handful of bush planes really) that operate from an actual registered airport.

cguess

Even the Eastern US has to deal with river and water landings all the time. You can book a scheduled flight from the East River right in-between Manhattan and Brooklyn to Marthas Vineyard, or the Hamptons or a number of other destinations. Not to mention those happen in the middle of arguably the most complex commercial airspace in the world.

It's pretty cool to be on a ferry and see a plane land basically next to you in the middle of the river.

defrost

I've written various types of aviation support software on and off since the early 1980s.

One of my favourite planes were the Grumman Mallards still owned and operated by Paspaley Pearling out of Mungalalu Truscott and other Kimberley airbases.

They're classic 1950s twin-engined amphibious aircraft that landed anywhere up and down the Kimberley Coast for pearling transfers.

* https://en.wikipedia.org/wiki/Grumman_G-73_Mallard

* https://en.wikipedia.org/wiki/Mungalalu_Truscott_Airbase

khuey

A reference to Air France 447 perhaps?

null

[deleted]

hermitcrab

>The only unique identifier for an aircraft across its lifecycle from production to end of life is a combination of the manufacturer, make and serial number. >I know this because I am on (for better or worse) the patent that involves defining that as a unique identifier for aircraft.

Isn't that blindingly obvious? If so, how did it get to be a patent? And is someone now extracting rent from it?

diggan

Does it matter if something is obvious or not for getting a patent granted? From some casual looks of various US patents, it seems to be "First who writes a obtuse patent about thing X gets it granted", doesn't really matter if the thing is "novel" or not, just that no one tried to submit it before.

ajb

Legally it's supposed to matter, yes. Non-novel or obvious ideas are according to the law not eligible to be patented. In practice the mechanism to decide both of these is broken.

diggan

I see, that's really not visible in practice. Silly example perhaps, but US5443036A comes to mind which just shows how broken the system is:

> A method for inducing cats to exercise consists of directing a beam of invisible light produced by a hand-held laser apparatus onto the floor or wall or other opaque surface in the vicinity of the cat, then moving the laser so as to cause the bright pattern of light to move in an irregular way fascinating to cats, and to any other animal with a chase instinct.

How on earth is anyone supposed to be able to take the patents system as a whole when there are 100s (if not 1000s) of examples like that, which obviously shouldn't be approved if "novel" or "non-obvious" ideas are required.