Drie keer infrastructuur, twee keer een echte bug

Op één dag ging er vier keer iets mis met mijn trading systeem. Een gefaalde ochtendrun, twee gefaalde builds, en een bug die zich pas liet zien toen er een verkoop doorging. Vier rode vlaggen.

Maar twee van die vier waren geen bug. Het waren infrastructuur-haperingen, ruis die niets met de code te maken had. En het herkennen van dat verschil, zonder erin te trappen, bleek de belangrijkste vaardigheid van de dag.

Wat de ruis was

De eerste hapering: de verbinding tussen mijn server en de plek waar mijn code staat viel weg tijdens een build. De foutmelding zag er dramatisch uit, een hele stapel rode regels. Maar de kern stond bovenaan: de code kon niet eens opgehaald worden. De build kwam niet eens toe aan het bouwen.

De tweede hapering: tijdens een andere build viel een download halverwege weg. Een verbroken verbinding naar de plek waar softwarepakketten vandaan komen. Weer een stapel rode regels, weer iets wat eng oogt, en weer niets met mijn code te maken.

Allebei opgelost met hetzelfde: opnieuw proberen. Geen codewijziging, geen diagnose, gewoon nog een keer. De tweede poging slaagde in beide gevallen, omdat de hapering voorbij was.

Hoe je het verschil ziet

Het verraderlijke aan een rode build is dat hij er altijd alarmerend uitziet, of het nu een echte fout is of een netwerkhapering. De truc zit in waar de fout valt, niet in hoe luid hij schreeuwt.

Een paar signalen die helpen. Faalt het bij het ophalen van de code, of bij het bouwen ervan? Een fout vóór het bouwen is bijna nooit jouw code. Bevat de foutmelding woorden als "verbinding verbroken" of "geen toegang"? Dat wijst op infrastructuur, niet op een logische fout. En de sterkste check: zou dezelfde code elders wel werken? Toen elf van mijn twaalf services prima bouwden met exact dezelfde code, was de ene die faalde overduidelijk geen codeprobleem. Een echte fout in de code had alle twaalf geraakt.

Dat laatste is het scherpste filter. Als hetzelfde ergens anders wel werkt, ligt het niet aan wat je net hebt veranderd.

Waarom dit ertoe doet

De verleiding bij een rode vlag is om meteen te gaan graven in je eigen werk. Wat heb ik kapotgemaakt? Maar als het ruis is, ben je een uur kwijt aan het zoeken naar een fout die er niet is. En erger, soms ga je dan iets "repareren" wat helemaal niet stuk was, en maak je het pas echt kapot.

De andere kant is net zo gevaarlijk. Als je elke rode vlag wegwuift als ruis, mis je de echte bug. Twee van de vier dingen die dag waren wél echt, en die verdienden volle aandacht. De kunst is niet om altijd kalm te blijven of altijd te graven, maar om per geval de juiste vraag te stellen: is dit van mij, of is dit de wereld eromheen?

Wat dit me leerde

Een systeem dat met geld moet gaan draaien, draait niet in een vacuüm. Het hangt aan servers, verbindingen, externe diensten, en die haperen soms gewoon. Een deel van betrouwbaar bouwen is leren welke storingen je serieus moet nemen en welke je gewoon opnieuw moet proberen.

Het signaal dat me hierbij het meest hielp was niet technisch. Het was de gewoonte om bij elke fout eerst te vragen waar hij vandaan komt, voordat ik aanneem dat ik iets fout deed. Die ene vraag scheelt uren, en behoedt je voor het repareren van dingen die niet stuk zijn.

Niet elke rode vlag is jouw schuld. Maar je moet wel elke keer even kijken om dat te weten.