Here is how most of us ship software in 2026. You pick a framework, pull in a few hundred dependencies, and your service idles at a gigabyte of RAM before it does a single useful thing. Nobody profiles it. Nobody asks why. If it’s slow, you scale up. Compute is cheap, your time is expensive, and the bill goes to someone else. We’ve accepted this as normal.

I used to live in a different world. I’d spend hours, sometimes whole weekends, squeezing every last byte out of code. Getting a program to run on hardware that “couldn’t possibly” handle it was the best feeling I knew. My inspiration was the demoscene: impossible visual effects rendered in 64 kilobytes or less. I’d watch one and just sit there asking myself, how on earth did they do that?

That instinct feels almost quaint now. But I think we lost something real when we stopped caring, and the cost of losing it has started showing up on the electricity meter.

When Optimization Was Survival

In the demoscene, the constraints were the whole point. A 64KB intro had to carry everything: graphics, music, animation, often generated procedurally at runtime because there was no room to store assets. Every byte was a decision. Every CPU cycle had an owner.

Groups like Future Crew, Farbrausch and Conspiracy turned that limitation into art. .kkrieger is the example I still bring up: a complete first-person shooter, with textures and levels and enemies, in 96KB. A single modern web font is bigger than that.

None of this was masochism. It was craft. You had to understand your hardware so intimately that you could coax performance out of it that the spec sheet said shouldn’t exist. That kind of understanding is exactly what I value most in the work I still do today. When you know why something is fast, you also know why it breaks.

The Great Forgetting

Then the ground shifted under us.

Cloud made infinite scale a checkout button. Moore’s Law kept paying out. Storage went from precious to free. And the culture of optimization quietly drained away, because the economics stopped rewarding it.

Why spend three days tightening an algorithm when a bigger instance costs less than your afternoon? Why compress assets when bandwidth is metered in fractions of a cent? Why profile anything when the customer can just buy more RAM? Every one of those questions has a defensible answer, and I’ve answered them the lazy way plenty of times myself.

I’ve watched the result pile up in enterprise environments:

  • Applications that need 32GB of RAM to display a spreadsheet
  • Docker images measured in gigabytes for services that do almost nothing
  • JavaScript bundles that take longer to parse than the interaction they enable
  • “Microservices” that demand more resources than the monolith they replaced

We decided, collectively and without ever voting on it, that developer time is expensive and compute is cheap. So we optimize for the one and waste the other. That made sense when the only thing at stake was a cloud bill. It makes a lot less sense now.

The Cost We Pushed Off the Balance Sheet

Every unnecessary CPU cycle burns electricity. Every bloated image needs storage and a network to move it across. Every over-provisioned Kubernetes cluster draws power around the clock to keep idle cores warm.

Data centres already eat somewhere around 1 to 2 percent of global electricity, and that figure is climbing fast, with the current wave of AI workloads pouring fuel on it. When your inefficient code runs on one laptop, nobody notices. When it runs on ten thousand instances, the inefficiency multiplies by ten thousand. The gap between O(n) and O(n²) stops being a whiteboard curiosity at that scale. It turns into kilowatt-hours, into real generation capacity, into carbon.

This is the part I keep coming back to. We’ve treated compute as disposable: take what you need, scale on demand, never think about waste. Run that logic long enough and it stops adding up.

What Would a Demoscener Do?

The old mindset gives us a practical lens, and most of it survives the jump from 64KB intros to production systems.

Measure first. Demosceners never guessed what was slow, they profiled until they knew. We have far better observability tools than they ever did, and we mostly point them at debugging instead of efficiency. The data is already there.

Question the default. Does this service genuinely need 2GB of base memory, or did it ship with that number and nobody ever checked? Does this JSON response need every field? Does this cron job need to run every minute?

Treat constraints as a feature. Give yourself a 50MB image limit. Force a service to run in 256MB. Artificial limits like these tend to produce cleaner, more focused designs, the same way 64KB forced the scene to invent procedural generation.

Make efficiency something to be proud of. In the scene, small and fast earned respect. In most companies it’s invisible work that no one demos at the sprint review. We celebrate features. We could celebrate the engineer who cut the cluster footprint in half.

Practical Green Software

I’m not suggesting you write a demo. But several habits from that world map straight onto how we run infrastructure, and you can start with any of them this week.

Profile before you scale. Before you reach for a bigger instance, find out why the current one is struggling. More often than not it’s one bad database query or a slow memory leak, and the fix is cheaper than the upgrade.

Right-size everything. Kubernetes resource requests and limits aren’t paperwork, they’re environmental policy with a YAML interface. An over-provisioned cluster spends real energy keeping CPUs warm and idle.

Measure energy directly. Tools like Scaphandre, Kepler and Cloud Carbon Footprint show the actual energy draw of your workloads. What gets measured gets managed, and most teams have never measured this at all.

Schedule with carbon in mind. Running batch jobs during off-peak hours, or when the grid is greener, cuts the impact for free. Some providers now offer carbon-aware scheduling out of the box.

Cache aggressively. The greenest computation is the one you never run. Caching pays you back twice, in latency and in watts.

Pick the right language for the job. Rust and Go burn far less energy than Python or Ruby for the same work. That trade-off doesn’t always matter, but when it runs at scale, it does.

Why We Haven’t Already Done This

So why isn’t everyone doing this already? Because the incentives still point the wrong way. Optimization is real engineering effort with no flashy demo at the end, and most roadmaps reward the new feature over the leaner one. A cloud bill is a number a CFO understands. A carbon footprint, for now, mostly isn’t. And “it works” remains the most powerful argument ever invented against “it could be better.”

I get it. I’ve shipped the bloated thing on a deadline too. None of this is a moral failing, it’s a default we drifted into because each individual shortcut was rational.

Closing the Gap

You don’t have to fix all of it. Start with one service nobody will miss if it wobbles. Profile it, right-size it, put an energy meter on it, and watch the number move. Let the measurement make the argument for you, the way the scene let a 96KB shooter make theirs.

The demoscene proved that constraints breed creativity, and that doing more with less can be its own reward. That lesson was true when the limit was a hardware ceiling. It’s true again now that the limit is a planet. Worth remembering, I think, before the meter climbs any higher.

The demoscene is now UNESCO-recognized cultural heritage in several countries. The art of doing more with less deserves both preservation and revival.