Agile, Programming

If You’re Using Pull Requests, You Probably Aren’t Doing Continuous Integration

I tend to agree with David Masters that pull requests (merge requests) hold the team back. They prevent you from doing continuous integration as it was originally defined in Kent Beck’s Extreme Programming:

Continuous — Every day (the when)
Integration — The mainline branch (the where)

On Medium: Are Pull Requests Holding Back Your Team? by David Masters.

Agile, Blog, Programming

Ontwerp voor fail safe

Bij de grand prix in Zandvoort is Sebastian Vettel komen stil te staan, er komt rook uit zijn auto. Hij rommelt met een brandblusser, marshals mogen er niet gelijk bij, en als er de rode vlag is, doen ze toch vrij weinig. Het duurt allemaal nogal lang voordat de auto wordt weggehaald. De commentator legt het later uit: “De brandweerman had bij de pit nagevraagd of er stroom op de auto stond, het antwoord was nee, maar hij kreeg toch een optater. De chef van het circuit heeft toen gezegd: als ik van de één te horen krijg dat er geen stroom is, en van de ander van wel, dan neem ik het zekere voor het onzekere: er staat stroom op de auto dus is er rode vlag”.

Dat is een vorm van het “fail safe” principe, ook wel genoemd “bij twijfel niet inhalen”. De circuitbaas kiest voor de oplossing die altijd veilig is, namelijk de aanname dat er stroom op de auto staat. Is dat zo, dan moet de race worden gestopt, is dat niet zo, dan kan het geen kwaad dat de race wordt gestopt. Zou andersom worden beslist, iets van “bij twijfel wel inhalen”, dan bestaat het risico dat de brandweer gaat spuiten en er iemand wordt geëlektrokuteerd.

Tijdens het natuurkunde bijvak in mijn sterrenkunde studie (ik heb in mijn doctoraalstudie veel elektrotechnische dingen gedaan) heb ik veel geleerd over “fail safe”. Ik deed onderzoek met een spectrograaf, een apparaat waarmee je licht kunt ontleden. Dat resulteert in een foto waarbij alle golflengten van het licht apart worden weergegeven. Bovenstaande illustratie is zo’n spectrum, gemaakt met één van de spectrografen waarmee ik heb gewerkt (ontleend aan het proefschrift van Ton Raassen). Het is een spectrum van UV licht, van rond 122nm golflengte. Ultraviolet licht wordt niet doorgelaten door de lucht om ons heen, dus de spectrograaf bevond zich in een grote tank die we vacuum konden pompen. De lichtbron was een staafje van een bijzonder metaal, Yttrium of Ytterbium of eén van al die bijzondere metalen. Omdat we een vonk lieten overspringen tussen twee staafjes Yttrium, en een vonk niet ontstaat als er geen lucht is om de elektriciteit te geleiden, moesten we een hoge spanning op de staafjes zetten zodat met het pietsebeetje lucht (het vacuum was niet perfect, dat kan niet op aarde) toch een vonk ontstond. Ik bediende dus een “plofkast” waar maximaal 10 kilovolt mee opgewekt kon worden en een stroom van een paar duizend ampère. Er was een trillingskring (je weet wel, een spoel, en condensator en een weerstand) om de vonk even gaande te houden. Je begrijpt dat een spoel voor 10kV en een paar duizend ampère een groot ding is: een flinke koperen pijp in een paar windingen gedraaid. De condensator was enorm, de weerstand ook.

De tank was een groot ijzeren ding waarvan de bovenkant hydraulisch omhoog kon zodat je de een fotografische plaat in de spectrograaf kon zetten. Achter de tank zat een vacuumpomp die werkte met een olie-scherm, en daarachter twee mechanische vacuumpompen. De spectrograaf had een tralie (een glazen plaat met streepjes die werkt als een prisma, maar dan anders). Dat tralie had een gouden coating en had zoveel duizend lijntjes per milimeter, en kostte iets van 20.000 gulden. Als de mechanische vacuumpomp uitviel, werd het oliescherm van de olie diffusiepomp in de tank geblazen en konden we het tralie weggooien. Als de hydraulica het begaf als ik net in de tank leunde kwam het deksel naar beneden en was ik doormidden. Als ik te dicht bij de plofkast kwam, was ik verdampt. Vandaar dat op vele manieren het fail safe principe was geïmplementeerd. Rond de hele opstelling stond een aluminium hek, dat goed was geaard. Als er ook maar het minste mis was met het hek, ging de elektriciteit uit. Op de plofkast zat een “schakelaar” die met perslucht werkte, en als de perslucht uitviel ging de schakelaar in de veilige stand, dat wil zeggen de elektra ging uit. Als de mechanische vacuumpomp uitviel, sloten onmiddelijk alle kleppen van de olie-diffusiepomp, zodat er geen olie in de tank kon komen. Er was een bedieningspaneel voor alle apparatuur, buiten het hek, als daar iets mee was, ging de hoogspanning uit en de kleppen op veilig. Alles in de hele installatie was zo ontworpen dat als er iets mis ging of stuk ging, niemand gewond kon raken en het tralie niet beschadigd kon raken. Het was ontworpen voor fail safe.

Natuurlijk heb je geen garantie. Toen ik op een middag lekker zat te ploffen merkte een collega op dat er vonkjes van het aluminium hek sprongen. We hebben alles gelijk stilgezet, en na grondig onderzoek gevonden dat het hek niet goed geaard was. Dikke koperen strips bleken niet genoeg aarde voor de hoge spanning. Ik kon een week niet ploffen omdat een installateur een nieuwe aardleiding moest maken in het grondwater. Diezelfde collega-student is er later in geslaagd toch een instelling te vinden waardoor de olie in zijn installatie (er waren twee spectrografen, hij werkte met de ene, ik met de andere, we gebruikten hetzelfde hek en plofkast) op het tralie belandde. Prof. Klinkenberg was daar niet blij mee.

Je verwacht dat wetenschappers allemaal begrijpen wat fail safe is. Niet alleen in het ontwerp van installaties (of sofware) maar ook bij het interpreteren van metingen en het nemen van beslissingen. Ik was daarom zeer verbaasd toen Jaap van Dissel het volgende zei over de mogelijkheid dat het coronavirus via aerosols verspreid kan worden. Hij zei “het is niet bewezen dat het virus via aerosols verspreidt dus we gaan daar niet van uit”. Huh? Fail safe zegt dat je als je iets niet weet, je van de veilige situatie uitgaat. Als je niet weet of een virus via aerosols verspreid raakt, is de veilige situatie die waarin mensen niet besmet raken, dus neem je aan dat het virus zich wel via aerosols verspreidt en neem je daar maatregelen tegen. Je kunt stoppen met die maatregelen als bewezen is dat het virus zich niet via aerosols verspreidt. Van Dissel verbaasde mij des te meer omdat er levens op het spel stonden, en staan. Als blijkt dat het virus zich via aerosols verspreidt, dan is dat in heel 2020 gebeurt, en zijn er weet hoeveel mensen besmet geraakt die niet besmet waren geraakt als Van Dissel iets had begrepen van fail safe.

Er komt natuurlijk meer bij kijken dan alleen “fail safe”. Bij de oude ADM werf in Amsterdam Noord hadden ze in het magazijn een snijmachine om metalen platen te snijden. Een enorm apparaat dat met een valmes zo een plaat doormidden sloeg. Het ding werd bediend met twee drukknoppen op ooghoogte op afstand van elkaar om te zorgen dat je beide armen uit de buurt had als het ding in werking was. Maar dat is natuurlijk onhandig, want dan kun je niet de plaat snel nog even recht leggen, dus zat er ineens een stuk ductape om de ene knop. De ontwerper moet dus verder gaan en detectie inbouwen dat als een knop langer dan x seconden is ingedrukt, de hele installatie uitvalt en niet zomaar weer kan worden aangezet. Waarna mensen dan toch weer iets vinden om het weer gevaarlijk te maken. Lees in “Gödel, Escher, Bach” van Douglas Hofstadter het verhaal van de krab en de schildpad over hoe zo’n wedloop nooit ophoudt.

De moraal van dit verhaal: als je iets ontwerpt, doe het dan zo dat als er iets mis gaat, de gevolgen beperkt blijven. En voor de manager, als je iets moet beslissen en je mist informatie, beslis dan zo dat er in ieder geval geen dooien vallen.

Agile, Programming

Stil op je fiets zitten

Een poos terug fietste ik mijn vaste rondje, ik begon met wat sprinttraining, daarna wat intervallen, en dan lekker uitrijden. Ik haalde bij zo’n sprint een vrouw in, ze fietste een constant tempo langs de vaart, na de sprint haalde ze mij in, en we wisselden in de loop van een uur een paar keer af. Bij Lisserbroek haalde ik haar weer in, en we reden een kort poosje samen, al pratend. Zij deed bloktrainingen, ze ging met haar vriend de Mont Ventoux beklimmen, en had wat extra training nodig. Ze zag een beetje op tegen de inspanning om zo’n grote berg op te fietsen, denk ik. Ik vertelde haar dat ik al wel een poosje fietste, en toen zei ze “ja, je zit zo mooi stil op je fiets”. Ik legde haar uit wat het geheim is van stil op je fiets zitten.

Je ziet nogal ‘s een wielrenner fietsen met bewegende schouders, de rechter schouder naar rechts en omlaag als het rechterbeen omlaag gaat, en links hetzelfde. Hij duwt als het ware zijn been omlaag met zijn schouder. Dat werkt natuurlijk niet, de beweging van je bovenlichaam kost wel energie maar draagt niet bij tot de snelheid. Zo iemand duwt de pedalen omlaag, eerst rechts, dan links, en om en om, net als je op je stadsfiets doet, net als iedereen fietst op een gewone fiets. Maar op een racefiets zitten je voeten vast aan de pedalen en kun je beter een ronddraaiende beweging maken. Je duwt je voeten niet alleen omlaag, maar op het laagste punt ook naar achteren, en dan omhoog, en dan naar voren, en dan weer omlaag. Het moet voelen dat je je voeten in een cirkel beweegt, waarbij je in het ideale geval op ieder punt van de cirkel evenveel kracht zet. Dat lukt natuurlijk niet, want omlaag duwend kun je meer kracht zetten dan omhoog trekkend, en omhoog trekkend meer dan vooruit of achteruit duwend. Toch kun je met een goede ronddraaiende beweging permanent kracht zetten, in plaats van alleen een kwart cirkel rechts en dan een kwart cirkel links. Door permanent met beide voeten te duwen lever je meer vermogen dan als je een kwart van de tijd links omlaag duwt en een kwart van de tijd rechts omlaag duwt. Het voordeel is niet alleen dat je 100% van de tijd duwt, je gebruikt ook meer spieren. Omlaag duwen doe je met je grote dijbeenspier, maar voor ronddraaien gebruik je alle spieren van je been. En meer spieren gebruiken geeft meer kracht op de pedalen. Het effect van je benen goed ronddraaien is dat alleen je benen het werk doen, en dat je dus mooi stil op je fiets zit. Kijk naar wielrenners in een wedstrijd en je ziet dat ze allemaal stil op hun fiets zitten. Behalve Bauke Mollema dan.

Ze fietste verder met haar volgende blok, en ik bolde nog wat uit, en voorbij de Kaag haalde ik haar weer in. Ze zei “ik probeer mijn benen goed rond te draaien, zoals je zei, en dan gaat het fietsen inderdaad makkelijker. Ik moet er nog wel bij nadenken om het zo te doen”. Ja, dat is altijd, als je iets op een andere manier doet, moet je dat in het begin bewust doen, totdat het vanzelf gaat. We praatten verder, ze zei dat ze het ook tegen haar vriend ging vertellen, dat ze over twee weken naar de Mont Ventoux ging, en we praatten over het werk, en over werken in coronatijd, en we kletsten verder terwijl we aan het uitrijden waren.

Gisteren fietste ik weer langs Lisserbroek, in een strak tempo, en toen bedacht ik dat stil zitten op de fiets een metafoor is voor het werken met scrum. Of beter, voor het werken zonder scrum. Stil zitten op je fiets wil zeggen dat je benen 100% van de tijd vermogen leveren, 100% van de tijd effectief bezig zijn. En of je nu hard fietst of lekker rustig, 100% constant vermogen geeft de maximale snelheid bij gegeven vermogen. Dan denk ik aan een scrum sprint, stel dat die twee weken duurt, tien werkdagen effectief. De dag dat de nieuwe sprint start heb je een retrospective meeting, een demo meeting, een sprint-start meeting, en die dag kom je aan software maken dus niet toe. De volgende dag ga je je verdiepen in nieuwe features (user stories, in scrum terminologie) en overleg je met collega’s en zoek je informatie bij elkaar, die dag is niet een heel effectieve programmeer-dag. De laatste dag van de sprint moet je zorgen dat je administratie op orde is, dat alle items op het scrum bord op “done” staan, dat de verslaglegging goed is, en dat je je demo van de volgende dag voorbereidt. Die laatste dag is ook niet de meest effectieve programmeerdag. Dus van de tien werkdagen in een sprint, kun je zeven dagen optimaal werken. Behalve dan dat je iedere dag een kwartier “stand-up” hebt, daarvóór kom je aan geconcentreerd werken niet toe, je bent zomaar een uur kwijt iedere dag. Effectief werk je zeven dagen van zeven uur aan de software. En in die bijna 50 uur doe je minder dan in 10 dagen van 8 uur. Of je moet in die 50 uur meer “vermogen” leveren dan in 80 uur, zoals je op de fiets als je niet stilzit bij het omlaagtrappen meer vermogen moet leveren als dat je mooi rond trapt.

Natuurlijk pleit ik er niet voor dat een software ontwikkelaar de hele dag alleen stilletjes in een hoekje moet zitten programmeren. Natuurlijk is overleg nodig, natuurlijk is afstemming nodig met collega’s, natuurlijk moet je samen de grote lijnen bepalen en bijstellen. Alleen, dat gebeurt evengoed wel. Dat gebeurt meestal als het nodig is, om elf minuten over drie ‘s middags, of om tien voor negen in de ochtend, en niet op het moment dat scrum zegt dat er een standup moet zijn of een refinement meeting. In de praktijk zijn de meeste vergaderingen en overleggen die scrum voorschrijft “extra”, dat wil zeggen, bovenop de discussies die je evengoed al hebt met je collega’s. En dat is waarom ik scrum vergelijk met de schokschouderende fietser: je bent niet 100% van je tijd productief bezig en je levert dus minder resultaat dan je zou kunnen, of je moet in de mindere beschikbare tijd harder werken om hetzelfde te bereiken.

In een eerdere blog heb ik geschreven hoe empowerment van medewerkers leidt tot beter resultaat. In een nog eerder stukje heb ik opgeschreven wat de frustraties zijn die werken met scrum voor veel software ontwikkelaars opleveren. In de praktijk – mijn ervaring in het werken in software ontwikkel teams beslaat een periode van 40 jaar – zie ik dat iedere methodiek verwordt van een handige tool om beter te werken tot een doel dat het werk zelf in de weg staat. Dat was zo bij SDM in de jaren ’80, dat was zo bij Prince2, en dat is zo bij Scrum. Waar agile (slagvaardig, wendbaar) werken goed is, verwordt het tot een rem op het werk zodra je het vastlegt in regels en procedures.

Als je als manager wilt dat je mensen effectief en met plezier werken, dan kun je er het beste voor zorgen dat ze zelf mogen sturen, en dat je ze stil op hun fiets laat zitten om maximaal resultaat te halen.