Twee keer een model verloren, en wat ik sindsdien anders doe
Een datamodel dat twee keer volledig crashte, waarschijnlijk door gelijktijdig schrijven. De werkafspraken die ik eraan overhield.
Dit is geen artikel met een nette conclusie. Het is er een over iets dat misliep, twee keer, en over wat ik sindsdien anders doe.
Ik werkte aan een datamodel in een projectformaat, het soort waarbij je model als losse bestanden op je schijf staat in plaats van in één groot gecombineerd bestand. Dat heeft voordelen: je kan de wijzigingen volgen, je kan met versiebeheer werken, je ziet wat er verandert.
Dat model is twee keer volledig gecrasht. Niet beschadigd, niet gedeeltelijk kwijt. Weg.
Wat er waarschijnlijk gebeurde
Ik werkte op twee manieren tegelijk aan hetzelfde model. Ik paste dingen aan in de ontwerptool, en tegelijk schreef ik er programmatisch naartoe via de interface die dat toelaat.
Die twee doen allebei hetzelfde ding: ze schrijven naar het model. En de ontwerptool synchroniseert ondertussen ook nog eens naar de bestanden op je schijf.
Drie partijen die naar dezelfde toestand schrijven zonder dat er iemand de leiding heeft. Dat gaat een tijdje goed en dan een keer niet.
Ik kan niet bewijzen dat dat de oorzaak was, en ik zeg het dus zoals het is: dit is mijn beste verklaring, gebaseerd op wanneer het gebeurde. Maar sinds ik me eraan hou, is het niet meer voorgevallen.
Wat ik sindsdien doe
Terug naar het gewone bestandsformaat. Dat is een stap achteruit qua versiebeheer en ik heb het met tegenzin gedaan, maar het houdt stand. De voordelen van het projectformaat wogen niet op tegen twee keer opnieuw beginnen.
Nooit tegelijk in de ontwerptool en via de programmatische weg werken. Één van de twee tegelijk, en de andere gesloten. Dat klinkt evident en het is precies wat je vergeet als je snel iets wil aanpassen.
Schrijfacties bundelen. In plaats van twintig kleine wijzigingen achter elkaar, één blok dat in één keer wordt doorgevoerd. Minder momenten waarop er iets halverwege kan staan.
Herberekeningen beperken. Elke wijziging die het model dwingt om alles opnieuw te berekenen, is een periode waarin het kwetsbaar is. Als je er drie na elkaar doet, heb je drie keer dat risico.
Het bredere punt
Wat me hiervan is bijgebleven, is niet de technische les. Het is hoe weinig dit soort dingen opgeschreven wordt.
Je vindt online duizenden artikels over hoe je iets bouwt. Je vindt er heel weinig over wat er stukgaat en waarom. Dat komt deels omdat het niet flatteert om te schrijven dat je twee dagen werk kwijt bent, en deels omdat het pas gebeurt als je iets lang genoeg doet.
Terwijl het net dat is wat iemand nodig heeft. Hoe je een model opbouwt, staat in elke handleiding. Dat je niet tegelijk langs twee kanten aan hetzelfde model moet zitten, staat nergens, en het kost je een namiddag om er zelf achter te komen.
Wat je hieruit kan meenemen
Als je met een model werkt waar meerdere hulpmiddelen naar schrijven, spreek dan af welk hulpmiddel op welk moment de leiding heeft. Ook als je alleen werkt, want dan ben jij degene die zichzelf onderbreekt.
Maak een kopie voor je aan iets structureels begint. Niet als procedure, maar gewoon als reflex, zoals je een document opslaat voor je een grote wijziging doet.
En schrijf op wat er misging toen het misging. Ik heb dat gedaan en het is de enige reden dat ik dit nu kan vertellen in plaats van me af te vragen of het aan mij lag.
De stelling
De handleidingen leggen uit hoe je iets bouwt. Wat je vak maakt, is weten waar het stukgaat, en dat leer je alleen door het een keer kwijt te zijn.