It's not really a big deal for me, despite the fact that I travel to Europe in a few days for two weeks. At least, I'm fairly confident this won't be an issue for me. A few of my fellow #sqlfamily might not be so lucky, as they use a different airline.
Apparently American Airlines has a bug in their scheduling system. It's not a safety bug, don't worry about that, but it's potentially a huge bug for the company in terms of profit and cost. The bug is a part of the system that lets pilots request holiday time off. The system allowed too many pilots to take vacation, and as a result, American Airlines (AA) doesn't have enough pilots to fly their planes.
In case you wonder about the scope of this, it's 15,000+ flights that are affected. AA flies about 6,700 flights a day and are the world's largest airline by some measure. They are offering pilots 150% of their normal rate, which is apparently the max allowed by contract. I'm sure some pilots will take the offer, but I'm also sure there may be some flight cancellations. After all, pilots have likely made their own plans, which they may not want to change. Apparently some have as the news as of this writing is a few hundred flights.
The complexity of airline scheduling software has to be quite high, and while this won't really endanger lives, it will affect the profitability of AA. This is definitely a development mistake, and one that should have been caught in testing. I don't know how often this software is updated, nor what their process is. Someone suggested this is outsourced software, but that doesn't matter. We clearly have a software development failure here.
I certainly think developers are responsible for testing their code and meeting requirements. This includes not assuming the happy path is followed. However, this is also a place where we need (as an industry) to learn to better test the bounds and limits of our software. We need to be sure that we account for not only security, but pushing the limits of use by legitimate users. Software mistakes cost money, and as we continue to use computing more and more, we need to become better at testing our code. Our systems are very complex these days, more complex than a single person can handle. We need better testing everywhere, including the database.
Please, make an effort to test better next year, in both your application and database. Use larger data sets at some point (both numbers and dates), add automated testing as a part of your development routine, and assume that users will do stupid, silly, and malicious things with inputs.
The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music.
How to track every change to your SQL Server database
See who’s changing your database, alongside affected objects, date, time, and reason for the change with SQL Source Control. Get a full change history in your source control system. Learn more
Register now for SQL in the City Streamed
Redgate’s popular SQL in the City Streamed virtual event takes place again this December. Wherever you are, tune in on Wednesday December 13 to watch some of the best-known speakers from the database world present the latest technologies and tools from Redgate. Register free now
There is a lot more to SQL Prompt than IntelliSense and code completion. Tony Davis takes a developer's eye view of its features, as they slot into a typical day of database development work, covering Prompt's snippets, Actions, custom code styling, safe database refactoring, as well as safety net features such as tab coloring and tab history. More »
Protect your data from attack by using SQL Server technologies to implement a defense-in-depth strategy, performing threat analysis, and encrypting sensitive data as a last line of defense against compromise. The multi-layered approach in this book helps ensure that a single breach doesn't lead to loss or compromise of your data that is confidential and important to the business. Get your copy from Amazon today.
Yesterday's Question of the Day
(by Evgeny Garaev):
How many indexes can be created on a Memory-Optimized Table if you use SQL Server 2016?
SQL Server 2014 and SQL Server 2016 have a limit of 8 indexes per memory-optimized table or table type.
Ref: Indexes for Memory Optimized Tables - click here
This newsletter was sent to you because you signed up at SQLServerCentral.com.
Feel free to forward this to any colleagues that you think might be interested.
If you have received this email from a colleague, you can register to receive it here.