Airmiles and Customer Service

I think we're all used to utterly rubbish customer service from airlines, especially if you have to fly in economy class. No food, no drink, Byzantine terms and conditions, cancellations and subsequent rebookings that cost money (!!!), cramped seating and paying for Wifi on board without refunds if it doesn't work. Oh and good luck if you want to speak to a human, either on the phone or at the airport

Some airlines still have a concept of customer service - SAS and Lufthansa as well as low cost challenger Norwegian at least treat passengers (sorry customers) with some degree of dignity.

I stopped flying Finnair years ago and switched my allegiance to Lufthansa and Norwegian, primary on price. When Norwegian want 600eur to fly a family to Gatwick from Helsinki while Finnair wanted over 2500eur (on a BA flight too!) with effectively the same ticketing terms and conditions. For long haul Lufthansa is my preferred airline - they serve wine and beer with the meal (all included in the price) and have the most professional and hard working cabin crew I've so far come across.

While none of the above are perfect - they could do a HUGE amount more to make the economy experience better - more on that another time.

But what really gets me is that if times are economically tough for airlines, how little they do to actually understand their customer. I mean I used to fly Finnair religiously - their customer service was excellent, food and drink on board, clean aircraft and you could change flights without being punished. Let's be honest here, Finnair were excellent, really, really excellent! I used to change whole itineraries to fly Finnair....

If you want customers then shouldn't you understand why customers aren't flying with you. Isn't this the whole point of customer loyalty programmes?

Below is my Finnair Plus statement - it's been that way for years and not once have I ever been asked why...

So privacy, security and other aspects aside, if you have a customer loyalty card of any sort and change your behaviour, eg: by stopping using that company's services and they never query why, then you were probably never getting any service anyway...

I used to have quite a tally of Finnair points, they all expired or were changed to some newer, more customer friendly scheme, for the benefits of the customer. I was never informed why or when, nor did anyone ever contact me about the change. For a customer loyalty programme you've got to admit that's pretty dire.

Forbes has quite a bit to say about this...

So, if you happen to work in the customer service dept of an airline and wish to discuss the above and how you can win me back as a customer, and a loyal one at that, let me know...

Surgical privacy: Information Handling in an Infectious Environment

What has privacy engineering, data flow modelling and analysis got to do with how infectious materials and the sterile field are handled in medical situations?  Are there things we can learn by exploiting by drawing an analogy between these seemingly different fields?

Surgical privacy: Information Handling in an Infectious Environment from Ian Oliver

We've discussed this subject earlier and a few links can be found here. Indeed privacy engineering has a lot to learn from analogous environments such as aviation, medicine, anaesthesia, chemical engineering and so on; the commonality here is that those environments understood they had to take a whole systems approach rather than relying upon a top-down driven approach or relying upon embedding the semantics of the area in one selected discipline.

Privacy Checklists and a Study in Ontario

Not that particular study in Ontario, but another in Ontario regarding the Surgical Checklist and its "ineffectiveness", which was rebutted by many including Atul Gwande which ended with this quote:

Perhaps, however, this study will prompt greater attention to a fundamentally important question for health care reform broadly: how you implement an even simple change in systems that reduces errors and mortality – like a checklist. For there is one thing we know for sure: if you don’t use it, it doesn’t work.

Relating this back to my experiences in deploying and using checklists for privacy is that THEY ARE NOT A TOOL FOR IMPROVING PRIVACY DIRECTLY but a TOOL for organising your workflows, your actions and ensuring that all members of a team are actively cross-checking each other; and even then this is just a small part of the overall effect. Let us for a moment rewrite Gwande's statement a little:

Perhaps, however, this study will prompt greater attention to a fundamentally important question for privacy engineering: how you implement an even simple change in systems that reduces errors and non compliance– like a checklist. For there is one thing we know for sure: if you don’t use it, it doesn’t work.

In the paper [1] (emphasis mine)

The checklist approach to privacy protection has been debated.[24] Checklists have become important safety elements in airplane and medical procedures and are quite common in security auditing. However, their utility for privacy remains questionable. It might be possible to design privacy checklists for frequent and standardized use cases, but the breadth of potential projects makes a standard checklist for everything an unlikely tool. 

[24]  Ian Oliver, “Safety Systems – Defining Moments” Available at http://ijosblog.blogspot.com/2013/07/systems-safety-defining-moments.html

Indeed the two paragraphs on checklists and privacy impact assessments fails to properly understand the former and compares it against the latter which is a different kind of tool altogether. In fact, a PIA should be done and this would be ensured or reminded by having it included as a point on a checklist for privacy.

Indeed no mention was made, nor has been made of any "standardised checklist". In fact there is a capitalised statement on the bottom of the checklist:

THIS CHECKLIST IS NOT INTENDED TO BE COMPREHENSIVE. ADDITIONS AND MODIFICATIONS TO FIT LOCAL PRACTICE ARE ENCOURAGED.

Which can be read about in this article published back in February.

The point here in both cases: surgical and privacy engineering is that the checklist needs to be accompanied by a procedural and "societal" change for it be successful. One only needs to read about Pronovost's work with a simple checklist and the changes surrounding that to understand how checklists work in practice - that and the other experiences presented in Gawande's excellent book on the subject: The Checklist Manifesto. Our experiences can be read about in the presentation Flying Planes, Surgery and Privacy.

* * *

References:

[1] Cavoukian, Cronk, Shapiro (2014) Privacy Engineering: Proactively Embedding Privacy, by Design

Airbus Aircraft Operational Philosophy

I'm reading the Airbus Flight Crew Training Manual for the A320/A321 aircraft at the moment. If anything, to get an understanding of how such things are written and presented. Aircraft are fairly complex systems and as I've already talked about in this blog, many ideas are directly applicable to privacy, security, software engineering etc if we only take time to learn.

Aside: If anyone does own an A320 or equivalent simulator and would like to offer me some time flying (simulated or otherwise) then YES PLEASE!!!.  OK, back to reality now...

A few things struck me as being particularly relevant such as The Operational Golden Rules:

1. The aircraft can be flown like any other aircraft
2. Fly, navigate, communicate - in that order
3. One head up at all times
4. Cross check the accuracy of the FMS
5. Know your FMA at all times 
6. When things don’t go as expected - take over 
7. Use the proper level of automation for the task
8. Practice task sharing and back-up each other

Nothing too surprising there, other than they're stating the obvious.

That's the great thing about the obvious, completely missable...

Note the emphasis on getting the job done without requiring anything other than basic aviation skills; or in our case basic software engineering skills. The emphasis on cross-checking, task sharing and delegation, the use of appropriate techniques and technologies and the note that when things don't go as expected - take over!

As an idea to start off...

1. There is nothing special about this system under development
2. Plan, code, test - in that order
3. Be aware of the wider engineering and requirements context
4. Cross check your system with its original goals
5. ...

The learnings here to our privacy engineering world are deep and profound. Just as an exercise to the reader, look at the procedures being followed for any engineering task and could these be placed into a simple set of operational golden rules as above? There's an interesting comparison waiting to be drawn here...that will have to wait for the moment.

Understanding Software Engineering Accidents

The cause of 99.999...% of accidents is easy to ascertain, quite simply it is the pilot's/driver's fault. In the cases of two recent aviation and railway accidents (Asiana 214 and the Galicia's train crash) these were caused by the pilot and driver respectively....?

Finding the causes of an accident don't actually involve finding who is to blame but rather the whole context of what led up to the point where an accident was inevitable. And then even after that exploring what actually occurred during and after the accident.

The reasoning here is that if we concentrate on who to blame then we will miss all the circumstances that allowed that accident to occur in the first place. For example., in the case of the Galician train crash it has been ascertained that the driver was speeding, on the phone and had a history of breaking the rules. However this misses the more subtle questions of why did the train derail, why could the driver break the speed limit, what was the reasoning of the phone call, why did the carriages fail catastrophically after the derailment, did the safety systems work sufficiently, what state was the signalling in, did the driver override systems, was the driver sufficiently trained etc etc etc.

In other words, the whole context of the systems and organisation needs to be taken into account before appointing final blame; and even then very, very rarely is it single point of failure: the Swiss Cheese Model.

If we apply this model to software engineering and specifically accidents such as hacking and data breaches we become very aware of how many holes in our computing Swiss cheese we have.

Take a simple data breach where "hackers" have accessed a database on some server via an SQL injection via some web pages. If we apply our earlier thinking, it is obviously the fault of the 'stupid' system administrators who can't secure a system and the 'stupid' software engineers who can't write good code. Hindsight is great here isn't it?

To answer 'who to blame?' or better still 'why did things go wrong and how can we prevent this in the future?' we need to put ourselves, as other accident investigators do, in the position of those software engineers, system administrators, architects, hackers and managers AT THE POINT IN TIME WHERE THEY ACTED, and NEVER in hindsight.

Why did the trained, intelligent software engineer write code susceptible to SQLi in the first place?

Maybe they were under time pressure, no proper, formal design documentation, coding standards, never trained to spot those kinds of errors? Actually just stating that we have a failure of discipline is already pointing to wholesale failures across our whole organisation rather than just one individual.

Even if in the above case this was malice by the programmer, then why didn't the testing pick this up? Why was the code released without testing or checking? Now we have a failure elsewhere too.

Were there no procedures for this? Was the code signed-off by management with the risk in place? Now the net widens further across the organisation

and so on...

In aviation there is a term to explain most accidents: loss of situational awareness, which when explored invariably ends up with a multitude of 'wrong' choices being made over a longer period of time rather than just at those few critical minutes or hours in the cockpit.

I'm of the opinion that in software engineering that we almost always operate in a mode where we have no or little situational awareness. Our systems are complex, we lack formal models of our systems that clearly and concisely explain how the system works; indeed one of the maxims used by some practitioners of agile methods actively eschews the use of formality and modelling tools. Coupled with tight deadlines, a code-is-king mentality and rapidly and inconsistently changing requirements we have a fantastic recipe for disaster.

Bringing this back to an aviation analogy again, consider Turkish Airlines Flight 1951 which crashed as Schiphol in 2009. It was initially easy to blame the pilots for allowíng the plane to stall on final approach, but the whole accident investigation revealed deficiencies in the training, the approach procedures of Schiphol, a non-fault tolerant autothrottle and radar combination, a massively high workload situation for the pilots and ultimately a fault which manifested itself in precisely the behaviour that the pilots were requiring and expecting on their approach, that is the aircraft was losing speed.

As an exercise, how does the above accident map to what we experience every day in software engineering? Given high workloads, changing requirements, inconsistent planning and deadlines to get something (anything!) out that sort of works and we start getting answers to why intelligent administrators and programmers make mistakes.

Facebook and Twitter....instead....

It was one of those funnily serendipitous things that connect everything together...first of all it started "playing" with XPlane 10....a damned good (understatement!) simulator and I suppose the next best thing to actually owning your own aircraft or holding a pilots license...anyway, flying around with some VOR or VOR navigation I ended up in Shannon --- and yes, I did land the plane.

Then I started wondering what flies out of Shannon now - the Shannon Stop-Over has been gone a very long time - and so I ended up looking for the Shannon departures board. Noticing the BA001 and 003 flights there - London City to JFK via Shannon on the outbound leg on an Airbus A318, I was wondering what that service was like.

Read a few passenger reports and noticed a comment about it being like the Pan Am Lunar Shuttle inside - certainly the photos of the all business-class seating look like it.

Which brings me to a clip of the said Lunar Shuttle from Kubrik's 2001:


Which then got me thinking:

1. The Blue Danube or more correctly An der schönen blauen Donau is a beautiful piece of music perfectly suited to a space docking
2. Kubrik was a genius
3. A.C. Clarke's 2001 is also a piece of genius
4. We had vision in the 1960's of a future where space travel and space-stations might be common place
5. We got Twitter and Facebook instead....

 ....which allows me to write about what we could have had instead of having it....

A380 Take-off

Hint: switch to 720p or 1080p and then full screen first:

Planespotting in Wales

Eurofighter Typhoons in Wales...

James May from Top Gear rides in a U-2 spy plane

Stunning!



and some extra scenes:

PARIS (a la El Reg)

PARIS joins the 17-mile-high club

Aerial mission photos for your viewing pleasure

By Lester Haines • Get more from this author

Posted in PARIS, 5th November 2010 12:30 GMT

Well, beloved readers, it's almost time to put PARIS to bed, but before the cocoa and slippers we'd like to share a few aerial photos from our audacious, and ultimately triumphant, space plane project.

Blue1 and the 717

Sadly phasing out two great aircraft types the MD-90 and Avro RJ (BAE146), but getting something interesting instead...the greatest aircraft Boeing have (n)ever produced, the 717...(MD-95). Here's the news and a picture of the liveries (designed by students of Aalto University, Helsinki)...look forward to these very much!

News and pictures from Flightglobal.

(C)Blue1

Blatant advertising: Blue1 offer a great deal, excellent with families - unlike Finnair who are expensive and are greatly reducing their almost non-existant on-board service and BA, again reducing service onboard and penalising families who wish to sit together.

Ps: McDonnell Douglas produced the best.

Dave Carroll is my hero

I'm not saying that United Airlines' customer service is bad, no, it is much much worse. Anyway, here's Dave Carroll's third video about United:



Not only do they break guitars but screw passengers (families in particular) out of money ( 1x23 kg takes a lot less hold space and fuel than 8x20 kg, but the former will cost you at least 150USD ) AND they don't process I94-W forms correctly either.

If your I94-W form is handed back to you at check-in when leaving the USA, inform the CBP as soon as possible with the name of the airline,check-in person, date, flight, airport etc. I'm told that not doing this is "very bad" for the airline.

Good thing that Finnair isn't going the same way....oh wait....

The Romance of Flying...

"Ladies and Gentlemen, you make now unfasten your seatbelts, smoke and move about as you wish. We shall be serving cocktails, lunch and afternoon tea...."

Not quite Ryanair or United Airlines ... anyway, enjoy a time when flying was a pleasure and the flight was longer than check-in and security...

http://www.youtube.com/watch?v=x9pN591cF1Y

Flight 666 videos

OK, so its a Boeing, but at least it was a 757 - anyway, a nice shot of the aircraft and Captain Dickinson at the helm...

http://www.youtube.com/watch?v=qzEQ440YjUE

AirFrance 447 and a new low in news reporting...

The loss of Air France 447 between Rio and Paris somewhere over the south Atlantic has produced much speculation. Last months mayday call by another Air France aircraft (flight number AF445) in roughly the same place due to turbulence has however produced this:

• Uusi Bermudan kolmio kehittymässä Atlantin ylle?
• Translation: A new Bermuda Triangle developing over the Atlantic?

Firstly, a MayDay call is part of the SOPs (Standard Operating Procedures) for Air France (and others) during exceptionally heavy turbulence which can often be found over that particular part of the Atlantic in an area called the Inter Tropical Convergence Zone (ITCZ).  A discussion about the above can be found on the Pprune forums by professional pilots which will shed a lot more light on what happened to AF 445.

One possible "new" Bermuda Triangle theory "could" be based upon the methane clathrate idea where large amounts of methane are released from the sea-bed due to earthquake or other seismic phenomenon. Such a release of gas would cause bubbles to reduce the density of the water and at least, theoretically, sink a ship. Such a methane release could burn or explode and reach to 30,000ft or more thus affecting aircraft. However this has never happened, never been recorded (an explosion reaching to 30,000 might just have been detected) and there appear to be no methan clathrate deposits in the area.

While the loss of AF447 is not known, the development of a "new" Bermuda Triangle is one of the more far fetched theories - a minor application of Occam's Razor is required here perhaps? The most likely theory for severe turbulence in this particular area is the already known, recorded and oft experienced effect of the ITCZ.