Bullshit software

Event Storming tegen Bullshit software

Bij het lezen over Domain Driven Design (DDD), kom je op een gegeven moment de naam Alberto Brandolini tegen. Hij is bekend als ‘uitvinder’ van Event Storming. Event storming kun je zien als een soort taal met ‘sticky notes’ waarmee je complexe systemen gezamelijk kunt modelleren. Wil je daar meer over weten dan kan ik je zijn boek aanraden. (het boek is alleen nog niet af)

Maar als je zoekt op zijn naam zul je zien dat hij ook bekend is om: “The bullshit asymmetry”. In een tweet die hij stuurde op 11 januari 2013 omschrijft hij de bullshit asymmetrie in het Engels als: “The amount of energy needed to refute bullshit is an order of magnitude bigger than to produce it.”

tweet bullshit asymmetry

In het Nederlands: “De hoeveelheid energie die nodig is om bullshit te weerleggen is een orde van grootte groter dan om het te produceren.”

Dit wordt op het internet de Wet van Brandolini genoemd.

Het belangrijke aan deze ‘wetmatigheid’ is mijns inziens dat bullshitten niet per se gebeurt met kwade bedoelingen. Het is geen liegen en soms zal het zelfs gaan om goed bedoeld advies van iemand die de klok heeft horen luiden en indruk probeert te maken. Of het kan gaan om iemand die onder prestatiedruk maar wat zegt.

In de publicatie Bullshitters. Who Are They and What Do We Know about Their Lives?, van het: I Z A Istitute of Labor Economics, door: John Jerrim, Phil Parker en Nikki Shure, uit april 2019, wordt een interessant onderzoek beschreven over wie de bullshitters zijn. Hun definitie van bullshitters:

“Bullshitters are individuals who claim knowledge or expertise in an area where they actually have little experience or skill”.

In het Nederlands: “Bullshitters zijn personen die kennis of deskundigheid claimen op een gebied waar zij in feite weinig ervaring of vaardigheid hebben.”

Uit hun onderzoek blijkt onder andere dat jonge welgestelde mannen grotere bulshitters zijn dan jonge vrouwen.

Maar wat heeft dat te maken met software ontwikkeling?

Het ligt in de aard van het beroep software ontwikkelaar dat er regelmatig iets in een onbekend complex domein moet worden gemaakt. Met complex bedoel ik hier:

“Een probleem dat niet door één persoon kan worden overzien”.

Daarom is volgens mij bij software de Bullshit Asymmetrie belangrijk. Want als één ontwikkelaar een complex probleem alleen uitwerkt zou je volgens mij van Bullshit software kunnen spreken. Die ene ontwikkelaar kan waarschijnlijk niet het gehele domein snappen en zal dus met de beste bedoelingen voor een deel zelf bedenken hoe het domein werkt.

De onderstaande quote die ik een keer hoorde vind ik veelzeggend in dit opzicht:

“Het is niet de kennis van de experts die in productie gaat, het is de interpretatie van de ontwikkelaars die in productie gaat.”

Het is dus van belang wat en hoeveel iemand programmeert. En meer is daarbij dus niet altijd beter. Wanneer er gebruik wordt gemaakt van git dan is het mogelijk om via de log files van git te achterhalen wie welke code heeft geschreven en hoeveel code (LOC) iemand heeft bijgedragen in verhouding tot anderen. Stel dat één ontwikkelaar de helft van de code van een complex domein heeft geschreven? Volgens mij zegt dat dan iets over de kwaliteit van de software. De software zal wellicht werken, maar:

  • Hoeveel van de code kunnen andere begrijpen (Cognitive load)?
  • Hoe groot is het gat tussen het taalgebruik in de code en het taalgebruik van de stakeholder/experts (Ubiquitous language)?
  • Hoe makkelijk is de code aanpasbaar aan het domein (ongepaste generalisatie)?
  • Hoeveel verbanden zullen in de code net anders georganiseerd zijn dan de organisatie van het bedrijf (Conway’s law)?

Dit alles maakt de code minder ‘houdbaar’ en meer bevattelijk voor technical debt.

Niet goed dus.

Brandolini maakt zelf de cirkel rond

Het mooie aan wat Alberto Brandolini zegt over Bullshit Asymmetry en Event Storming vind ik dat met mijn constatering van het bestaan van Bullshit software een cirkel wordt rondgemaakt. Want voor het ontwikkelen van houdbare software in een complex domein zal je moeten samenwerken. Door kennis te delen en samen modellen te maken zal de bullshit verminderen. En Event Storming van Alberto Brandolini is een mooie tool om snel kennis te delen en samen modellen te maken. Na een Event Storming workshop kan je het systeem volgens de principes van Domain Driven Design vormgeven. Door samen te werken wordt de taal die de ontwikkelaars en de experts spreken eenduidig. En de verschillende bounded contexts kunnen worden geïdentificeerd, waardoor het mogelijk wordt om delen van de software onafhankelijk van elkaar te ontwikkelen en live te zetten. Er wordt kennis gedeeld, de ontwikkelaars krijgen een spoedcursus over het domein en leren bij welke experts ze informatie kunnen inwinnen. Meer mensen krijgen een beter begrip van het achterliggende bedrijfsprobleem dat wordt geautomatiseerd en kunnen daarom betere voorstellen doen.

Het resultaat: houdbare software, betrokken ontwikkelaars en betrokken experts/stakeholders en dus wendbaarheid.

 Share!

 
comments powered by Disqus