Het artikel legt eerst de Jevons-paradox uit: het fenomeen waarbij lagere kosten voor een hulpbron leiden tot een hoger totaalverbruik omdat nieuwe toepassingen rendabel worden. De auteur introduceert vervolgens de 'Omgekeerde Jevons-paradox', waarbij stijgende kosten juist zorgen voor een daling in het gebruik. Als concreet voorbeeld wordt softwarebeheer genoemd, waarbij overmatige bureaucratie en complexe reviewprocessen kleine codeverbeteringen (refactors) zo kostbaar maken dat ontwikkelaars hiermee stoppen, wat uiteindelijk schadelijk is voor de kwaliteit van de codebase.
De Omgekeerde Jevons-paradox
Het klinkt tegenstrijdig; men zou verwachten dat de totale uitgaven zouden dalen nu de prijs is gedaald. Echter, de lagere kosten maken meer gebruik mogelijk binnen hetzelfde budget en openen de deur voor nieuwe toepassingen: zaken die voorheen netto-negatief waren vanwege de kosten van de hulpbron, zijn plotseling netto-positief [^1].
Voorbeeld: Auto's en benzineprijzen
Een typisch voorbeeld is de relatie tussen oude auto's en de benzineprijs.
Wanneer benzine duur is, zul je vaker het openbaar vervoer naar je werk nemen, naar vrienden en familie fietsen, en elke dag naar de supermarkt lopen zodat de tassen niet te zwaar worden. Wanneer de benzineprijzen echter dalen, wordt het plotseling zinvol om met de auto te gaan om tijd te besparen. Je kunt in bulk inkopen, verder weg wonende vrienden en familie bezoeken, en zelfs een nieuwe baan aannemen met een langere reistijd, omdat dit nu economisch haalbaar is.
Jevons-paradox in programmeren
De Jevons-paradox wordt vaak aangehaald binnen de wereld van programmeren, waarbij de kosten zowel monetair als in tijd kunnen worden uitgedrukt.
Neem bijvoorbeeld een build- en testsuite:
- Bij een trage suite: Je voert deze mogelijk slechts één keer per dag uit (de nightly build).
- Bij een snelle suite: Er is geen reden meer om dit te beperken tot één keer per dag. Je kunt bij elke commit een volledige build en testsuite uitvoeren. Sterker nog, je kunt dit lokaal doen voordat je commit, wat leidt tot nog intensiever gebruik.
Dit is niet simpelweg het versnellen van een bestaand proces; het is een fundamenteel andere manier van werken dan het maken van nightly builds. Het gevolg is dat de kosten voor je CI-omgeving (Continuous Integration) uiteraard stijgen.
De Omgekeerde Jevons-paradox
Hoewel bovenstaand effect bekend is, heb ik gemerkt dat dit proces ook in omgekeerde richting werkt: wanneer de kosten van een hulpbron stijgen, kunnen de totale uitgaven aan die hulpbron dalen. In sommige gevallen kan dit zelfs tot nul dalen.
Ik weet niet of dit verschijnsel een officiële naam heeft, dus ik noem het de Omgekeerde Jevons-paradox, ook al klinkt het minder paradoxaal dan het origineel.
Toepassing op softwarebeheer
Stel dat je verantwoordelijk bent voor een groot softwareproject. Als je het wijzigen van code bemoeilijkt door:
- meerdere niveaus van reviews te vereisen;
- een complex web van Jira-tickets te creëren;
- een grote groep mensen te eisen die hun goedkeuring moeten geven;
- en andere vormen van bureaucratie in te voeren;
...dan kun je effectief een hele categorie wijzigingen uitroeien, zoals kleine refactor-PR's (Pull Requests). De kosten voor het maken van kleine wijzigingen in de codebase worden zo hoog, dat het voor een individuele ontwikkelaar netto-negatief wordt om de wijziging door te voeren. Het is simpelweg de moeite niet meer waard, waardoor deze verbeteringen volledig stoppen.
Dit is rampzalig voor de gezondheid van een codebase. Ook hier gaat het om een fundamenteel verschil in plaats van een marginale verandering in tempo: de codebase ontvangt niet langer dezelfde stroom aan incrementele verbeteringen in een lager tempo, maar de verbeteringen stoppen volledig.
***
[^1]: Als je \$1,00 betaalt om op een knop te drukken en het indrukken van de knop levert je \$0,99 op, dan druk je nul keer op de knop. Als je in plaats daarvan \$1,01 krijgt, druk je constant op de knop.
De Omgekeerde Jevons-paradox
Het klinkt tegenstrijdig; men zou verwachten dat de totale uitgaven zouden dalen nu de prijs is gedaald. Echter, de lagere kosten maken meer gebruik mogelijk binnen hetzelfde budget en openen de deur voor nieuwe toepassingen: zaken die voorheen netto-negatief waren vanwege de kosten van de hulpbron, zijn plotseling netto-positief [^1].
Voorbeeld: Auto's en benzineprijzen
Een typisch voorbeeld is de relatie tussen oude auto's en de benzineprijs.
Wanneer benzine duur is, zul je vaker het openbaar vervoer naar je werk nemen, naar vrienden en familie fietsen, en elke dag naar de supermarkt lopen zodat de tassen niet te zwaar worden. Wanneer de benzineprijzen echter dalen, wordt het plotseling zinvol om met de auto te gaan om tijd te besparen. Je kunt in bulk inkopen, verder weg wonende vrienden en familie bezoeken, en zelfs een nieuwe baan aannemen met een langere reistijd, omdat dit nu economisch haalbaar is.
Jevons-paradox in programmeren
De Jevons-paradox wordt vaak aangehaald binnen de wereld van programmeren, waarbij de kosten zowel monetair als in tijd kunnen worden uitgedrukt.
Neem bijvoorbeeld een build- en testsuite:
- Bij een trage suite: Je voert deze mogelijk slechts één keer per dag uit (de nightly build).
- Bij een snelle suite: Er is geen reden meer om dit te beperken tot één keer per dag. Je kunt bij elke commit een volledige build en testsuite uitvoeren. Sterker nog, je kunt dit lokaal doen voordat je commit, wat leidt tot nog intensiever gebruik.
Dit is niet simpelweg het versnellen van een bestaand proces; het is een fundamenteel andere manier van werken dan het maken van nightly builds. Het gevolg is dat de kosten voor je CI-omgeving (Continuous Integration) uiteraard stijgen.
De Omgekeerde Jevons-paradox
Hoewel bovenstaand effect bekend is, heb ik gemerkt dat dit proces ook in omgekeerde richting werkt: wanneer de kosten van een hulpbron stijgen, kunnen de totale uitgaven aan die hulpbron dalen. In sommige gevallen kan dit zelfs tot nul dalen.
Ik weet niet of dit verschijnsel een officiële naam heeft, dus ik noem het de Omgekeerde Jevons-paradox, ook al klinkt het minder paradoxaal dan het origineel.
Toepassing op softwarebeheer
Stel dat je verantwoordelijk bent voor een groot softwareproject. Als je het wijzigen van code bemoeilijkt door:
- meerdere niveaus van reviews te vereisen;
- een complex web van Jira-tickets te creëren;
- een grote groep mensen te eisen die hun goedkeuring moeten geven;
- en andere vormen van bureaucratie in te voeren;
...dan kun je effectief een hele categorie wijzigingen uitroeien, zoals kleine refactor-PR's (Pull Requests). De kosten voor het maken van kleine wijzigingen in de codebase worden zo hoog, dat het voor een individuele ontwikkelaar netto-negatief wordt om de wijziging door te voeren. Het is simpelweg de moeite niet meer waard, waardoor deze verbeteringen volledig stoppen.
Dit is rampzalig voor de gezondheid van een codebase. Ook hier gaat het om een fundamenteel verschil in plaats van een marginale verandering in tempo: de codebase ontvangt niet langer dezelfde stroom aan incrementele verbeteringen in een lager tempo, maar de verbeteringen stoppen volledig.
***
[^1]: Als je \$1,00 betaalt om op een knop te drukken en het indrukken van de knop levert je \$0,99 op, dan druk je nul keer op de knop. Als je in plaats daarvan \$1,01 krijgt, druk je constant op de knop.
Groetjes,