Wat is daar nou zo mooi aan?

Door Arjen Uittenbogaard

Waarschuwing. Dit wordt een stukje over hardcore softwareontwikkeling. Maar ook voor niet-programmeurs valt er hopelijk iets van te leren.

Er zijn van die artikelen die een blijvende indruk maken. Klassiekers die je een inzicht geven waardoor je kijk op de wereld voorgoed verandert. Voor mij was een van die klassiekers deze XP-episode. Hierin wordt letterlijk verteld hoe twee programmeurs tot de puntentelling voor een bowlingwedstrijd komen. Als je geen programmeerervaring hebt, kan ik me voorstellen dat je weinig plezier beleeft aan het stuk. Iemand die ik op dit stuk wees maakte in zijn reactie de vergelijking met oud-Chinese poëzie: je kunt je voorstellen dat sommige mensen er lyrisch van worden, maar jou ontgaat de schoonheid. Toch had hij serieus geprobeerd het stuk door te nemen. En wat hem was opgevallen: “Ze willen code gaan schrijven en het eerste wat ik in die abracadabra ontwaar is: ‘test’?!” Waarmee hij de eerste reden raakt waarom ik het zo’n prachtstuk vind.

Zijn verwarring is vergelijkbaar met wat programmeurs dik 15 jaar geleden overkwam. Toen werd het artikel gepubliceerd met de titel: “Test infected. Programmers love writing tests”. In plaats dat je als programmeur meteen begint te programmeren, werd daarin gezegd dat je moest beginnen met het schrijven van tests. Waanzin ten top. Maar het was wel het begin van Test-Driven Development (TDD). Een revolutie in ontwikkelland. Eerst een test schrijven dwingt je als programmeur eerst goed te snappen wát je nu eigenlijk wilt maken. Je specificeert als het ware de acceptatiecriteria van de story, maar dan meteen in code. Zo kun je met een gerust hart voortaan de software uitbreiden en aanpassen: je draait gewoon weer alle tests en ziet meteen of je niks kapot hebt gemaakt. Hoe dit werkt is mooi te lezen in die XP-episode. Elke keer als de mannen al pratende een vraag steeds ingewikkelder maken, is de reactie: laten we maar eens een test schrijven. Het grappige is dat ze er zo gaandeweg achter komen dat hun code ‘klaar’ is: elke volgende test die ze bedenken doet het dan al zonder dat ze er nog iets voor hoeven te programmeren.

Natuurlijk is het dan nog niet echt klaar. Dat brengt me op de tweede reden waarom ik dit verhaal zo gaaf vind. De samen programmerende mannen in het stuk zijn continu bezig de code beter te maken, te refactoren. Steeds weer in het verhaal blijven zaken knagen waarvan ze vinden dat die beter moeten. Een voorbeeld voor iedereen die wel eens met code bezig is. Het komen tot goede code is geen sinecure en vraagt veel discipline. Het is daarom al te verleidelijk om dit af en toe te laten verslappen. Maar in het stuk lees je hoe de discipline ingebed kan worden in het ontwikkelwerk: bespreek wat je nodig hebt, maak een test, als deze niet slaagt maak je de benodigde code en tot slot maak je je code weer netjes.
(Terzijde, een van de teams die ik coach houdt zogenaamde Clean Code sessies. Deze zijn genoemd naar het boek Clean Code dat gaat over het schrijven van goede code. Eens in de twee weken bespreekt het team met elkaar een hoofdstuk en past het toe op hun eigen code. Een mooie gewoonte die ik álle bouwteam van harte aanbeveel!)

Een laatste reden waarom ik die XP-episode zo mooi vind, is omdat in dit stuk het maken van de puntentelling van bowling uiteengerafeld wordt in piepkleine stories. Mensen die mij kennen, kennen mijn mantra: “Het moet kleiner.” Ik weet het: ik zeg het zó vaak, dat het sommigen begint te irriteren. Toch blijf ik het roepen. Zolang we nog over stories praten die ruim meer dan één sprint kosten om gerealiseerd te worden, zijn ze veel te groot. Zolang we in de voorbereiding op het echte werk nog documenten van tientallen pagina’s schrijven, zijn die veel te groot. Het moet allemaal kleiner. Voor mij is de XP-episode een mooi voorbeeld hoe ver je daarin kunt gaan. De eerste story is er een van verbluffende eenvoud: “Als er nog geen bowlingbal is geworpen, moet de score 0 zijn.” Daarmee is de ‘feature’ van de puntentelling niet af, maar wordt wél een stukje waarde gerealiseerd. Een stukje functionaliteit dat gedemonstreerd en getest kan worden. Niet analyseren tot de hele puntentelling is ontworpen en pas dán beginnen te programmeren, maar al programmerende het ontwerp ‘ontdekken’. De running gag door het hele artikel gaat over een stukje ontwerp dat ze wel vooraf hebben gemaakt. Achteraf blijkt dat te ingewikkeld te zijn geweest.

Kleine, heel kleine stapjes. Steeds weer feedback krijgen en dat gebruiken als start voor een volgende verbeterstap. Gecombineerd met veel discipline leidt dit tot een mooi resultaat. Daarom vind ik dit nou zo’n mooi en inspirerend stuk!

Arjen Uittenbogaard

Arjen is verhalenverteller. Een training van hem is een ervaring die je niet licht vergeet. Hij is ook regisseur van improvisatietoneel. Dat vindt hij een mooie metafoor voor zijn werk in het coachen van teams en individuen in organisaties die meer agile willen worden. Want dat is zijn expertise: agile werken. Daar heeft hij al twintig jaar ervaring mee en daar is hij goed in. Zijn hart gaat uit naar de menselijke kant van het werk, naar de communicatie en de samenwerking. Daarbij weet hij alles van complexe adaptieve systemen: omgevingen waarin niets is wat het lijkt, waar best practices je op het verkeerde been kunnen zetten en waar je steeds zult moeten experimenteren en leren. Ook heeft hij nog steeds lol van zijn achtergrond in object georiënteerde softwareontwikkeling: hij mag ontwikkelaars graag uitdagen op hun ontwerpen en de toepassing van design patterns daarin.

06 - 59 443 440

Andere posts

Klik hier