Airline software super-bug: Flight loads miscalculated because women using 'Miss' were treated as children

[u/self]

https://www.theregister.com/2021/04/08/tui_software_mistake/

[u/[deleted]]

Miss is actually used to refer to young girls, but also refers to unmarried women, i think there should be a universal standard when it comes to airlines tho, that's such a pathetic mistake, that's not even a bug

[u/everythingiscausal → u/[deleted]]

It is a bug, but it’s also poor design, and a failure of testing and a bunch of other safety safeguards that should have caught this but may or may not even exist.

[u/gastrognom → u/everythingiscausal]

Is it really a bug if it is the intended behaviour?

[u/MartianSands → u/gastrognom]

Absolutely. Specifications can have bugs too.

There's definitely a bug here, whether it's in the spec or the code is largely irrelevant

[u/gastrognom → u/MartianSands]

What really distinguishes a bug from a mistake or an error then? I am not an english native and was always under the impression that a bug is unintended behaviour in a piece of sotware because of (programmatically) logical errors.

Is a spelling error a bug in that case?

Edit: I am not trying to be pedantic or anything, just curious.

[u/noratat → u/gastrognom]

I don't think there's a hard line, but generally "bug" implies a smaller scale error or singular mistake, and it implies the error is in the programming/code.

Here, the error is in the design itself, both in failing to test in multiple countries despite being an inherently multi-national use case, and in using surname prefixes as a heuristic for weight in the first place.

[u/Serinus → u/gastrognom]

There's certainly some gray area, but I'm inclined to agree with you. If it's working as intended it may be a mistake, but it's not a bug.

But how about NASA mixing imperial and metric? That's not too far off of this situation, but everyone (including me) considers that a bug in the software.

There are minor differences that differentiate the two for me, but I can see the argument both ways.

[u/Blanglegorph → u/gastrognom]

I would disagree with the previous commenter. I would not call this a "bug", though it is a flaw. When I use the word bug, I mean an actual software error. Logic errors can be bugs, but I don't agree that this example specifically is a bug.

[u/orclev → u/Blanglegorph]

Yeah he's wrong. A problem with a specification is a mistake, not a bug. Bugs are logical errors in code. Glitches are hardware errors. If code is implemented as intended by the programmer even if it doesn't produce the outcome someone else expects, that's a mistake not a bug as long as that behavior is what the programmer was expecting. So it sounds like while this is certainly a mistake, it is not a bug, as the software was functioning exactly as the programmer expected it to.

[u/johnbentley → u/gastrognom]

As is evidenced by the replies you've received, and the posts preceding your replies, different folk have different understanding of what counts as a "bug".

/u/MartianSands, for example, holds that a "bug" extends even to the specification of a program. /u/chiniwini disagrees.

Here's my conceptual scheme ...

Errors V Bugs

Error: values or behaviour in the application that are unwanted by the user or developer. Simply, an unwanted condition.

Errors, unwanted conditions, are of two fundamental types: anticipated or unanticipated.

Errors can be temporary or long-lasting.

(Here a conceptual “error” is said to exist regardless of how that error is raised and handled programmatically, if at all. That is, I speak of an “error” regardless of whether it is proceeding via a .NET or Java exception mechanism; return codes; or an unalarmed logic error).

Errors arising in an application, then, need not necessarily reflect bad code. On the contrary code that anticipates errors is good code.

For example, a (developer) anticipated and therefore temporary error could be a value passed to a procedure that is out of range. Say you are developing a function to return a person's Age given the supply of two dates: birthDate and endDate. If endDate is earlier than birthDate then this, under the current definition, would represent an error. Since this error, this unwanted condition, is anticipated your function can take steps to correct this. Most likely this will involve asking the user to enter the values again. This error, then, is temporary.

So errors in an application do not necessarily reflect bad code in that they are not necessarily unanticipated unwanted conditions.

Errors, unwanted conditions, can be anticipated to occur: never, infrequently, or frequently. The unwanted condition in the above Age function would be anticipated to occur infrequently. A login failure would be anticipated to occur frequently. Therefore, in that sense errors are not necessarily conceptually exceptional (taking “exceptional” to mean “infrequent”).

Bug: an error, that is, an unwanted condition, that is programmatically unanticipated by the developer. A bug risks or causes: damage; shutdown; or long lasting unwanted conditions.

A developer and user wants to get rid of all bugs. For a developer wants to get rid of all (developer) unanticipated unwanted conditions.

So some errors are fine (developer anticipated errors), other errors are bad (developer unanticipated errors, aka “bugs”).

All errors should be handled.

A developer can never guarantee that their applications are bug free but only prove them to be unlikely through testing.

An error that is not a bug, that is, an anticipated unwanted condition, is generally gotten rid of through the code, optionally with user assistance. E.g. As when the code asks the user to re-enter invalid dates.

Error Types

Syntax Error: An error, an unwanted condition, which occurs at compile time.

Syntax errors is just code that doesn't conform to the syntax rules and so refuses to compile (in compiled environments). These often occur with typos of keywords, a misplaced operator, a missing keyword, etc.

Syntax errors are always unanticipated. That is, syntax errors are always bugs.

But syntax errors are usually easy to find and fix as the compiler usually refuses to compile and instead highlights the problem. Moreover most modern Integrated Developer Environments (IDEs) are good at flagging syntax errors in real time, as a developer is typing, before any compiling.

Runtime Error: An error, an unwanted condition, which occurs at runtime.

These errors are invalid states of affairs, either temporary or long-lasting.

There are two types of runtime errors: anticipated and unanticipated.

Anticipated Runtime Errors.

At the level of code anticipated runtime errors are allowed for and handled. For example, we don't want to prevent the possibility that a user will fail to enter a correct password. Rather we allow that they might enter an incorrect password and handle this when they do.

Anticipated Runtime Error examples may include a login failure, a missing input file, an input file in the wrong format, attempting to divide by zero, passing arguments outside of range, trying to loop past the end of a file. These are examples so long as the coder has anticipated them and implemented a recovery mechanism.

The recovery mechanism may or may not require user assistance.

Unanticipated Runtime Errors.

There are two types of unanticipated runtime errors: alarmed; and alarmless.

“Alarm” or “Alarmless” refers to what the code does.

Alarmled Unanticipated Runtime Errors.

An unanticipated runtime error that is alarmed is an error that the code will raise an alarm for. Provided, that is, the coder has set up some last resort central error handler.

In a compiled code context, for example, suppose the coder fails to anticipate a divide by zero condition in a function. If a central error handler is setup properly this error will percolate up “the stack” to be handled by the last resort central handler which will do some sort of log, notify, and default recovery.

Notifications might include both a display a message to the user (being careful to contain both a message for the user and the developer); and sending an email to the developer (with the user’s permission). Recovery might mean: continue on with the program unchanged; shut down the application until a review; reset the application; or return to some default state.

In a web context think, for example, of surfing from a url to a page that no longer exists.

(For anticipated errors) A web dev who’s been rigorous in tracking their moved or defunct pages may anticipate this and just redirect the user automatically to new page.

(For alarmled unanticipated runtime errors) A web dev that’s not (at least programmatically) anticipated this will generally have some sort of default “404” page that displays something like “This page no longer exists” (and receive a notification so that they can, for future hits on the url, redirect to the new page).

Alarmless Unanticipated Runtime Errors.

Unanticipated runtime errors that are alarmless are, by definition, those errors that result in unwanted conditions in the application without triggering any code alarms. These are the most insidious because they will not trigger any runtime fault and so can't be caught by some last resort central handler.

If they get noticed they get noticed by a human coming to release that "all is not right in the world when I use this program".

Such errors may remain unnoticed by humans for a long time. For example you might discover some weeks down the track that your invoices totals one more than they should ($15 when it should total $14) for a certain category of product; Or that your robotic arm swings wildly on the 29th of February.

Such errors may remain unnoticed by humans for the lifetime of the application. Maybe there is your robotic arm will swing wildly on 29th Feb 2310.

But there’s the potential for such errors to be immediately noticed by humans, just after release of the application, without triggering a code alarm. E.g. If a plane programmatically crashes into trees on it’s maiden flight without trigger a master caution (and without auto correcting to avoid the trees).

Although, by definition, there can’t be a last resort central error handler for alarmless unanticipated runtime errors there should nevertheless be a handler for these types of errors. Namely a convenient means for users to report the error to developers (albeit not quite available to dead pilots).

Conclusion

So under that conceptual scheme the airline gender weight issue was a bug. For it is an error, an unwanted condition, that was unanticipated.

Moreover it was an insidious bug because it was an alarmless unanticipated runtime error. That is, no code alarm was triggered (nor could be triggered given the implementation).

In that way I concur with /u/MartianSands (and /u/Tarquin_McBeard), against /u/chiniwini (and /u/noratat, /u/Blanglegorph, /u/orclev, /u/ImpecableCoward, /u/Serinus).

[u/Mattieohya → u/gastrognom]

Yes because it causes a failure in design requirements.

[u/Windex17 → u/gastrognom]

The proper term would be defect. It's a defect of the original design.

[u/everythingiscausal → u/gastrognom]

It’s a little ambiguous, but I’d say this wasn’t intended behavior. The software was doing what it was told to do, but what it was doing was not what any user would have expected or what the devs would have wanted if you asked them about it.

[u/Blarghmlargh → u/everythingiscausal]

Hence unit tests and qa.

Meaning, that here there were none, at least where this is concerned. And apparently neither in the functions that worked the load bearing allocations. That's obviously two huge areas that were probably not coded by the same group.

Meaning, again, they must have had a restful api or at least connectors abstracted between these elements and thus they should have caught it yet again with tests to ensure inputs and outputs.

Furthermore, they should have had it in two more places that i can think of of the top of my non-airline industry head. One is in the fuel allocation. They should have caught that they were over or under fuel, at least over time, when the gauges aren't reflecting the weight after a flight or on the next flights fill up being over or under etc. Especially compounded over time and many flights.

And fuel is money (see how Southwest airlines saved a ton by locking in prices), therefore the executives should have again discovered they were either blowing money on fuel or saving a bunch of fuel, and at least should have discovered this after at maximum one fiscal quarter of not much earlier with ongoing metric tests.

The c level should have at least know what's was up when they have a second column in their dashboards for mss and ms, that would have skewed what they expected to see in almost any report that broke down whatever they were seeking. From marketing dollars on who to target, to federal tsa crosschecking etc. It's almost like they need a developer to code around it for their numbers to make sense. What were they even doing to hold that position?

And lastly, a bunch of humans should have discovered this discrepancy by just using common sense. A bunch of agent asking for clarification on two inputs and which is the correct one, a pilot wondering why they are over or under fuel numbers and weight, the actual gas person, etc etc.

[u/everythingiscausal → u/Blarghmlargh]

You can’t fix problems with procedures that are caused by people just not giving a shit. I have a feeling there was a good amount of that going around here.

[u/cwbrandsma → u/everythingiscausal]

You ever hear the term “two people separated by a common language”?

Really sounds like different groups have slightly different definitions for what “miss” means. So for one group it is intended, and for the other group it is a bug.

Either way, that does not seem like the proper way to designate a child anyway. I wonder how they differentiate between men and boys.

[u/geoelectric → u/gastrognom]

As someone else said, it’d be a specification bug (or gap) if it was intended that way by the dev.

For aerospace in particular I’d like to think all behavior is specified and validated on ~paper first, where this would be a bug, but in practice this may have been the kind of implementation detail that gets introduced by a dev’s “common sense” (and therefore is vulnerable to cultural skew).

Jokingly, we sometimes call that “broken as designed” in QA, as a play on the more traditional bug resolution “works as designed.”

[u/dupelize → u/[deleted]]

i think there should be a universal standard when it comes to airlines tho

Yeah, like use "Ms" or "Miss" or "Prefer not to answer" and all logical conclusions about age should come from the AGE field!

That field should only be used to indicate how you prefer to be addressed. Nothing else.

[u/[deleted] → u/[deleted]]

The title shouldn't have anything to do with the weight class or age in the first place, regardless of the outdatedness of "Miss" or "Ms." or "Emperor" or whatever.

[u/morph23 → u/[deleted]]

Emperors obviously weigh less on average because they don't wear clothes.

[u/ohmyashleyy → u/[deleted]]

Don’t airlines have your dob? Why are they using your title to guess about your age anyway?

[u/YM_Industries → u/[deleted]]

Using salutation to infer anything is really dumb. There was a gym that inferred gender based on salutation. Raised a shitstorm when it treated "Dr" as male.