Plaatje kijken

Onlangs kwam ik onderstaande afbeelding tegen op de site van Alistair Cockburn, met als vrijwel enige toelichting dat het door Kent Beck gebruikt werd bij een aantal presentaties die hij gegeven heeft in het jaar 2000. Hoewel een plaatje zoals bekend meer zegt dan duizend woorden, spreekt dit buiten zijn context 12 jaar later niet meer helemaal voor zich.
Ten eerste helpt het als je weet waar XP voor staat. XP, Extreme Programming, is een werkmethode die in de jaren negentig van de vorige eeuw uit experimenten is ontstaan. Het doel waarop gemikt werd, was zo snel mogelijk, zo betrouwbaar mogelijk, zo consistent mogelijk over een langere periode nieuwe functionaliteit met business relevantie op te kunnen blijven leveren.
Met “Swiss XP project” wordt het payroll systeem bedoeld, dat gemaakt werd voor Chrysler. Chrysler werd in 2000 overgenomen door Daimler Benz, waarop het project werd gestopt. Zo eindigt de vette lijn bij “what would this mean?”, zonder dat het Swiss XP project zelf nog op zoek kon gaan naar het antwoord. Ik denk dat het plaatje destijds gemaakt is, om een van de neven effecten van het zoeken naar de meest effectieve werkmethode te illustreren, namelijk dat de release cycles steeds korter werden. Door de Y-as logaritmisch te maken, oogt het ook lekker, met zo’n vette rechte streep, en dat er niet bij staat wat er op de X-as wordt afgebeeld geeft in die context ook niks meer.

Doordat de streep van links naar rechts daalt, wordt gesuggereerd dat “Days of work not yet in production” een slechte zaak is. En dat is natuurlijk ook zo. Want in economische termen laat zich dat vertalen in “een investering waar nog niks tegenover staat”. Pas in productie komt er Return On Investment.

XP is als proces nogal streng. De moderne agilist zal bekend zijn met het begrip “Work In Progres”, en geneigd zijn een verschil te zien tussen “Days of work not in production” en WIP. Binnen XP wordt dit onderscheid echter geen betekenis toegekend. Want naarmate de Gedane Arbeid langer op de plank ligt en niet in productie gebracht is, stijgt de kans dat de Gedane Arbeid (niet begroot) nawerk vereist.
Het is daarom uit het oogpunt van risicomanagement zinvol om de dichotomie tussen “Days of work not yet in production” en “Work In Progress” niet te accepteren. WIP is af als het ROI maakt.

Niet voor niets is “release early, release often” een van agile’s mantra’s. Men slaat bovendien ten minste twee vliegen in een klap: niet alleen wordt de ROI daadwerkelijk zichtbaar, het nog steeds grootste gevaar voor de kwaliteit of zelfs het slagen van projecten, geen of weinig feedback van “expert users” die echt ook iets anders te doen hebben dan ontwikkelaars begeleiden, wordt ook ondervangen.

Inmiddels is de agile bal vrolijk door het software ontwikkellandschap gerold. In de Java wereld zijn 12 jaar later de build server, het schrijven en automatisch uitvoeren van unit-testen, het gebruik van Maven voor het managen van depencies en bouw gemeen goed geworden, zo zelfs dat de afwezigheid van deze tooling gevoeld wordt als onverantwoordelijk gedrag, helemaal los van de mate waarin het project over zichzelf denkt als meer of minder agile. Het bijzondere is gewoon geworden. Niet zoveel projecten gaan dagelijks naar productie, maar met een beetje nadenken over hoe je nieuwe functionaliteit implementeert zou het best kunnen.

En “what would this mean?” In 2007 al werd er door “Express yourself in thé world’s largest 3D Chat and Dress-Up community” IMVU inc. tot 50+ keer per dag “live” gegaan. Zoals in eerste instantie het test – build process zo veel mogelijk geautomatiseerd werd (de avant garde van rond de eeuwwisseling), staat technisch niets ook het automatiseren van de deployments in de weg. En zoals in de loop van de tijd de build en test tools gerijpt zijn, zullen ook de release en configuration management tools steeds volwassener worden.

Over hoe te komen tot een productiestraat die Continous Delivery mogelijk maakt en waarom je dat zou willen is in 2010 een mooie pil verschenen in de Addison Wesley Signature Series van de hand van Jez Humble en David Farley met als titel “Continuous Delivery, Reliable Software Releases through Build, Test, and Deployment Automation”.

Of Continuous Delivery een zonnige toekomst tegemoed gaat? Ik denk het wel, op dezelfde manier waarop de productie van software grosso modo veel gewonnen heeft door inzichten, processen en tooling die met de verspreiding van agile gemeen goed zijn geworden. En net zo min als vandaag de dag de dagelijkse release gangbaar is, zal over 10 jaar de 50+ keer per dag live gaan, die de huidige avant garde 5 jaar geleden alweer haalde bij IMVU, gangbaar noch nodig zijn. Maar, zullen we zeggen, als we er een beetje slim over doen, kan het best.
Het plaatje laat, met dank aan de logaritmische Y-as, ook nog een gedachten experiment toe: Wat gebeurt er wanneer we de lijn nog verder naar beneden door trekken, door de X-as heen? Dan hebben we software gedeployed voor we hem gemaakt hebben. Mooi man. Maar waarom daar gestopt? We trekken de lijn gewoon nog wat door. Dan draait morgen geheel automagisch de oplossing voor het probleem waarvan we ons overmorgen bewust gaan worden. Now we’re talking!

Marcus Dijkstra, JAVA Lead Developer