Misschien heb je het wel eens gehad, je hebt een probleem, komt er niet uit, gaat naar iemand die hoger in de "line-of-command" staat, maar nadat je hebt uitgelegd wat het probleem is, krijg je de wedervraag: "wat denk je zelf dat het is?". Het standaard antwoord van iemand die geen flauw idee heeft wat de oplossing is en misschien ook niet eens het probleem snapt.
Omdat ik als back-ender de directe lijn voor mijn service-collega's ben en ik vaak "vage" problemen en vragen krijg ga ik natuurlijk niet deze vraag aan mijn collega's stellen. Mijn vragen zullen zijn: "hoe zijn ze op dit punt gekomen" en "wat heb je zelf al uitgezocht en uitgesloten"? Want als een klant zegt dat een formulier niet werkt, dan mag ik toch aannemen dat je zelf het formulier ook een keer ingevuld en verstuurd hebt. Werkt het dan wel? Wat heb jij dan anders gedaan dan de klant? Essentiële informatie dus. Als ik naar de garage ga en ik zeg "mijn auto is kapot", maar de monteur kan hem vervolgens wel starten, ook in de eerste versnelling zetten en de handrem eraf halen, maar dan (pas) gebeurt er niets op het moment van wegrijden, dan is mijn omschrijving van het probleem onjuist, de auto is niet kapot, maar hij wil niet wegrijden. Helaas worden veel problemen/fouten met zo'n beperkte hoeveelheid informatie aangeleverd, dus is de eerste stap: krijg van de melder de juiste (en uitgebreide) informatie wat er gebeurd is en wat er niet goed gegaan is.
Als je de benodigde informatie hebt en het probleem kunt reproduceren, dan is nog vaak onduidelijk wat de oorzaak is. En dan begint het puzzelen. Omdat puzzelen een hobby van mij is, is dit ook 1 van de redenen dat ik developer ben. Vaak kun je niet een directe oorzaak aanwijzen. Dan begin je maar op een andere manier: alle mogelijkheden langslopen en afstrepen, dit kan niet, dat niet, dit niet, dan zijn deze 3 mogelijkheden nog over. Of je hebt dan nog geen idee waar het door komt en dat zal dan ook je antwoord zijn: de oorzaak is niet te vinden. Maar (natuurlijk) ga je wel extra logging e.d. toevoegen om te zorgen dat als deze situatie nog een keer optreedt je meer informatie beschikbaar hebt en hopelijk wel de oorzaak aan kunt wijzen.
Laten we hier het voorbeeld van boompje-tentje nemen (voorbeeld PDF van Denksport). In dit schema moet elke boom een tentje hebben. Waar in dit raster begin je met het plaatsen van je tentje? Er zijn een aantal regels waar je je aan moet houden, zo mogen tenten elkaar niet raken (horizontaal, verticaal, diagonaal) en staat bij de rijen en kolommen hoeveel tenten er maximaal in staan. De eerste keer dat ik dit overzicht zag kon ik niet echt en plek vinden, er waren meerdere mogelijkheden, ik plaatste een tentje, ging de rest invullen en bleef al snel hangen: ik had verkeerd "gegokt". Maar dit is een logisch spel, je moet niet gokken. En hier geldt dus: je moet eerst mogelijkheden uitsluiten in plaats van meteen tentjes plaatsen. Je ziet een aantal rijen en kolommen waarin 0 tenten staan. Dus in die rij en die kolom vul je met kruisjes: daar kan en mag niets staan. En op die manier kon ik dus wel alles netjes invullen.
Hetzelfde geldt voor sudoku's (wikipedia-link). In elke hokje (3 bij 3 vakjes) komen de cijfers 1 tot en met 9. In elke rij en in elke kolom komen ook de cijfers 1 tot en met 9. Doordat een rij vol is, moet de 9 wel in de 2e of 3e rij komen. En als je dan naar de andere kolommen kijkt zie je misschien dat deze alleen in de 2e kolom kan staan en dat zorgt dan weer dat de 3e rij niet kan: dus dan moet de 9 in de 2e rij. Je hebt ook andere sudoku's. Daarbij geldt dat ook de diagonalen de cijfers 1 tot en met 9 moeten bevatten.
En ook in het geval dat je denkt: "dit moet de oorzaak zijn", voordat je vol vuur die uitspraak doet, ga toch kijken of er andere mogelijke oorzaken zijn. Want soms zijn we zo gefocust op "dat is de oorzaak!", dat we de rest uit het oog verliezen. En mogelijk heb je wel een oorzaak gevonden, maar is er op een hoger niveau nog iets anders wat speelt. Stel dat je in je code iets met een BTW-percentage doet, je deelt een getal door dat percentage en in sommige gevallen is dat 0 (division by zero). Je kunt hier de code aanpassen en zeggen: als het percentage 0 is, deel ik door 1. De fout die je had heb je dan opgelost. Maar misschien mag in jouw applicatie geen BTW-percentage van 0% voorkomen. Dus dat het hier nu "kapot" ging, dat was op zich wel correct. Je had eerder moeten afvangen dat de invoer onjuist is.
Waar deze aanpak mogelijk je ook verder kan helpen? Bij concurrency-problemen (doordat meerdere processen door elkaar lopen krijg je deadlocks e.d.) en bij memory-leaks of andere oorzaken waardoor het CPU en/of geheugengebruik van je applicatie in het rood schiet. Dat zijn de zaken waarbij je zelf ook in de stress schiet want je weet: dit wordt moeilijk. Aan de andere kant, iedereen heeft wel eens een uitdaging nodig :) Dan eerst maar eens een lijstje met mogelijke oorzaken maken en kijken of we zaken kunnen wegstrepen.