Revolut, Monzo, and Incident Transparency

I bank with Barclays. But I also in the recent years have opened up accounts with @monzo and @revolutapp.

While neither of these two accounts are my primary bank account, I do use them extensively, especially Monzo, where I’m both an investor, and took out the Plus option.

What I absolutely *LOVE* about both of these two banks, is how much you can do over the app on your phone. You can see money in an out, AS IT HAPPENS, pay for things and immediately get notified that the money has left your account and even approve online transactions from the app.

But the one thing I really like about these two companies, is how transparent they are as a company and admit “yes, we fucked up, we are sorry. Here’s what happened and here’s how we are stopping it happening again.”

No company, no architect, no developer, no engineer is perfect. We will all miss certain things. There’ll always be edge cases. There’ll always be split brain situations where you don’t expect them.

In this case Revolut’s app had trouble after an update — their full update is here in case you want to read it.

In short, there was an unused database column. Someone presumably thought “hey, no-one uses that, let’s remove it and tidy up the database table”.

As you might expect, something was using it, and that caused problems with the Revolut app. The engineers rolled back the change, but that caused more problems as the old code no longer found the column that was removed as part of the update.

Even at my workplace, we have encountered almost this exact same problem. I had a colleague from another department ask me why they were able to add new entries to a database, but whenever they wanted to edit a record, the system would error.

Turned out a column was _missing_ from the database, and had been for 2 YEARS. The change to the code was supposed to be accompanied by a schema update, but that didn’t happen, for whatever reason.

Since the insert command to the database didn’t specify the column, the default was used, but since the update wanted to modify that field, and didn’t find it, the command failed.

Monzo are not perfect either, they also have messed up, and have been just as transparent. They also had a database mess-up, this time in Cassandra.

Rather than hiding behind jargon or spin, these two companies are so open about their mistakes it’s refreshing. Sure there’s some people out there who are mad at these banks for closing their account, but there’s normally a reason behind it, and Monzo explains why they block accounts in their blog.

Google to buy FitBit

Well, this is a bit of a surprise, but not too much a surprise.

Regular readers will know I’m a FitBit user and have been for a few years.

You’ll also know that I’m an Android user, and Linux user.

So I just read this article, about Google acquiring FitBit. I’m curious to see how they incorporate FitBit and whether improve it or destroy it….

https://www.engadget.com/2019/11/01/google-buys-fitbit/

And a Press Release has just been found in my inbox:

https://investor.fitbit.com/press/press-releases/press-release-details/2019/Fitbit-to-Be-Acquired-by-Google/default.aspx

Training – 7th September 2019

A quick lap around the park. Felt fast and good, but it turns out I was a 5:27, 0:08 slower than my best time. But the chart looks good:

The pace/HR chart also looks okay. Speed (top line) drops at corners, as expected. The last drop is when I’m turning two corners, and I’m under trees, so the GPS probably dropped out.

The HR (bottom line) was fairly stable between 155 and 170 bpm.

%d bloggers like this: