Deductief, inductief en abductief denken tijdens programmeren

In de softwarewereld wordt veel gepraat over tools, frameworks en methodologieën. Maar zelden gaat het over hoe ontwikkelaars eigenlijk denken. En dat is vreemd, want de manier waarop je redeneert bepaalt de kwaliteit van alles wat je bouwt.

Drie manieren van denken

Laat ik beginnen bij de basis. Er zijn drie fundamentele vormen van redeneren:

• Deductief denken: je vertrekt vanuit een algemene regel en past die toe op een specifiek geval. Als de regel klopt en de toepassing correct is, dan is de conclusie gegarandeerd waar. Het is logisch, strikt en bewijsbaar.
• Inductief denken: je observeert een aantal gevallen en trekt daaruit een algemene conclusie. "Het werkte de vorige drie keer, dus het zal wel altijd werken." De conclusie is waarschijnlijk, maar niet gegarandeerd.
• Abductief denken: je ziet een resultaat en bedenkt de meest waarschijnlijke verklaring. "De tests falen, dus het zal wel aan die laatste commit liggen." Het is een gok, soms een goede, maar het blijft een gok.

Hoe de meeste ontwikkelaars werken

Hier zit het probleem. Het merendeel van de ontwikkelaars leunt zwaar op inductief en abductief denken. En dat is begrijpelijk. Deadlines duwen je richting snelle aannames. Stack Overflow-antwoorden trainen je om patronen te herkennen en over te nemen zonder de onderliggende logica te doorgronden. "Het werkt bij anderen, dus het werkt bij mij."

Inductief denken leidt tot code die werkt totdat het niet meer werkt. Je hebt vijf gevallen getest en het ging goed. Maar het zesde geval breekt alles, omdat je nooit de onderliggende regel hebt begrepen. Je hebt een patroon gevolgd in plaats van een principe.

Abductief denken leidt tot debugging op gevoel. Je verandert iets, kijkt of het probleem weg is, en als dat zo is, ga je verder. Maar je hebt niet bewezen waarom het werkte. Je hebt het symptoom behandeld, niet de oorzaak. En twee weken later komt hetzelfde probleem terug in een andere vorm.

Waarom dit gevaarlijk is

Software is logica. Het is wiskunde vertaald naar instructies. En toch behandelen veel ontwikkelaars het alsof het een ambacht is waar ervaring en intuïtie genoeg zijn. Dat werkt tot op zekere hoogte. Maar zodra systemen complexer worden, vallen de gaten in inductieve en abductieve redeneringen genadeloos op.

Een paar voorbeelden:

• Architectuurbeslissingen op basis van eerdere projecten: "We gebruikten microservices bij het vorige project en dat ging goed, dus we doen het weer." Dat is inductief. Het houdt geen rekening met de specifieke vereisten van het huidige project.
• Bugfixes zonder root cause analysis: "Ik heb een null-check toegevoegd en de crash is weg." Dat is abductief. Je hebt niet onderzocht waarom die waarde null was. Ergens in het systeem zit een fout die je niet hebt opgelost.
• Framework-keuzes op basis van populariteit: "React wordt overal gebruikt, dus het is de juiste keuze." Dat is inductief. Populariteit zegt niets over geschiktheid voor jouw specifieke situatie.

Deductief denken als fundament

Deductief denken dwingt je om bij het begin te beginnen. Wat zijn de regels? Wat zijn de beperkingen? Wat volgt er logisch uit de vereisten? Als je deductief werkt, schrijf je geen code op basis van wat waarschijnlijk werkt. Je schrijft code op basis van wat moet werken, omdat de logica dat dicteert.

Dat betekent niet dat inductief en abductief denken geen waarde hebben. Ze zijn nuttig als startpunt, om hypotheses te vormen of patronen te herkennen. Maar ze zouden nooit het eindpunt mogen zijn. Elke aanname moet getoetst worden aan deductieve logica voordat die in productie gaat.

Waar McDD binnenkomt

En hier wordt het persoonlijk. Mijn brein werkt anders. Door McDD ervaar ik de wereld intenser, neem ik meer waar, en verwerk ik informatie op een manier die niet altijd het standaardpad volgt. Dat heeft nadelen, maar het heeft ook iets opgeleverd wat ik niet had verwacht: een natuurlijke neiging tot deductief denken.

Waar anderen snel een aanname doen en doorgaan, blijf ik hangen bij de vraag waarom. Niet uit twijfel, maar uit een diepe behoefte om te begrijpen hoe iets werkelijk in elkaar zit. Mijn brein accepteert geen "het werkt toch?" als antwoord. Het wil de regel kennen, de structuur zien, het bewijs hebben.

Dat kost tijd. Het maakt me soms langzamer in de beginfase. Maar het betekent ook dat wanneer ik iets bouw, het klopt. Niet omdat ik geluk had, maar omdat de logica het ondersteunt.

De blinde vlek van de industrie

Wat mij opvalt is dat de softwareindustrie inductief en abductief denken beloont. Snelheid wordt gewaardeerd boven grondigheid. "Ship fast, break things" is geen grap, het is een cultuur. Ontwikkelaars die snel iets werkend krijgen worden geprezen, ook als de fundamenten wankel zijn.

Ondertussen worden de mensen die eerst willen begrijpen voordat ze bouwen gezien als langzaam, perfectionistisch of moeilijk. Maar de technische schuld die inductief en abductief werken oplevert, betaalt iedereen uiteindelijk. De bugs, de herschrijvingen, de systemen die niemand meer durft aan te raken. Dat is het resultaat van te snel aannemen en te weinig bewijzen.

Waar het schuurt

En dan komen de conflicten. Want als je deductief denkt in een omgeving die inductief en abductief werkt, bots je. Niet af en toe, maar structureel.

Het begint vaak onschuldig. Iemand stelt een oplossing voor in een overleg. De rest knikt, want het klinkt logisch en het sluit aan bij wat eerder heeft gewerkt. Maar ik zie de gaten. Ik zie de aannames die niet zijn getoetst, de randgevallen die over het hoofd worden gezien, de fundamentele fout in de redenering die pas over drie maanden gaat opspelen. En als ik dat benoem, ontstaat er wrijving.

Niet omdat ik ongelijk heb. Maar omdat ik iets zichtbaar maak wat anderen liever niet zien. Wie inductief heeft geredeneerd naar een conclusie, ervaart een deductieve weerlegging niet als een inhoudelijk punt. Het voelt als een aanval. Alsof je zegt: je hebt niet goed nagedacht. En dat is precies wat er aan de hand is, maar niemand wil dat horen.

Het patroon herhaalt zich. Ik stel een vraag die te diep gaat. Ik wijs op een risico dat "theoretisch" wordt genoemd. Ik stel voor om iets eerst goed uit te zoeken voordat we beginnen met bouwen. En de reactie is bijna altijd dezelfde: "Je maakt het te ingewikkeld." Of: "We moeten pragmatisch zijn." Pragmatisch is in de praktijk vaak een ander woord voor: laten we het niet te nauw nemen met de logica.

Het frustrerende is dat de tijd mij vaak gelijk geeft. De bug die ik voorspelde, komt. De architectuur die ik in twijfel trok, moet worden herschreven. De aanname die niemand wilde onderzoeken, blijkt de oorzaak van weken aan vertraging. Maar tegen die tijd is iedereen alweer bezig met het volgende probleem, en wordt er niet teruggekeken naar hoe het had kunnen worden voorkomen.

Wat het extra lastig maakt is dat mijn perspectief soms als arrogant wordt ervaren. Alsof ik denk dat ik het beter weet. Maar het gaat niet om beter weten. Het gaat om anders kijken. Mijn brein laat me niet toe om een aanname te accepteren zonder bewijs. Dat is geen keuze, dat is hoe ik functioneer. En wanneer die aanname vervolgens leidt tot problemen, voel ik me niet triomfantelijk. Ik voel me moe. Want ik had het gezegd, en het maakte niet uit.

De kern van het conflict is dit: inductief en abductief denken voelt snel en productief. Deductief denken voelt langzaam en lastig. In een cultuur die snelheid beloont, verliest grondigheid het bijna altijd van momentum. En degene die grondigheid bepleit, wordt het obstakel.

Herkenning in code

Je kunt het verschil zien in code. Inductief geschreven code is vaak een verzameling van patronen die ergens vandaan zijn gekopieerd. Het werkt, maar er zit geen samenhang in. Abductief geschreven code is vol met workarounds en hotfixes. Pleisters op pleisters.

Deductief geschreven code vertelt een verhaal. Elke beslissing volgt logisch uit de vorige. De structuur is niet willekeurig, maar het resultaat van principes die consequent worden toegepast. Het is code die je kunt lezen en begrijpen, niet alleen uitvoeren.

Wat ik hiervan heb geleerd

Mijn McDD maakt dat ik de wereld soms te intens ervaar. Maar datzelfde brein dat me overweldigt, is ook het brein dat niet stopt met zoeken naar de waarheid achter de aanname. Het brein dat niet tevreden is met "waarschijnlijk" als "zeker" ook mogelijk is.

Dat maakt me geen betere ontwikkelaar dan anderen. Maar het geeft me een perspectief dat in de industrie vaak ontbreekt. De wil om te bewijzen in plaats van te gokken. Om te begrijpen in plaats van te proberen. Om de regel te kennen in plaats van het patroon te volgen.

En ik geloof oprecht dat de softwarewereld beter zou worden als meer mensen zich die vraag zouden stellen: weet ik dit, of neem ik het aan?

"Een aanname die werkt is nog geen bewijs. En code die draait is nog geen oplossing."

Tot slot

Dit is geen pleidooi tegen inductief of abductief denken. Het zijn waardevolle denkvormen die hun plek hebben. Maar het is wel een oproep om eerlijk te zijn over hoe vaak we erop leunen zonder het door te hebben. En om te erkennen dat grondigheid, ook al is het langzamer, uiteindelijk de sterkere basis legt.

Vanuit mijn McDD-perspectief is dat geen keuze. Het is hoe mijn brein werkt. Maar misschien kan het voor anderen een bewuste keuze worden.