CODE IN TOKYO

Today, Let Me Praise Microsoft

Yesterday I tried to set up a Docker environment on a somewhat old Mac, and for the first time in a while, I got spectacularly stuck.

“Docker absorbs environmental differences.” “Containerize it and it runs the same way everywhere.”

…Sure, in theory that’s true.

But that “everywhere” came with some fairly strong conditions attached.

In the end, after trying this and that, I quietly gave up.

“The hardware’s too old. It’s not happening.”

Docker’s “Ideal” and Reality’s “Wall”

The philosophy behind Docker really is wonderful.

We’ve been largely freed from the old hell of: “It works on my machine.” “Aren’t the library versions different?” “Do you have that DLL installed?”

I’ve personally been saved by Docker countless times, in AWS and in local development.

But that ideal only holds on one premise: that everyone has a relatively new machine.

The latest Mac. Enough memory. A new CPU. A fast SSD.

In environments like that, Docker really does work like magic.

But the moment you step over to the legacy side, the air changes.

“Ah, this Mac can’t run that version.” “That’s for Intel.” “That’s Apple Silicon only.” “That version of Docker Desktop is already out of support.”

Before you know it, the very technology meant to erase environmental dependencies has created a new environmental dependency.

What an ironic story.

A Sudden Thought: “Isn’t Microsoft Actually Amazing?”

It’s at moments like this that I remember Windows.

In engineering circles, Windows gets picked on quite a bit.

“It hangs on to too much old stuff.” “It’s full of legacy.” “It’s ugly because of all the compatibility it maintains.”

Well, I get what people are saying.

But watching actual business environments, that “stubborn insistence on compatibility” starts to look like something of enormous value.

Old Visual Basic. Ancient Access. Mysterious ActiveX. Business apps from 20 years ago.

Things that would normally have died long ago, Windows keeps running.

Of course it’s not perfect. There’s pain involved.

But “completely cutting things off” — they don’t really do that.

This is less technical debt than a kind of sense of responsibility.

The “It’s Your Fault for Not Modernizing” Atmosphere

In recent modern-development circles, I sometimes sense a slightly peculiar atmosphere.

“You’re still using that environment?” “Why not just update?” “Containerize it and it’s solved.”

These are fair points, sure.

But real companies quite normally have things like:

And those kinds of environments are overwhelmingly the majority.

Introducing something new is not easy.

Especially with business systems, the risk of changing something that works weighs more heavily than technical beauty.

Ignoring this and saying “Let’s migrate everything to the latest Docker environment!” sometimes becomes nearly synonymous with:

“Let’s throw away everything we’ve built up so far.”

Technical Correctness and Business Correctness Are Different

Chasing modern tech is fun.

Playing with new tools is interesting too. I like it.

But in the business world, the ability to maintain old things without breaking them becomes incredibly important.

In that sense, Microsoft has been fighting a long, gritty battle.

If they only chased the latest tech, there would have been plenty of smarter ways to go.

But they keep protecting the things their old customers are running, with an almost uncanny tenacity.

From a developer’s perspective this tends to be disliked, but from a management perspective it’s quite powerful.

The trust earned by not throwing away old assets is tremendously valuable in enterprise systems.

Closing

Aiming for “environment standardization” with Docker is wonderful.

But who is that “standard” premised on?

Who does it cut off?

Unless you think that far, maybe it never becomes true “commonization.”

That’s what I was vaguely thinking in front of my old Mac, staring at Docker’s error screen.

…Well, in the end I just gave up, though.