May 27, 2021

s09e32: "We Really Didn't Expect This To Work"

0.0 Context setting

It’s a can’t-decide-to-rain-or-keep-dry Thursday May 27 2021 in Portland, Oregon.

Straight into it, for this episode.

---

1.0 Some things that caught my attention

Phew. 2 short things, one medium thing, 2 short-medium things, and then one long thing. Clearly keeping myself on my toes.

---

1.1 Very short things

• A thread from Tiffani C. Li, a technology and legal scholar, recommending a short reading list for foundational tech knowledge. The list happens to be for law students and lawyers who want to be work in technology law. One title that stood out to me was The Pattern On The Stone: The Simple Ideas That Make Computers Work” by W. Daniel Hillis¹.

• Via Australia’s itnews, the three out of the four biggest Australian federal agencies have more IT contractors than internal staff, “with almost 7500 IT contractors split between the two”. The breakdown of staff vs contractor at each agency is on page 77 of the Digital Transformation Agency’s report². I’ve leave it as an exercise to the reader as to whether this is “good” or “bad” and under what criteria “good” and “bad” are defined.

---

1.2 A million-to-one chance³

So there’s this project called Dolphin. Dolphin is an example of sheer geek bloody-mindedness: it’s a project to emulate the Nintendo Gamecube and the Nintendo Wii⁴ games consoles.

Last year, Apple finally came out with its own processor, with an architecture called Apple Silicon. This is, like, the fourth time Apple have changed CPU architectures, and each time it’s been difficult to pull off. Changing a CPU architecture while hundreds of millions of people use your computers is like, I don’t know, another software metaphor that involves rebuilding a plane while you’re flying it, but instead of a plane it’s every single plane that’s in flight at a single moment?

Anyway: Dolphin runs on x86 (Intel and AMD) processors and also on 64bit ARM processors, and ARM is the same architecture that Apple.

Long story short, the Dolphin team wanted to see if they could get Dolphin running on Apple’s new chip, the M1, in part because Apple’s marketing is extraordinarily effective and all signs indicate that the M1 processor is unreasonably efficient and fast. But! Like I said, the whole thing about rebuilding planes while they’re flying.

There’s an easy version: Apple makes rebuilding the plane (getting your software to run on the M1) a bit easier by translating your stuff from an x86 processor to an Apple one. Dolphin as a whole works by using a technology called JIT, which means just in time, and is a kind way to translate the instructions for one kind of system and processor (e.g. a Nintendo Gamecube or Nintendo Wii) to run on whatever the kind of CPU is running it.

Dolphin actually has two JITs: one for x86 processors, and one for AArch64, the same architecture as Apple’s processor). The AArch64 JIT lets Dolphin run on ARM Linux systems.

Dolphin already ran on an Apple silicon M1 mac by using its x86 JIT (translating Gamecube/Wii to x86 architecture) which was then translated by Rosetta, Apple’s technology for running x86 software on Apple silicon. Frankly it’s pretty cool that works in the first place, and it even worked respectably!

Anyway, there’s a whole bunch of stuff to do with the combination of the JIT and Apple’s Rosetta that mean the software isn’t running as fast as it could be, so the Dolphin team decided to start doing the work to make sure Dolphin could run natively (i.e. without any translation) on an Apple Processor. That meant using the AArch64 JIT.

Very long story short: they did it, and it’s really good! Their blog post has charts and everything.

The end.

Wait, what?

OK, fake-out: see the biggest test was getting an x86 Dolphin game to play online multiplayer against an AArch64 game, which the Dolphin team hadn’t been able to test before. So they tried that: Apple silicon playing against x86.

Very, very long story short: That worked, too!

Really now, that’s the end.

No, wait.

Caught my attention because: look, there’s this amazing quote at the end:

“Yes, we’re aware that Windows and Linux AArch64 devices existed before the M1. There was no allure to testing netplay on those because they could not run Dolphin reasonably. We really didn’t expect this to work or we probably would have tried it sooner.” (my emphasis)⁵

Just… just to sit with that. We really didn’t expect this to work or we probably would have tried it sooner.

This has come up in some many contexts in work before and not just in tech and software. I think it’s a good example of “do something, actually try doing something and you can be surprised, because if you don’t try, you can never be surprised”. It doesn’t mean things will always work, but if you’re assuming something won’t work, then… what’s the quickest way to figuring out if that assumption is wrong?

---

1.3 Jump off cliffs and burn bridges

Gizmodo’s coverage of ExxonMobil’s annual shareholder meeting (“Shareholders Tell Exxon to Eat Shit”) was a good example of When You Have No Fucks To Give. An activist investor called for new candidates on the board with climate change and sustainable experience, and the rest of the institutional investors backed them. I stick this in the “read the room to figure out if all it takes is somebody to go first” combined with “do you have the courage to go first”, which is close to “no fucks to give” and “I’m on this side of the bridge, you’re on the other and I’ve got the matches”. I mean, my point here isn’t to be a dick and to burn bridges, my point here is to figure out if the other people/stakeholders/entities involved need the safety to be a follower. Which can sometimes involve knowing they can exercise the excuse of “well, it was Engine’s idea, not ours!” To which the response is, “well, if Engine told you to jump off a cliff, would you?” and clearly the answers is sometimes “yes”.

---

1.4 Studying Reddit

Via Dr. Casey Fiesler⁶, an overview of 727 papers studying the use of Reddit as a data source⁷. Some quick findings: the majority of works were in the disciplines of Computer Science, Mathematics and Engineering; 832 unique subreddits were name but only two were given “fake names” to protect privacy (here’s a table of the 20 most commonly studied subs⁸, the top 3 are somewhat unsurprisingly politics, worldnews and askreddit); the most prominent data sources studied are subreddits covering politics, mental health and drug use; 30% of the studied research used direct quotes from users (big ethics flag given the subjects studied and potentially vulnerable populations!). Here’s a key part for me:

“[while] Reddit has become an important data source for researchers, there are serious questions regarding the degree to which this prominence matches users’ expectations for their data. Many subreddits position themselves as small communities rather than public fora, setting up a potential mismatch between IRB interpretation of Reddit as a public space and users’ understandings of the communities they are participating in” (my emphasis)

---

2.0 What Digital Doesn’t Do

This is part of a continuing recent series on digital in the context of government⁹. Really, though, I think the majority of it also applies to non-government organizations when you get to the same equivalent size and scope of operation.

Here’s the short, pithy version:

• Digital doesn’t change your process
• Digital doesn’t increase capacity
• Digital doesn’t change how people work
• Digital doesn’t make things more transparent
• Digital doesn’t improve customer service
• Digital doesn’t improve collaboration
• Digital doesn’t change policy
• Digital doesn’t make you more efficient

I mean, it’s not like digital is magic.

I see what amount to these expectations fairly often when people or organizations are shopping for big new IT/technology systems. Often they’re things like system replacements or modernizations, more rarely are they green field, brand new systems.

Let’s take one example: Digital doesn’t increase capacity. This came up while Cyd Harrell and I were working on the curriculum for an upcoming course we’re teaching together:

On the one hand, of course digital should increase capacity. Digital brings with it Efficiency Gains and Dynamic Collaboration, all those fun and exciting words that are frustratingly and potentially strategically vague.

You could have a crack team working on a great digitally enabled user experience for, I don’t know, getting a vaccine appointment, but that digital service doesn’t actually create any more vaccine appointments if they’re already oversubscribed. It doesn’t fix an underlying problem.

Applying “digital” to a thing that’s broken will just mean you have a broken digital thing. Never mind you may have spent lots of money and time and burned through people to get to the broken digital thing.

(Yes, it’s not polite to call things broken. It’s not like they’re completely broken. Probably. But when those things don’t work for people, then those people are justified in saying their experience was broken).

Instead, what “digital” does, or what it can do, is show you what’s broken or what isn’t working. If you want to know. If you pay attention.

Part of the problem here is when digital/technology projects come under the ownership of technology leaders without enough leadership and direction from the actual program or service.

Here’s my pithy list to make a point again that absolutely doesn’t work if you take it absolutely:

• Digital doesn’t change your process
• Digital doesn’t increase capacity
• Digital doesn’t change how people work
• Digital doesn’t make things more transparent
• Digital doesn’t improve customer service
• Digital doesn’t improve collaboration
• Digital doesn’t change policy
• Digital doesn’t make you more efficient

Process. Yes, digital changes your process because now your process for getting a thing approved is in Servicenow instead of… whatever it was you were doing before. Congratulations! You have a digital process! Sure, it’s changed. Is it… better? How would you know? Is it better in the right way? What are the right ways?

Transparency. Sure, digital means it might be easier to publish a dashboard and datasets, but… what for? Who’s using them? What are they using them for? What’s the goal of transparency, anyway?

Collaboration. I mean, in theory sure your case management system lets people collaborate because now you can schedule more meetings. But is that collaboration better? Easier? Faster? Is the quality of the collaboration better? How, exactly is using a new technology supposed to accomplish that on its own?

This was, really, a long-winded way of saying that duh, tech/digital isn’t the thing. Sure, you need it. Most of the time, doing digital is the how-the-service-is-used. Implementing “digital” means figuring out the how, which is an opportunity to change the rules around the how (the policy, process, whatever) and improve them. Or, you know, you could not do that and just think that doing the implementation work will do the trick.

In this way, I like to think that digital/modernization/digital service projects in government and the private sector are more like an excuse to ask quite pointed questions that nobody will like the answers to and may spend quite a lot of time, energy and emotion avoiding and sticking their head in the sand.

I hate to use the phrase, but disruptive kind of works here: asking those questions is (breaks out thesaurus) can be seen as troublemaking or unsettling, and the promise of digital is that things can be done substantially differently because different capabilities are now available that weren’t when existing processes were defined and laid down. You can do things differently now, which doesn’t necessarily mean that it’s your fault things are done the way they are now.

Doing digital won’t make things better, it’ll raise a bunch a questions, and they don’t have to be threatening.

---

That’s it for today, and probably for this week. In the U.S. it’s a holiday weekend, so I’ll be back on Tuesday.

How are you?

Best,

Dan