'Extreme programming' verzwakt architectuur

Enkele maanden geleden kreeg ik ineens de behoefte een klein programma te schrijven om backups van mijn eigen bestanden te maken. Ik had al wat bestaande producten bekeken en die voldeden niet aan mijn wensen. Dapper besloot ik om het zelf te gaan schrijven. Het leek me ook een leuke vingeroefening.

Initieel besloot ik om het in C# te schrijven met gebruikmaking van Visualstudio.Net, maar dat werd al snel te veel code. Voordat ik het in de gaten had, had ik al twee pagina's met C#-code, terwijl er niets gebeurde. Het leek me verstandiger om over te stappen op een 'scripting'-taal. Eerst dacht ik aan Python, maar in mijn speurtocht naar de Python-cd viel mijn oog op Rexx. Deze oude 'scripting'-taal stamt nog uit het mainframe-tijdperk. Waarom niet, dacht ik. Ik had nog nooit met deze taal geprogrammeerd, dus dat zou het gelijk een extra uitdaging maken.
Bij de ontwikkeling heb ik zoveel mogelijk de xp-principes (extreme programming) toegepast. Het resultaat is een programma van nog geen honderd regels met een eenvoudig te onderhouden en goed geteste structuur. Dit compacte programma, dat nu elke dag een incrementele backup maakt, heeft echter geen architectuur. Het slaat geen gegevens op in een database, gebruikt geen applicatieserver, beveiliging speelt geen rol, en is niet uit drie lagen opgebouwd; het is een recht-toe-recht-aan programma.
Had ik xp kunnen toepassen als het programma wel op een degelijke softwarearchitectuur had moeten steunen? De meeste administratieve informatiesystemen hebben dat namelijk wel nodig. Als een programma door honderden gebruikers benaderd wordt en een centrale database manipuleert, is een doordachte softwarearchitectuur vereist.
Van de 'agile' methodieken is xp waarschijnlijk de bekendste. Kenmerkend is een aantal sterke principes. Sommige zijn uniek voor xp, andere kennen we nog van oudere methodieken. Voor mijn kleine backup-programma was xp goed toe te passen. Het is ook geschikt voor veel grotere projecten. Net als elke methodiek heeft het echter ook zwakke kanten. Eén daarvan blijkt als het programma een complexe onderliggende en dragende softwarearchitectuur moet hebben. De hoge iteratiegraad en het 'user-story' gedreven werken leiden ertoe dat aan het begin niet altijd voldoende over de architectuur nagedacht wordt.
Vorig jaar verscheen een boek met de intrigerende titel Extreme programming refactored: the case against XP geschreven door Matt Stephens en Doug Rosenberg. Ik ben zelf een groot voorstander van xp en dergelijke methodieken, dus dit leek me een spannend boek. Er zijn al veel boeken over xp geschreven (bij Amazon krijg je op deze twee woorden meer dan twintigduizend hits). Allemaal vertellen ze hoe krachtig deze revolutionaire aanpak is. Dit boek is een uitzondering. Het geeft de zwakke plekken haarfijn aan. De auteurs schrijven dat het lastig is om met xp een geschikte softwarearchitectuur uit te dokteren. In de meeste boeken over xp zijn de voorbeelden dan ook altijd programma's waarvoor een architectuur niet echt nodig is.
Iemand die zich bezighoudt met systeemontwikkeling, of hij nu in het voortraject zit of de code moet intikken, hoort verschillende methodieken te kennen, waaronder xp. We horen ook te weten wat de sterke én zwakke eigenschappen zijn, en wanneer xp al dan niet ingezet hoort te worden. Aan het gebruik kleven risico's en de architectuur is er daar één van. Het blind en haast fundamentalistisch toepassen van een methodiek is altijd al naïef geweest. Een methodiek is als een stuk gereedschap; je moet weten wanneer je hem wel en niet kunt inzetten. Misschien moeten we initieel met een wat klassiekere methodiek de architectuur analyseren en ontwikkelen, om vervolgens de programma's met xp uit te werken.< BR>
 
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.