My G+ Profile
« Banner Graphic | Main | More Identity on the Gillmor Gang »
16-Bit Overflows and Airport Delays
“Who’d ever need to make more than 32K worth of crew changes per month?” You can almost hear the thought running through the programmer’s mind, can’t you? Unfortunately, Delta did in December 2004 and an overflow in some scheduling software created by SBS, a subsidiary of Boeing left Delta trying to figure out what crews were available to fly where and when. Actually, I doubt that the programmer even thought to ask that question. Just selected INT and that was the end of it.
Who’s fault is it? The programmer is certainly to blame for not understanding and taking into consideration the limitations of the language. Even so, the language itself ought not to be so tied to the hardware. People are unused to thinking about arithmetic overflows when they see an expression that looks like “X + Y”. They think they’re doing math but in most languages, they’re just doing an approximation of math. We can do better than that.
Thanks for Bryan Morse for the pointer to this.
Posted by Phil Windley on January 3, 2005 10:35 AM
Comment from Kelly Hall at January 3, 2005 5:30 PM
Funny, what I hear running through my mind when I read about this is:
Tech Lead: "Hey product manager - the code currently supports 32K events per month. We can make the code handle more, but it will require re-architecting the event index table subsystem and will increase our disk footprint by a few hundred K. I think it'll take 2 weeks of coding, probably 2 weeks of QA testing."
Product Manager: "What? We can't slip the schedule and we have to support West BumFuck Airlines that still uses a PC/XT to handle crew scheduling. Ship it the way it is and I'll tell the sales team."
Sales Team: "32 thousand events? That's plenty..."
Comment from Marc at January 3, 2005 6:14 PM
Recently, our helpdesk started complaining that their (Windows-based) ticket system suddenly began to fail - when I noted that just over 32,000 tickets had been issued since the system had been installed three years earlier, I knew the reason. When the vendor was contacted about this, all they would suggest was to purchase and install the "latest" version of their product ... (which unfortunately we did, although we were never able to load in the old tickets into the new system, something to do with "incompatible new formats and schemas")
Comment from Phil Windley at January 3, 2005 6:20 PM
Well, Kelly's probably got a point regarding some products. If that's the case here, then the company's probably getting what it deserves with the bad publicity.
Marc's post bring to mind a thought that there are millions of little Y2K problems alive and well, they're just not all going to strike at once. Sometimes though, as in the crew scheduling debacle, they have wide impact nonetheless.
One third thought: If you go to the SBS web site (http://www.sbsint.com/), you'll see no mention of this. This reduces their integrity (as a measure of the distance between their public and private faces). Most companies still don't get that the Net has changed the rules here.
Comment from Kelly Hall at January 6, 2005 11:44 PM
From the January 3, 2005, issue of Aviation Week and Space Technology, page 43, paragraph 6:
--quote--
Michael Pound, senior vice president for communications at Jeppesen, describes the 1986 SBS Track system as limited to handling 32,000 flights per month. "My understanding is that Comair is typically running about 28,000 flights a month through the system. When this weather event hit and they began looking at rescheduling ... on a massive scale, that obviously put them up to the limit in almost no time."
--end quote--
I remember writing software in 1986. A third of what I wrote was on the college Vax, written in Fortran 77 or Pascal, with a few lines in DEC Basic. Another third was on the college mainframe in Fortran 77 or Pascal or exec2. The last third was Pascal or assembly on my home computers: A Kaypro running CP/M, an Atari ST, or an Apple //c. I wanted to learn C, but it wasn't available on any system I had access to.
Personally, I'm surprised any company would be cheap enough to still use software that old in 2004. Of course, I image SBS / Jeppesen / Boeing had shiny marketing brochures for this product a lot newer than the code. Of course, caveat emptor.
Buy My Book
I'm CTO of Kynetx
Dates for IIW
IIW XV - Oct 23-25, 2012
Free Newsletter!
Search
Find Me Elsewhere
Digital Identity
Buy the book!
Upcoming Events
Recent Entries