About “That” Prime Engineering article

Everyone who has worked with managed cloud services has experienced the moment when it made sense to move away from managed services.

Turns out, so does Prime Video.

Amazon Prime Video recently wrote about how changing away from managed services and writing a more integrated application saved them money. Despite being a few months old, this appeared to blow-up this week, and predictably has caused some cries of “SEE, SEE YOU SHOULD JUST RUN EVERYTHING YOURSELF”.

But to those of use who have been building on AWS (and other providers) for many years, it’s not a surprise, and we all have stories where we’ve done similar.

I say this as someone who is an annoying cheerleader for serverless compute and managed services, but despite that, I have home-rolled things, when it made sense.

How do you solve a problem

When you’re solving a problem, you look at what the managed services that you have available, considering factors like:

  • Your teams experience with the service
  • Limitations on the service, and what it was intended for, against what you’re doing
  • What quotas may apply that you hit
  • How the pricing model works

While pricing for managed-services is generally based on usage, sometimes specific costs will apply more to your workload, e.g. if you’re serving small images, you’ll be more impacted by the per-request cost than the bandwidth charges.

I would be surprised if an experienced architect hasn’t faced a situation where “Service X would be perfect for this, if only it didn’t have this restriction Y, or wasn’t priced for Z”.

My example

We’d built out a system that was performing 3 distinct processing steps on large files.

The system had built out incrementally, and we had the 3 steps on three different auto-scale groups, fed by queues.

While some of the requests could be processed from S3 as a stream, one task required downloading the file to a filesystem, and that download took time.

The users wanted to reduce the end-to-end processing time. Some of the tasks were predicated on passing prior steps, and so we didn’t want to make the steps parallel.

Attempt 1: “EFS looks good”

We used the ‘relatively’ new Elastic File System service from AWS… The first component downloaded the file, subsequent operations used this download.

This also had the advantage that the since the ‘smallest’ service was first, you paid for that download on the cheapest instance, and the more expensive instances didn’t have to download it.

We developed, deployed, and for the first morning it was really quick… until we discovered that we were using burst quota, and spent the afternoon rolling back.

Filesystem throughput was allocated based on the amount stored on the filesystem, but as this was a transient process, we didn’t replenish it quickly enough, and didn’t like the idea of just making large random files to earn it.

Now you can just pay for provisioned throughput, perhaps in a small part because of a conversation we had with the account managers.

Attempt 2: “Sod it, just combine them”

The processes varied in complexity, there was effectively a trivial, a medium, and a high complexity task… So the second solution we approached was combining all the tasks onto a single service… the computing power for the highest task would zoom through the other two tasks, and so we combined them into what I jokingly called “the microlith”.

We didn’t touch the other parts of the pipeline, or the database, they remained in other services, but combining the 3 steps worked.

What did we gain

The system was faster, and even more usefully to operators, more predictable.

Once processing had started you could tell, based on the file size, when the items would be ready…

Much like “lower p90 but higher maximum” feels better for user experience, this consistency was great.

What did we lose

Two of the three components had external dependancies, and this did mean this component was one of the less ‘safe’ to deploy, and while tests built up to defend against that… the impact of failed deploy was larger than you’d want.

In Conclusion

There are always times when breaking your patterns makes sense, the key is knowing what you’re both gaining and losing, and taking decisions for the right reasons at the right times.

Prime video refining an architecture to better meet scaling and cost models, making it less “Pure”, isn’t the gotcha against these services that some people would have you believe.

“Pure” design doesn’t win prizes.

Suitable design does.

Can I port my number out of Skype UK?

Here’s the one wild secret they don’t want you to know.

Please forgive me the horrible SEO title and URL…

I recently ported a number out of Skype UK to a much cheaper SIP VOIP provider. Skype served me well for a number I really just needed for compliance reasons… and it seemed obvious that I should actually transfer it to a supplier that would cost me about 12GBP per year, rather than 57 EUR as I was paying.

Number porting in the UK is a magical mystery tour, for all the times it “just works” other times you’ll feel like you’re playing the worst possible game of DND, with a horrible enemy and a disinterested Game Master.

Skype initially said “you don’t need to do anything special, just ask the new provider to port in” but turns out there was this one secret trick they didn’t think I’d want to know…

Skype expect your ‘surname’ as provided by your new supplier, to actually be your Skype username.

I discovered this after two failed porting attempts (for which my new super cheap provider charges me, which I understand, since the ongoing rental is so cheap).

I had asked Skype multiple times what to do: before the first port, after the first failure, after the second failure.

Most of these interactions were pretty infuriating “Porting is done by your new provider… it’s nothing to do with us” – despite that fact that My New Provider asks Skype to port, and Skype then says yes/no… They are pretty involved in the situation.

Skype wouldn’t tell the new provider what was wrong, beyond “the surname didn’t match” – This is entirely correct, because since Skype UK don’t seem to implement any porting code/verification scheme, for security they can’t and shouldn’t tell the port destination…

However they wouldn’t then tell me, via an authenticated channel, what they were expecting. Merely “you did it wrong try again… porting is nothing to do with us.”

It was only when I then went on another chat, talking about going to the ombudsman, and generally being a pain, did the porting team authorise the port, and revealed to the provider “yeah, the surname needs to be the username”.

This is not mentioned on their documentation. Or provided in live-chat because it’s seemingly a rare occurrence.

So if you’ve come to this post, having had problems porting out, try again telling your new provider that your ‘surname’ is in fact your username.

2023 Comms Resolutions

What things can you do in 2023 to make you communications more efficient and considerate in the world.

I don’t really like New Years resolutions for reasons beyond the scope of this post.

This year however, am going to try and make a few changes to how I communicate, in work and otherwise.

“No Hello”

No Hello on instant messaging.

I hate being on the end of the Dangling Hello, and the 15 minutes of massively predicting what the person is wanting. But I still find it very hard to bundle in all up in the first message.

Equally, 4 notifications in quick succession can feel like literal torture.

You can still ask how people are doing, but you can just include that upfront, in a single message.

Hello X, hope you’re good, can you tell me what’s going on with TICKET-123

Me, Slack, This Year

Priority Tagging, ideally lower

Low Priority exists as well as High Priority on emails.

Flagging a gossipy/catchup IM as such in the opening.

Clarify & Summarise

The discomfort at being That Guy who pastes back the summary of what you agreed is less than the pain when you discover that you weren’t all sharing understanding.

When half the team thought “advance by 2 seconds” meant delete 2 seconds, and the other half thought add 2 seconds..

Always a default

When arranging things, I’m going to offer a default, always.

“I’m free all day” vs “I’m free all day, how about 11”

Make it easier to say “Great” done.

Stick to Core Hours

I’m a freelancer, I work self-defined hours… but that’s not mine to share with others.

While it’s useful for me to get thoughts out of my head into an email, that doesn’t mean I need to get them forced onto other people…

  • If I’m sending an email, I’ll set it to send later
  • If it’s an IM, I’ll set Slackbot to remind me or maybe the person, during the next working day

In Conclusion

We all drowning in a sea of notifications, if you can make yours just a little better, you make it easier for people around you to help you.

Smartspeaker listening is massively up, but sure, delaying podcasts will help drive adoption

The BBC really need to add more Siri intents to Sounds to enable smart speaker listening.

Rajar data continues to show that Smart speaker listening is on the up.

As someone thoroughly locked into the Apple ecosystem, until recently I’ve not been able to easily ask to BBC Radio services through my HomePods. I had to follow some Reddit posts to install shortcuts “hey Siri play Bbc 6 music” and suddenly I find myself listening to more BBC Radio as a consequence.

Previously I think you had to listen to stations ‘enough’ for Siri to recognise the activity, then it could be a suggested shortcut. It was a bit ugly, and down to how intents originally worked.

The Siri APIs have got more developed over time, and now it is possible to do this in a way that doesn’t require upfront declaration.

It’s funny then, that given the choice of “adding a play with Siri intent to BBC Sounds” or “delaying podcast release to open platforms”, that Auntie chose the latter…

This has the strange result:

  • The BBC’s first party actions have me listening to less BBC Podcast Audio – why listen to a topical podcast 4 weeks later, and having to remember to check BBC Sounds doesn’t match my workflow
  • Actions by a Third-Party, have me listening to more BBC Live audio

I know there are always backlogs, but Siri intents have been around for a while now…

You make me install it… you tell me how to remove it

Having installed some invasive ‘online proctoring’ software, I tried to ask the company how to uninstall it.

I was, finally, getting around to doing AWS certifications, and one of the way you can do that is via the Pearson OnVue proctoring system. You run software that limits what you can use your machine for, stops you using multiple windows to look up answer. It asks for a fair bit of access when you run, unsurprisingly.

I installed it, I ran the test to see if it worked, and shortly afterwards was having problems with my computer and the clipboard – and wondered if that was a ‘feature’ of this software.

I have since resolved these separately, but I wanted to uninstall OnVue, but there is NO detail of how to do this on the website.

I have asked all their contact channels, “how do I uninstall it” – I get back a variety of canned responses:

  • “you can’t cancel an exam via email”
  • “if you run a test exam you can see if the software works on your system”

Now given it doesn’t look like it was an “installed” app and just an application that ran from a zip file, uninstalling it could be as simple as not running it ever again, and deleting the download.

But I don’t know if it hasn’t installed a few system extensions or similar, I’ve had a quick look and I don’t think it has but is it too much to expect a webpage owned by Pearson that says that – right now the search results for “remove onvue macintosh” are swamped by advertising pages for Mac removal software.

A document that states what to do online, an answer in the knowledge base so agents respond – is really the bare minimum.

If you make me run/install it, give me a clear way to remove it.

The Weaponisation of Resilience

(This post inspired by some posts I saw on LinkedIn, and some client experiences from many many years ago)

Resilience is a useful property.

We want it in many places: In our infrastructure from floods or traffic spikes, in our organisations from attacks by bad faith actors, and within ourselves from unexpected or exceptional events in our lives.

Now, in the last few years *waves hand* we’ve had quite a bit going on, and many of us have had to call on that resilience reserve more than usual.

Maybe as a results of that, or a general awareness of mental health in the workplace, it’s now something that’s being taught to employees.

While I think that is a good thing, I think that has the perception to be weaponised.

A resilient worker, or more likely a team, has the skills/headroom/reserve to cope with a “once in an N” event, every “N”. So a “once in a week” exception every week, a once in a month exception every month, etc.

I worry that bad managers and teams, will weaponise that resilience, and expect teams to be resilient against all events, even if they’re facing a ‘once a year’ event every month.

Exceptions aren’t avoidable. Things do change, go wrong, go better, go worse.

You can’t avoid all exceptions, and those are the ones that will draw on the “resilience reserve”, but if your team is constantly facing exceptions that are caused by poor coordination or planning – you’re wasting that valuable resource you should be keeping for elsewhere.

Giving your team the tools to be resilient is great, but you’re not giving them invincibility.

Is your software more important than you realise?

Software that isn’t “safety critical” can have real-world impacts.

If you’ve been working in IT for as long as I have been, you’ll maybe remember this wonderful example of legalese:

NOTE ON JAVA SUPPORT: THE SOFTWARE PRODUCT MAY CONTAIN SUPPORT FOR PROGRAMS WRITTEN IN JAVA. JAVA TECHNOLOGY IS NOT FAULT TOLERANT AND IS NOT DESIGNED, MANUFACTURED, OR INTENDED FOR USE OR RESALE AS ONLINE CONTROL EQUIPMENT IN HAZARDOUS ENVIRONMENTS REQUIRING FAIL-SAFE PERFORMANCE, SUCH AS IN THE OPERATION OF NUCLEAR FACILITIES, AIRCRAFT NAVIGATION OR COMMUNICATION SYSTEMS, AIR TRAFFIC CONTROL, DIRECT LIFE SUPPORT MACHINES, OR WEAPONS SYSTEMS, IN WHICH THE FAILURE OF JAVA TECHNOLOGY COULD LEAD DIRECTLY TO DEATH, PERSONAL INJURY, OR SEVERE PHYSICAL OR ENVIRONMENTAL DAMAGE.

Windows NT4 License agreement

It’s a pretty good example of where our minds tend to go when you think of “safety critical” systems. I tend to also think about things like complex train automation systems or the Therac-25 radiation therapy machine.

All things that are complicated, but are generally grounded in physical interactions with machinery, machinery that has high energy, or that interacts with other humans.

This came to mind because once again the Post Office Horizon Scandal, one of the biggest miscarriages ever in justice in the UK, is in the news.

If you weren’t aware, the system was buggy, could cause the branch to have massive shortfalls, giving postmasters three options.

  • Make up the loss up themselves, and hope the problem didn’t happen again
  • Report that their accounts balance, which was an act of fraud
  • Try to report to the Post Office which would be unhelpful at best, or began an investigation at worse

The results of this were bleak:

  • People were wrongly convicted of fraud/stealing from the Post Office
  • People were wrongly imprisoned
  • Some people ended their lives in the immense shame of being someone who stole from their local community

In hindsight, that looks pretty safety critical… lives were materially changed, damaged, or extinguished.

What’s worse is that people from the software vendor, and the post office claimed that the system was robust, that remote access wasn’t possible – at the same time as planning remote access to resolve issues caused by known bugs.

The latest BBC Radio 4 program on this (after an amazing series), had an instance where a Post Master lost his branch due to these bugs, a new owner bought the shop, only to then experience the same bugs. The helpline gave the same line “Nobody else is reporting these problems” which sounds highly unlikely to be true.

Sure some senior people at the time have stepped down from their non-exec directorships.

In my view this is either negligence as they should have done the due diligence to ascertain that the system was generally robust.

Software is everywhere.

Ovens have Wifi, cars have highly complex computer vision, human bodies have attachments controlling insulin flows. People had artificial eye implants to help them see, that the manufacturer no longer supports.

Whistleblowing is a painful and sacrificial act for the person who does it.But if you see people from your company, testifying in courts of law that “there are no problems with the software” (an impossible situation in all by the smallest of programs), we need to provide better ways to help this information surface.

Maybe if defence teams were better briefed, a statement like that could be countered with “No problems? Cool, we’ll verify that with an extract from your Jira instance” or “a third-party code review wouldn’t be a problem”?

I don’t know the solution.

I’m not a lawyer, I’m not an ethicist, I’m not someone who typically works in these kinds of environments – but I do know that lives were lost due to an accounting system being buggy.

And that doesn’t sit right with me.

The one in which I learned to build a chat bot, and a bit about how I learn

Why revisiting known problems can be a boring but reliable way to learn, and how to think about that for Hackdays

I’ve two problems I keep coming back to and implementing (or attempting to) every now and again.

First is my home-grown voicemail system, not that anyone actually makes standard telephone calls to me anymore, but after a series of “voicemail with dictation” providers left the market, I rolled something together with Twilio and App Engine.

The other is the data feed for the TfL London Bike here scheme. I have failed to buy myself a bike, and still rely on the hire ones, and before app coverage was good, I had a webpage that could show me the docks around where I live.

These have both been revisited over the years, the Voicemail system got moved from being on Google App Engine which returned a complete web page (remember those), to running on AWS as a Single Page App, listening to an MQTT change feed, and connecting to the AWS services to retrieve data for the React App to update on screen.

Meanwhile, although the original Bike webpage went stale and stopped working, last year I started writing an application in SwiftUI that would display the data. Thanks to changes in iOS/Xcode that project can’t even run to get a screenshot anymore…

I’ve long wanted to be able to text something, and to get a reply about the bike docks nearby. Because I’m an iOS user, the Siri intents are very limited, and text message interacting is easier with voice – this would keep my eyes on the road.

So, after an idea just before bed, over the last few days I’ve created a chatbot, and I can ask it questions about the Hire bikes.

But why do I keep revisiting these problems?

TL;DR They’re boring problems that I understand the domain of.

I learn by doing.

My Professional Development Plan would be summarised as Continually Feeling Just A Little Out Of My Depth and managing to keep up.

It’s very much “I learn this stuff because I HAVE to learn it”.

Outside of that directed work frenzy, I have limited windows for learning – periods when I feel interested and able to commit some time to learning. I’ve found that I can generally learn 1 of 2 things:

  1. Approach: Something new about an existing domain I know: e.g. Using a new language, web framework or API to solve a problem I already broadly know.
  2. Domain: Learning new problem domains with existing technologies, e.g. building out a new website to use a new API, technologies I understand in areas I haven’t previously worked.

When I try to do both at once, I quickly get frustrated and quit. I’m not a full time coder, I architect systems and work with teams to coach them into building things, but I’m not best served building things myself, even though I love to work with those who are building.

When I’m working, the need to get things done powers me through any frustration walls (mostly). But when I’m doing stuff for ‘fun’, that doesn’t happen as much, so I try to only do one of the two things.

So, What does BikeBot do and What Did I Learn?

I can ask BikeBot for the details of a specific hire station if I know the name, which is useful if I’m heading to a place I know well, and just want to get details of bikes or docks that are available.

I can also ask bikebot for the dock Nearest to a point of interest, when I don’t know what the station is called.

Bikebot then returns the data from the TfL API, and is accessible over the phone with speech recognition or could be available by SMS if I configure an integration.

So, by revisiting a familiar problem, I got to learn:

  • AWS Lex, the chatbot tool
  • AWS Location, the tool I use to geocode “I’m at this Place give me dock”
  • AWS Connect, the contact-centre product that makes it accessible to voice over the phone

I now have a neat demo, which with a little more work provides me something I can use myself.

I also re-learned just how easy managed services can make solving problems, because so much of the hard lifting is done for you. I would never find the time to do fuzzy matching of station name to user input, but if I give Lex that list, it’s done for me. Not perfectly, but orders of magnitude better and faster than I’d ever be able to do it myself.

“erm, cool story bruh, but how does this help me?”

If you’re running hackdays, think about how many ideas that teams have, and if the teams are capable of learning both 1 & 2 at the same time.

Some companies frown on “doing things to do with the day job” on hackdays, really wanting more Blue Sky Out There things, but maybe your team aren’t really up for that. Or if they are, they need a bit more planning, so teams and ideas are kind of sketched out ahead of the hackday, along with any of the pre-requisites to make progress quicker.

Monoliths or Microservices: how about a middle way?

Should we deploy as micro-services or monoliths, how about neither.

The latest argument that we’re having again, is how we should deploy our systems, and we’re asking “micro services” or “monolith”.

Now, I’ll try to skip past what we mean by all of those things (because it’s covered better elsewhere), but in essence, we’re asking “does our software live in 80 repos or 1 repo?”.

TL;DR How about we aim for 8?

What does good deployment/development look like

In an ideal world, we’d have the following properties in our deployment:

  • It would have appropriate tests and automation, so deployment is easy and doesn’t feel risky
  • The potential impact to a deployment should be predictable, something over shouldn’t impact something over here
  • It should be clear where to look to change code

Problems with Micro-services

  • If you go properly granular, it can be difficult to know which repo code resides in – if you pick up a ticket, you should need to spend 15 minutes to identify where that codes live
  • Deployment of related services may need to be coordinated more closely than you’d like, ensuring that downstream components are ready to accept any new messages/API calls when they arrive
  • Setting up deployment for each new component can be time-consuming (Although with things like CDK/Terraform etc, it should be possible to template much of this to a config file for the deployment system)

Problems with Monoliths

  • Code can potentially leak into production more easily – requiring more robust feature-flagging to hide non-live code. While this is good practice, it becomes a requirement in larger repos – you can avoid this by ‘dev’ deployments not being in trunk, but that’s a different kind of deployment complexity
  • Spinning up another instance of “the system” for testing of a single component may be more expensive and fiddlier than duplicating an individual component
  • The impact of a deployment may not be known, you may need to assess if other commits included in what you’re putting live could break things, this may increase deployment friction

How about Service Cluster Deployments

In a prior engagement, we built what was really a task management system.

  1. Messages would arrive which could potentially make new tasks for the system, or update existing tasks: these were handled by the task-creator-and-updater
  2. The task-viewer would access the database of tasks, cross reference with other services, and create a unified view of the task list
  3. An automation component would use the output of of task-viewer to initiate actions to resolve the tasks, which would ultimately result in more messages arriving, which then updated the task database

In our deployment, these components were all in 3 different projects, the micro service model. And it worked, but is also an example of where these 3 components could be combined into one functional service repo.

This makes sense to me because the 3 services are closely coupled, especially between the task-creator-and-updater and the task-viewer. So maybe they could have been in a combined repo task-management

With this setup I could still feel safe doing a deployment on a Friday afternoon to one component, because even if the task management system failed entirely, the manual processes were in place to allow recovery until the system could be rolled back.

Meanwhile another one of our components, the cost of a failed deployment was so high, and even if it was recovered the time-critical nature, meant we only deployed during ‘off-peak’ periods of the week. Could it have been made more robust? Probably, but it was also a relatively static system – that effort was better spent on other components that were more ‘active’.

In summary

Your deployment should work for your team. It should be based on templated conventions that allow easy configuration of new deployments, and it should be as granular as makes sense.

Instead of worrying about being “truly micro-services” or “fire & forget monolith” find the smallest number of functional groups to keep your code in. That way you can have scope-limited deployments, without having hundreds of repos.

Finally, please, just-name-your-repos-like-this, it’s funny at first giving things amusing names, but honestly, kitchen-cooking-oven is far more supportable than the-name-of-a-dragon because it gets really hot.

Things that it was good we learned this year

Rather than a “hey look at the good that actually happened in 2020” I’d rather take a more realistic view: there are a whole bunch of things that are very good for us to have learned/been reminded of – but that aren’t necessarily good

Medical Science can do amazing things, when we want it to

  • The virus was genetically sequenced within a month of it being discovered
  • The speed at which we got a whole range of vaccines/vaccine approaches into trials was incredible – that many of the vaccines were made never having been near the virus, is incredible
  • RNA vaccines could revolutionise things – we’ve shown efficacy and some have suggested that if we have vaccine templates in place for major families of pathogens we could have the ability to rapidly respond to the next pandemic
  • Clinical trials, such as the UK “Recovery” trial found existing drugs that have improved survival rates

Turns out we need society and collective action

  • Masks help other people more than they help you… without that sense of shared responsibility their use won’t be consistent
  • Local Mutual-Aid groups popped up around communities, and people helped those shielding or isolating

The situation has codified and made visible inequalities

  • People with jobs where they can comfortably work from home, have been shielded from a lot of the worst of the situation
  • They can likely afford to buy delivery food, order online – and effectively outsourcing their risk to someone else
  • Freed from that casualisation of employment, they have far less concern if asked to isolate
  • Contactless payment everywhere is great for those of us who hate carrying cash, but less good for the under-banked who find it hard or impossible to get a contactless card or account

The casualisation of employment hurts us all

  • Casual workers tend to move around between clients and sites more, which in the case of Melbourne’s Aged Care facilities, meant that they were in a prime position to move the infection between facilities
  • Casual workers also can’t sit at home as easily waiting for a test results because they have bills to pay, or to isolate when they’ve had a contact.

Not all Key-Workers where a fancy uniform

  • Health service employees have had a terrible time, working in stressed conditions, seeing more death than any of them signed up for. But they did sign up to work for a critical function in society.
  • The same can’t be said for people who work on the tills in the supermarket. We discovered that food-retail is pretty important – but until now those people didn’t get any of the cachet for that role
  • Similarly delivery drivers, postmen, transport workers… the list goes on, but there are numerous roles, that are occasionally looked down on, that turn out to be vital

Food supply chains maybe don’t need to be quite so lean

I love a just-in-time manufacturing supply chain as much as any logistics nerd, but while it makes sense for car-parts, it maybe doesn’t make sense for everything

  • Food systems adapted, but initially they were shown wanting for supplies (interestingly packaging rather than the food goods in some cases)

5 days a week in the office is dead, remote learning can be a thing

  • Turns out that most jobs can almost be done at home – knowing this might help people less able to travel due to health conditions get work
  • 5 days a week at home isn’t great though: it can be lonely, cramped, maybe not possible if you’re in a shared home. I suspect we’ll end up with most people doing 2-3 days a week in an office and the rest remote
  • Local co-working spaces may well pop up – many people who want to get out of the house may not need a commute, they just need a comfortable place to work where they can see people, just not their colleagues
  • Many disabled people have tweeted, in justified disgust, that they asked for remote learning for years, and were told “it wasn’t possible”. Turns out that lecturers can load Teams when able-bodied people need that facility

The Economy needs to adjust to the end of Big City Centre Offices

  • Our economy is too service sector heavy: Jobs have been lost because people aren’t coming into city-centres anymore. I sympathise with those employees & unlike a govt campaign (actually from months before the pandemic) not all of those people can retrain in cyber
  • Despite this hurt, and what politicians/commercial property owners say in press op-eds: we are not obliged to support the service-sector in the city centre as a patriotic duty
  • Some of those jobs may be relocated to places nearer where people are now, (personally I’ve still bought far too many takeaway meals while WFH)
  • Going forward, do we need more mixed-use neighbourhoods like you see in mainland Europe, driving the demand for services, not driven by office-workers

The NHS

To those people working in the NHS, I think we all thank you, and hopefully we’ll find ways to do It that go beyond clapping

  • While no health service truly coped with this, years of recruitment shortfall have exacerbated difficulties in the NHS response
  • While impressive how quickly we built the Nightingale hospitals, because admitting hospitals needed to provide staffing and equipment for the patients, it made little sense for them to be used, resulting in them being white elephants
  • When freed from arbitrary government targets, the NHS can radically reconfigure itself when it needs to.

Personal Protective Equipment (PPE)

  • The entire world shouldn’t outsource production of PPE to one area in China, that happened to be hard hit by the outbreak – we should have some on-shore production that could be ramped up at times of crisis
  • PPE Management shouldn’t be given to random companies – this is a UK specific one, but we love outsourcing things, and sometimes you can’t just treat specialist things as commodities
  • Those PPE stockpiles should be actively managed – rather than building up emergency stockpiles – we should always be taking stuff out of them and replenishing, that way we don’t end up with years old PPE that needs to be re-certified for use, which doesn’t instil confidence

UK Government Response

  • The Prime Minister undermining the response before it even began, when the government message was “Don’t go home for Mother’s Day” and the PM was quoted “I’m still hoping to see my Mum” wasn’t a good look. Nor was sanctioning his advisor for taking a unique eye-test in Durham
  • Any effective pandemic response always feels excessive, because it’s done before it feels needed. Having a PM who is unable to make decisions before his hand is forced, doesn’t work so well
  • The UK needs to give up its obsession with throwing problems at generic business process outsourcing companies, they do a shit job time and time again, and have take far too much money for a sub-standard response
  • Continuing the above, local contract tracing teams work better than centralised teams – replicated in other places, not just the UK
  • After a brief period of IT improvement though GDS, the UK can once again have poor IT processes waste money with private IT companies: just look at the money spent on the initial Bluetooth app that everyone who understood iOS restrictions told them wouldn’t work
  • Worse the failed excel handover mechanism that cost lives because contacts weren’t followed up. I know that people do things at haste in situations like that… but still

We need to address online-misinformation

  • There have always been contrarian conspiracy people, but without the distribution channels of social media, their impact has been limited: their actions undermine trust in the response, vaccines. etc.