Ik besteedde vroeger uren — soms dagen — aan het uitknijpen van elke laatste byte uit code. Een programma laten draaien op hardware die het “onmogelijk” aankon was oprecht spannend. De demoscene was mijn inspiratie: onmogelijke visuele effecten gerenderd in 64 kilobyte of minder. Hoe deden ze dat?

Die mentaliteit lijkt nu bijna ouderwets. Waarom optimaliseren als je gewoon meer hardware naar het probleem kunt gooien? Waarom om efficiëntie geven als compute goedkoop is?

Maar hier is het punt: compute is niet goedkoop. We hebben alleen de kosten geëxternaliseerd.

Toen Optimalisatie Overleven Was

In de demoscene waren beperkingen geen obstakels — ze waren creatieve brandstof. Een 64KB intro moest alles bevatten: graphics, muziek, animatie, vaak procedureel gegenereerd in real-time. Elke byte telde. Elke CPU-cyclus deed ertoe.

De legendarische demo’s van groepen zoals Future Crew, Farbrausch en Conspiracy waren niet alleen technische prestaties — het was kunst geboren uit beperking. .kkrieger, een complete first-person shooter in 96KB, demonstreerde dat je met genoeg creativiteit en optimalisatie ogenschijnlijk onmogelijke dingen kon doen.

Dit was geen masochisme. Het was vakmanschap. Je hardware intiem genoeg begrijpen om prestaties te produceren die niet zouden moeten bestaan.

Het Grote Vergeten

Toen veranderde er iets.

Cloud computing maakte oneindige schaal on-demand beschikbaar. Moore’s Law bleef leveren. Opslag werd praktisch gratis. En geleidelijk verdween de cultuur van optimalisatie.

Waarom drie dagen besteden aan het optimaliseren van een algoritme als je grotere instances kunt opstarten? Waarom assets comprimeren als bandbreedte goedkoop is? Waarom je code profilen als de klant gewoon meer RAM koopt?

Ik heb dit uit eerste hand gezien in enterprise-omgevingen:

  • Applicaties die 32GB RAM nodig hebben om een spreadsheet te tonen
  • Docker images gemeten in gigabytes voor simpele services
  • JavaScript bundles die langer duren om te parsen dan de daadwerkelijke gebruikersinteractie
  • “Microservices” die meer resources nodig hebben dan de monoliet die ze vervingen

We hebben collectief besloten dat ontwikkelaarstijd duur is en compute goedkoop. Dus optimaliseren we voor het eerste ten koste van het laatste.

Deze afweging was begrijpelijk toen het puur economisch was. Maar het is niet meer puur economisch.

De Verborgen Milieukosten

Hier is de ongemakkelijke waarheid: elke onnodige CPU-cyclus verbruikt elektriciteit. Elke opgeblazen Docker image vereist opslag en netwerktransfer. Elk over-provisioned Kubernetes cluster verbrandt 24/7 stroom.

Datacenters verbruiken momenteel ongeveer 1-2% van de mondiale elektriciteit. En dat percentage groeit. Snel. De explosie van AI-workloads versnelt dit dramatisch.

Als je inefficiënte code op duizenden instances draait, vermenigvuldigen die kleine inefficiënties zich. Het verschil tussen O(n) en O(n²) is niet alleen computerwetenschapstrivia — het zijn kilowatturen. Echte energie. Echte milieu-impact.

Dit is waar circulair economie-denken relevant wordt. We hebben compute behandeld als een wegwerpresource: gebruik wat je nodig hebt, schaal op, maak je geen zorgen over verspilling. Maar dat model is steeds minder houdbaar.

Wat Zouden Demosceners Doen?

De demoscene-mentaliteit biedt een ander perspectief:

1. Meet eerst, optimaliseer dan

Demosceners gokten niet wat langzaam was — ze profileerden obsessief. Moderne observability-tools geven ons vergelijkbare mogelijkheden. Hoe vaak gebruiken we ze eigenlijk voor optimalisatie in plaats van debugging?

2. Bevraag de default

Heeft deze service echt 2GB basisgeheugen nodig? Moet deze JSON-response echt elk veld bevatten? Moet deze achtergrondtaak echt elke minuut draaien?

3. Beperkingen als creativiteit

Wat als je Docker image een limiet van 50MB had? Wat als je service op 256MB RAM moest draaien? Deze beperkingen leiden vaak tot schonere, meer gefocuste oplossingen.

4. Trots op efficiëntie

In de demoscene was iets klein en snel maken prestigieus. In moderne software is het vaak onzichtbaar. Wat als we optimalisatie vierden zoals we features vieren?

Praktische Groene Software

Ik stel niet voor dat we allemaal demo’s gaan coderen. Maar sommige praktijken uit die wereld vertalen zich direct:

Profile voor je schaalt. Voordat je grotere instances opstart, begrijp waarom je ze nodig hebt. Vaak is een enkele inefficiënte database query of memory leak de boosdoener.

Right-size alles. Kubernetes resource requests en limits zijn geen bureaucratie — ze zijn milieubeleid. Een over-provisioned cluster verbrandt energie om CPUs warm en idle te houden.

Meet energieverbruik. Tools zoals Scaphandre, Kepler en Cloud Carbon Footprint kunnen je de daadwerkelijke energie-impact van je workloads tonen. Wat gemeten wordt, wordt gemanaged.

Batch en schedule slim. Jobs draaien tijdens daluren of wanneer hernieuwbare energie beschikbaar is vermindert de milieu-impact. Sommige cloud providers bieden nu carbon-aware scheduling.

Cache agressief. De groenste berekening is degene die je niet doet. Caching is niet alleen performance — het is duurzaamheid.

Kies efficiënte talen voor de juiste taken. Rust en Go verbruiken veel minder energie dan Python of Ruby voor equivalente workloads. Soms doet die afweging ertoe.

Het Grotere Plaatje

Software optimalisatie gaat niet meer alleen over geld besparen of gebruikerservaring verbeteren. Het gaat over erkennen dat compute een fysieke voetafdruk heeft.

Elke keer dat we opgeblazen software shippen, maken we een keuze. We kiezen gemak boven efficiëntie. We externaliseren kosten naar het milieu. We nemen aan dat iemand anders — de cloud provider, de eindgebruiker, de planeet — de verspilling absorbeert.

De demoscene leerde ons dat ongelooflijke dingen mogelijk zijn binnen beperkingen. Dat limieten creativiteit voeden. Dat efficiëntie zijn eigen beloning is.

Misschien is het tijd om die lessen te herinneren.

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