Zo shippen de meesten van ons software in 2026. Je kiest een framework, trekt een paar honderd dependencies binnen, en je service staat al op een gigabyte RAM voordat hij iets nuttigs doet. Niemand profilet het. Niemand vraagt waarom. Als het traag is, schaal je op. Compute is goedkoop, jouw tijd is duur, en de rekening gaat naar iemand anders. Dat hebben we als normaal geaccepteerd.

Ik leefde ooit in een andere wereld. Ik besteedde uren, soms hele weekenden, aan het uitknijpen van elke laatste byte uit code. Een programma laten draaien op hardware die het “onmogelijk” aankon was het beste gevoel dat ik kende. Mijn inspiratie was de demoscene: onmogelijke visuele effecten gerenderd in 64 kilobyte of minder. Ik keek er een en zat dan gewoon te denken, hoe in hemelsnaam deden ze dat?

Dat instinct voelt nu bijna ouderwets. Maar ik denk dat we iets echts kwijtraakten toen we stopten met erom geven, en de prijs daarvan is gaan opduiken op de elektriciteitsmeter.

Toen optimalisatie overleven was

In de demoscene waren de beperkingen het hele punt. Een 64KB intro moest alles dragen: graphics, muziek, animatie, vaak procedureel gegenereerd op het moment zelf omdat er geen ruimte was om assets op te slaan. Elke byte was een beslissing. Elke CPU-cyclus had een eigenaar.

Groepen als Future Crew, Farbrausch en Conspiracy maakten van die beperking kunst. .kkrieger is het voorbeeld dat ik er nog steeds bij haal: een complete first-person shooter, met textures en levels en vijanden, in 96KB. Een enkele moderne webfont is groter dan dat.

Niets hiervan was masochisme. Het was vakmanschap. Je moest je hardware zo intiem begrijpen dat je er prestaties uit kon halen die volgens het spec sheet niet zouden mogen bestaan. Precies dat soort begrip waardeer ik het meest in het werk dat ik nu nog doe. Als je weet waarom iets snel is, weet je ook waarom het stukgaat.

Het grote vergeten

Toen schoof de grond onder ons weg.

Cloud maakte van oneindige schaal een afrekenknop. Moore’s Law bleef uitkeren. Opslag ging van kostbaar naar gratis. En de cultuur van optimalisatie liep stilletjes leeg, omdat de economie hem niet langer beloonde.

Waarom drie dagen besteden aan het aanscherpen van een algoritme als een grotere instance minder kost dan je middag? Waarom assets comprimeren als bandbreedte wordt afgerekend in fracties van een cent? Waarom iets profilen als de klant gewoon meer RAM koopt? Elk van die vragen heeft een verdedigbaar antwoord, en ik heb ze zelf vaak genoeg op de luie manier beantwoord.

Ik heb het resultaat zich zien opstapelen in enterprise-omgevingen:

  • Applicaties die 32GB RAM nodig hebben om een spreadsheet te tonen
  • Docker images gemeten in gigabytes voor services die bijna niets doen
  • JavaScript bundles die langer duren om te parsen dan de interactie die ze mogelijk maken
  • “Microservices” die meer resources vragen dan de monoliet die ze vervingen

We besloten, collectief en zonder er ooit over te stemmen, dat ontwikkelaarstijd duur is en compute goedkoop. Dus optimaliseren we voor het eerste en verspillen we het tweede. Dat klopte zolang het enige dat op het spel stond een cloud-rekening was. Het klopt een stuk minder nu.

De kosten die we van de balans schoven

Elke onnodige CPU-cyclus verbrandt elektriciteit. Elke opgeblazen image vereist opslag en een netwerk om hem over te zetten. Elk over-provisioned Kubernetes cluster trekt de klok rond stroom om idle cores warm te houden.

Datacenters slokken al ergens tussen de 1 en 2 procent van de mondiale elektriciteit op, en dat getal klimt snel, met de huidige golf aan AI-workloads die er olie op gooit. Als je inefficiënte code op één laptop draait, merkt niemand het. Als hij op tienduizend instances draait, vermenigvuldigt de inefficiëntie zich met tienduizend. Het verschil tussen O(n) en O(n²) is op die schaal geen whiteboard-curiositeit meer. Het wordt kilowatturen, echte opwekcapaciteit, koolstof.

Dit is het deel waar ik steeds op terugkom. We hebben compute behandeld als wegwerp: pak wat je nodig hebt, schaal on-demand, denk nooit aan verspilling. Volg die logica lang genoeg en het houdt geen stand.

Wat zou een demoscener doen?

De oude mentaliteit geeft ons een praktische bril, en het meeste ervan overleeft de sprong van 64KB intro’s naar productiesystemen.

Meet eerst. Demosceners gokten nooit wat traag was, ze profileerden tot ze het wisten. Wij hebben veel betere observability-tools dan zij ooit hadden, en we richten ze vooral op debugging in plaats van efficiëntie. De data ligt er al.

Bevraag de default. Heeft deze service echt 2GB basisgeheugen nodig, of kwam hij met dat getal en heeft niemand het ooit gecheckt? Heeft deze JSON-response elk veld nodig? Moet deze cronjob elke minuut draaien?

Behandel beperkingen als een feature. Geef jezelf een imagelimiet van 50MB. Dwing een service op 256MB te draaien. Zulke kunstmatige limieten leveren vaak schonere, meer gefocuste ontwerpen op, op dezelfde manier waarop 64KB de scene dwong procedurele generatie uit te vinden.

Maak van efficiëntie iets om trots op te zijn. In de scene leverde klein en snel respect op. In de meeste bedrijven is het onzichtbaar werk dat niemand demonstreert op de sprint review. We vieren features. We zouden de engineer kunnen vieren die de cluster-footprint halveerde.

Praktische groene software

Ik stel niet voor dat je een demo schrijft. Maar verschillende gewoontes uit die wereld vertalen zich direct naar hoe we infrastructuur draaien, en je kunt deze week met elk ervan beginnen.

Profile voordat je schaalt. Voordat je naar een grotere instance grijpt, zoek uit waarom de huidige het zwaar heeft. Vaker wel dan niet is het één slechte database query of een trage memory leak, en de fix is goedkoper dan de upgrade.

Right-size alles. Kubernetes resource requests en limits zijn geen papierwerk, ze zijn milieubeleid met een YAML-interface. Een over-provisioned cluster geeft echte energie uit om CPUs warm en idle te houden.

Meet energie direct. Tools als Scaphandre, Kepler en Cloud Carbon Footprint tonen het daadwerkelijke energieverbruik van je workloads. Wat gemeten wordt, wordt gemanaged, en de meeste teams hebben dit nog nooit gemeten.

Schedule met koolstof in gedachten. Batchjobs draaien tijdens daluren, of wanneer het net groener is, snijdt de impact gratis weg. Sommige providers bieden carbon-aware scheduling nu standaard.

Cache agressief. De groenste berekening is degene die je nooit draait. Caching betaalt zich dubbel terug, in latency en in watts.

Kies de juiste taal voor de taak. Rust en Go verbranden veel minder energie dan Python of Ruby voor hetzelfde werk. Die afweging doet er niet altijd toe, maar wanneer het op schaal draait, wel.

Waarom we dit nog niet hebben gedaan

Dus waarom doet niet iedereen dit al? Omdat de prikkels nog steeds de verkeerde kant op wijzen. Optimalisatie is echte engineering-inspanning zonder flitsende demo aan het eind, en de meeste roadmaps belonen de nieuwe feature boven de slankere. Een cloud-rekening is een getal dat een CFO begrijpt. Een koolstofvoetafdruk, voorlopig, meestal niet. En “het werkt” blijft het krachtigste argument dat ooit is uitgevonden tegen “het kan beter”.

Ik snap het. Ik heb het opgeblazen ding ook op een deadline geshipt. Niets hiervan is een morele fout, het is een default waar we in afdwaalden omdat elke individuele shortcut rationeel was.

Het gat dichten

Je hoeft het niet allemaal op te lossen. Begin met één service die niemand zal missen als hij wankelt. Profile hem, right-size hem, zet er een energiemeter op, en kijk hoe het getal beweegt. Laat de meting het argument voor je maken, zoals de scene een 96KB shooter het hunne liet maken.

De demoscene bewees dat beperkingen creativiteit voeden, en dat meer doen met minder zijn eigen beloning kan zijn. Die les was waar toen de limiet een hardwareplafond was. Hij is opnieuw waar nu de limiet een planeet is. Het waard om te onthouden, denk ik, voordat de meter nog hoger klimt.

De demoscene is nu UNESCO-erkend cultureel erfgoed in verschillende landen. De kunst van meer doen met minder verdient zowel behoud als heropleving.