May 8, 2013 at 10:28 pm
Comments posted to this topic are about the item A Broken Data Model
May 9, 2013 at 5:23 am
I've already seen a similar situacion.
But it was human error! The screen was flashing red and the operator wasn't looking at it...
This happened on entering the internacional zone in London and was the cleaning lady that asked the operator what was that red light...
In the end, the person had another ticket printed and all was sorted out... Computers and scanners and barcodes and qr codes and everthing else are great in this systems, however, if the users are not even looking at the screen then there's nothing that will work 100% of the times.
Sorry about any error on my english gramar,
Helder
May 9, 2013 at 5:35 am
You just had to post this, 19 days before I'm going on a flight...
I do think, however, that your thought of two flights, same day, same flight number, different times was likely the correct presumption. Especially if it was a fairly short hop flight. Which, especially with the recommendations of "arrive two hours before your flight, yada yada yada," makes it easy for someone to arrive early, breeze through security, hear their flight number, and try to board.
Then find out that they're a couple hours early.
The system probably displays the flight time for the boarding crew when they scan the boarding pass, but they're trying to get everyone on and seated so they can get out on time, so they probably barely glance at the screen, making it easy to miss. Really I can think of only two solutions, one of which is more a joke...
1. Fewer flights, and give the crew more time to load people, including checking the boarding passes thouroghly...
2. Set up the scan terminal to really alert someone if anything doesn't sync up. Boarding pass has a flight time of 12:00 but it's 9:00? Flash red and beep! Wrong flight entirely? Flash red and beep!
May 9, 2013 at 5:36 am
Two flights to the same place by the same aircraft on the same day will always have different flight numbers.
Airlines often do this for short trips e.g. London - Paris. The same aircraft (and crew) may do all the flights back and forth for a given day.
To allocate seats, the system needs to know the specific aircraft, as seating plans on aircraft can be changed easily (and sometimes frequently). Even 2 aircraft of exactly the same model may have different seating arrangements.
I too am very surprised that the passenger booked on the later flight was able to board. It might be a broken data model, or the person checking maybe ignored a warning, but either way it is a significant security failure.
May 9, 2013 at 7:53 am
They don't have nearly enough data screening going on. Depending on the airport/airlines, you can go to the wrong gate and give them your ticket and get on the wrong plan and not know you screwed up until you are in the wrong city. You would think this could never happen but it does.
May 9, 2013 at 8:09 am
I always just assumed that they were checking to make sure that your boarding pass was valid for that day of travel. It's not up to them to tell you how early you can/can't go sit by the gate.
---------------------------------------------------------
How best to post your question[/url]
How to post performance problems[/url]
Tally Table:What it is and how it replaces a loop[/url]
"stewsterl 80804 (10/16/2009)I guess when you stop and try to understand the solution provided you not only learn, but save yourself some headaches when you need to make any slight changes."
May 9, 2013 at 8:11 am
However given that so much of the airline industry relies on systems that were developed decades ago, perhaps I shouldn't be surprised.
Are you implying that old code is inherently inferior to modern code?
I would agree that modern languages make it easier for devs, but they also make it easier for devs to make mistakes too.
Decades-old code written (and tested) using waterfall project management methodology for the FAA may be an exemplary case of build it right the first time.
That the expected use case(s) [normal behavior] works smoothly as frequently as it does I think deserves some kudos.
The new behavior of customers/users (incl. airlines) to book multiple daily trips to the same destination with the same plane or to change seat assignments in near-real-time, etc. being driven through decades-old code (that maybe didn't anticipate 'modern' craziness) with as few mistakes as we see is also pretty amazing.
I'm not trying to be an apologist for crufty old code. However, in some cases old code survives as long as it does because it works so well there's no reason to risk system stability by replacing it with the flavor of the month.
I'm sure you wouldn't make age-ist remarks about coworkers, just shedding light on the attitude towards "old code" 🙂
May 9, 2013 at 8:21 am
kevin.parks 41073 (5/9/2013)
They don't have nearly enough data screening going on. Depending on the airport/airlines, you can go to the wrong gate and give them your ticket and get on the wrong plan and not know you screwed up until you are in the wrong city. You would think this could never happen but it does.
Years ago I was on a late night flight which made a brief stop in DC and ended in Newark, NJ. At Newark, they woke everyone up on the plane including the young soldier in a nearby seat who was supposed to get off in DC. No one noticed, no one woke him, and suddenly he was dumped in a strange city late at night.
...
-- FORTRAN manual for Xerox Computers --
May 9, 2013 at 8:35 am
Most of the airline industry is strapped for cash as it is and struggling just to stay alive. You don't seriously think they have the money or time and energy to to put in state of the art booking systems do you? Of course not, they are using legacy out of date systems that are probably 10-15 years old as you stated. This should not surprise anyone. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
May 9, 2013 at 8:43 am
Interesting example - but some time what we miss out is the fact - Model is not broken, its because we could not model it correctly due to lack of standards - some facts to know!!!
1. Numbering used in the flights were first developed for the purpose of identifying flights in each airports - and the numbering system varies from airlines to airlines/country to country... (You can imagine the challange when 2 airlines merge that are from 2 country !!)
2. The way numbering is done though has a standard - but do not have a industry standard, an Example - one airline will use east/north bound flight numbers to be in even numbers & West/south bound to be odd numbers - and other would use odd numbers for outbound and even for inbound - so there is no standards set across the industry on the numbers!
3. Now, IATA - a Regulatory body had attempted to solve this challange in flight numbers and had come up with standard manual - but still not widely followed across the world!!
With all of the above challange - its not possible to build a standard data model that can be used across any airlines when it comes to Flight number field and usage/relationship etc - to complicate the above fact airline merger/ Flight accidents ( you do not reuse the number when u have a flight accident ) fuels the data challange.
This is a classical example of how Compliance, Change in business environment, lack of standards - can lead to business impacts
May 9, 2013 at 8:58 am
Years ago I was on a late night flight which made a brief stop in DC and ended in Newark, NJ. At Newark, they woke everyone up on the plane including the young soldier in a nearby seat who was supposed to get off in DC. No one noticed, no one woke him, and suddenly he was dumped in a strange city late at night.
Cabin crew count the passengers after boarding - surprised they didn't notice the numbers didn't tally.
May 9, 2013 at 10:07 am
Mike Dougherty-384281 (5/9/2013)
However given that so much of the airline industry relies on systems that were developed decades ago, perhaps I shouldn't be surprised.
Are you implying that old code is inherently inferior to modern code?
No.
...
That the expected use case(s) [normal behavior] works smoothly as frequently as it does I think deserves some kudos.
It does, and I should have pointed out how well things seem to work.
...
(that maybe didn't anticipate 'modern' craziness)
I'm not trying to be an apologist for crufty old code. However, in some cases old code survives as long as it does because it works so well there's no reason to risk system stability by replacing it with the flavor of the month.
It's not that the code is old; it's what you referenced. Modern craziness, and new requirements exist. We've shoehorned some of those features in there, and that causes issues. We've also scaled. Code doesn't always scale, as much as we'd like it to.
May 9, 2013 at 10:11 am
skumar 5499 (5/9/2013)
Interesting example - but some time what we miss out is the fact - Model is not broken, its because we could not model it correctly due to lack of standards - some facts to know!!!
Semantics. It's still broken. Not because it wasn't built well, though that could be it. It's broken certainly because of change.
May 9, 2013 at 3:35 pm
TravisDBA (5/9/2013)
Most of the airline industry is strapped for cash as it is and struggling just to stay alive. You don't seriously think they have the money or time and energy to to put in state of the art booking systems do you? Of course not, they are using legacy out of date systems that are probably 10-15 years old as you stated. This should not surprise anyone. 😀
Make that age 30-40 years. SABRE was considered old when I was doing a project for them 23 years ago.
May 9, 2013 at 5:11 pm
Steve Jones - SSC Editor (5/9/2013)
... We've shoehorned some of those features in there, and that causes issues.
The bane of developers and their system, shoehorning. I have learned to dislike this process over the years. But a developer cannot stop it from happening. We cannot even slow it down. Many think it is cheap and easy but there is a cost somewhere in the process where others or you yourself will have to pay.
After years of use and resurfacing or shoehorning, systems start to show the results of the series of compromises that have been made. Like using a pair of pliers as a hammer you are going to get hurt before it is over, and you had best watch out for it will in fact be wrong.
Thanks Steve! You helped me get off a late afternoon vent 🙂
M.
Not all gray hairs are Dinosaurs!
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply