Verifiëren boven aannemen

Een wijziging aan de database gaf de melding "Succes. Geen rijen teruggegeven." Klinkt goed. Het probleem: er was helemaal niets gewijzigd. De melding was waar en misleidend tegelijk.

Toen even later een script die wijziging probeerde te gebruiken, faalde het meteen. De functie die er volgens de melding had moeten staan, bestond niet. De geruststelling was vals geweest, en alleen omdat de volgende stap er meteen overheen struikelde, kwam het aan het licht.

De melding die niets zegt

"Succes. Geen rijen teruggegeven" betekent bij dit soort wijzigingen alleen dat er geen foutmelding was. Het zegt niets over of het beoogde effect ook echt is opgetreden. Een lege opdracht geeft dezelfde melding als een geslaagde. Geen fout is niet hetzelfde als gelukt.

Dat is een subtiel maar belangrijk onderscheid. We zijn geneigd om "geen foutmelding" te lezen als "het is goed gegaan". Maar afwezigheid van een fout is geen bewijs van succes. Het is alleen de afwezigheid van een specifiek soort mislukking.

De les was simpel en kostte bijna niets: na zo'n wijziging niet vertrouwen op de melding, maar apart navragen of het beoogde resultaat er echt is. Eén extra controle, een paar seconden, en je weet het zeker in plaats van dat je het hoopt. Sinds die ochtend is dat een vaste stap geworden: wijzig, en controleer dan los of de wijziging er echt staat voordat je er iets op bouwt.

Aannames die geld kosten

Dit raakt aan een breder principe, en het werd diezelfde dag op een tweede manier duidelijk. Het systeem heeft een aparte stap die elke ochtend de uitstapregels controleert, de momenten waarop posities verkocht moeten worden om verlies te beperken of winst veilig te stellen. Die stap draait los van de rest.

De aanname was: als die stap is ingesteld, draait hij ook. Maar wat als hij stilletjes niet draait? Geen foutmelding, geen alarm, gewoon een ochtend waarop de controle overgeslagen wordt. Een gemiste verkoopcontrole is in dit systeem de duurste fout die er is, want dan blijft een positie open die had moeten sluiten.

Hetzelfde principe als bij de database-melding: niet aannemen dat iets draait, maar zorgen dat je het weet als het niet gebeurt.

Een bewaker die buiten het systeem staat

De oplossing is een mechanisme dat omgekeerd werkt dan je zou denken. In plaats van dat het systeem een alarm afgeeft als er iets misgaat, verwacht een externe dienst juist elke ochtend een teken van leven. Een kort signaal dat zegt: ik heb gedraaid, alles is goed. Blijft dat signaal uit, dan slaat de externe dienst alarm.

Het mooie zit in dat omgekeerde. Een alarm dat in je systeem zelf zit, faalt mee als je systeem faalt. Als de hele machine plat ligt, ligt het alarm ook plat. Maar een bewaker die buiten je systeem staat en een teken van leven verwacht, merkt juist de stilte op. Geen signaal is het alarm.

Het vangt daardoor alles tegelijk. Of de verbinding met de broker wegvalt, of een stap faalt, of de hele boel niet draait, in al die gevallen blijft het ochtendsignaal uit en gaat de bel. Je hoeft niet vooraf te bedenken op welke manier het kan misgaan. Je hoeft alleen te weten dat er 's ochtends een teken van leven hoort te komen.

Wat dit me leerde

Beide verhalen, de valse melding en de stille controle, komen op hetzelfde neer. Een systeem dat met geld gaat draaien mag niet leunen op aannames over wat er gebeurt. Het moet bewijzen dat het werkt, of het moet je waarschuwen als het dat niet doet.

"Geen foutmelding" is geen bewijs. "Het staat ingesteld" is geen bewijs. Het enige bewijs is dat je het apart hebt gecontroleerd, of dat er een onafhankelijke bewaker is die merkt wanneer het stilvalt.

Vertrouw niet op de stilte. Zorg dat de stilte zelf het alarm is.