Learning is not a spectator sport

OK, that title sounds a bit weird, so let me explain.

If you live in Australia you may have seen that the national airline Qantas had a little stumble last week. I would log on to the mobile phone app, and normally it shows a brief summary of your frequent flyer membership

The problem there is .. if you refreshed the screen, then the app also would show you details of random members of the frequent flyer program.  I didn’t take any screenshots, so these are some example from those posted on Twitter, each time after someone hit refresh on their own app.

Just random (but real) members details coming up on my app!

In isolation, that does not seem like such a big issue, but when presented with someone else’s details, you could also then click on the “My Bookings” and lo and behold, you could also get their boarding pass for upcoming flights!

That of course is a much bigger deal.

Anyway, Qantas had to roll out an emergency fix and after a day or so, things got back to normal (although apparently a lot of customers had to get boarding passes re-issued at the airport).

This post is not about dunking on Qantas – I use them regularly 🙂 but it does bring me back to the title of this post.

If the client facing part of your app is a 50 megabyte chunk of Javascript that does complex interactions and interpretations of data, then if that app has a bug like the Qantas app did, then that is a nightmare to resolve, because the smallest piece of the task to fix it is the software itself. The much larger challenge comes once the bug is fixed – you need to push the fix out to everyone running that app. Maybe some people have automatic updates turned on, maybe some people have that disabled. What if someone is using the app and never exits it – how do you force them to get the fresh update. It often seems in these days of ever larger apps on our phone that we have forgotten the lessons we learned (the hard way) in the days of client/server. The bigger the client, the harder it is to maintain.

Conversely, if your app is primarily just doing rendering of data, that is, it does not do a lot of complicated logic, then when a bug is reported your customers, there is a much higher probability of the issue lying with code that is running inside your data centre on an app server or in the database. Both of those things are much easier to fix than the millions of devices out there on the internet.

I’m a data centric app fan due to my long time use of APEX, and even in the conventional full code arena, I’ve always been a fan of putting logic within or near the database. But my motivations were about the common pain paints – better performance, reducing latency, etc. It was only when I experienced the Qantas issue that I realised another facet to this – Data Centric apps are easier to fix when they go wrong.

This is why I think there’s a much bigger future in PWAs on your phone. Not necessarily for the easier build/deployment model, but for the ability to rapidly address problems when they occur, because there is likely nothing needed to be fixed on the app.