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.
> 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.
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.
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.
It's a unique identifier but now "not on a computer".
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?
Reminds me of the ship of Theseus: https://en.wikipedia.org/wiki/Ship_of_Theseus
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.
> 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.
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.
> 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.
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)
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
Even runway IDs change over time: https://en.m.wikipedia.org/wiki/Runway#:~:text=Runway%20desi...
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.
The claim isn't that programmers go around literally believing falsehoods about a given domain. The whole point of the "falsehoods programmers believe about X" genre is a tongue-in-cheek way of listing the kind of bad design assumptions that happen in a given domain, and I believe that is very interesting indeed.
The fact remains that software that models real-life events or information is making normative assumptions about what can and cannot happen in the domain, due to the very nature of software, and these assumptions are knowingly-or-not being introduced by programmers. If for any given domain we had hundreds of human notaries, scribes or typists managing information instead of software, their mistaken assumptions wouldn't matterâthey would simply go "Oh, that's odd", make the necessary adjustments, and learn from the experience. But as long as software is a prescriptive model of what it is representing, it will be valuable to highlight the "falsehoods" that its creators may accidentally prescribe into it.
I don't understand your argument
it doesn't matter whose failure it is
the point of the article (just as with the one about names) is that there are "reasonable defaults" many people would believe - that don't work in practice and become gotchas
whether you have enough knowledge to know that something is unreasonable doesn't mean it doesn't seem reasonable for many others
And as programmers, we inevitably spend most of our time dealing with these weird edge cases, because the stuff that makes sense is generally incorporated into our initial modelling and becomes a solved problem.
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...
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.
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.
Adding to the list: Runway numbers never change [1]
[1] https://www.ncei.noaa.gov/news/airport-runway-names-shift-ma...
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.
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.
> 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.
> 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.
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.
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.
The profession of programming is fundamentally about the interface between squishy human systems and rigid rule-based machines. No surprise that keeps coming up.
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.
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.
Falsehoods people believe about programs:
* When a new corner case appears, it is easy to adjust the program to handle it.
Falsehoods people believe about falsehoods about programmers: the stated falsehoods are actually false.
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.
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
Uhh, and how often were you able to run the Blaine skydiving test? :D
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.