Software ontwikkelen onder architectuur, waar blijft de feedbackloop?

donderdag 30 november 2017

Twintig jaar hou ik me bezig met software ontwikkelen, veel van die jaren met de handen aan de codeknoppen. Toen ik aan de slag ging met deze blog over werken onder architectuur, kwamen momenten naar voren uit die dagelijkse praktijk. Momenten waarin ik als ontwikkelaar diep in de codetunnel bezig was om gaten te dichten of nieuwe stukken tunnel aan te leggen, terwijl ergens ver weg in de woestijn een architect stond te roepen. Dat moet en kan anders.

Bij software ontwikkelen onder architectuur gaat het om abstracte doelstellingen die vooral relevant zijn voor de langere termijn. Althans dat is mijn beeld als ontwikkelaar. Mijn eerste focus is namelijk werkende software opleveren. Dat is concreet, met een duidelijke korte termijn deadline en een heldere feedbackloop: demo’s en testen. Veel, zo niet alles, in mijn omgeving draagt uit dat het opleveren van werkende software belangrijk én urgent is. Zo ontstaat de focus in mijn denken die daarvoor nodig is.

Feedback is nodig, maar komt te laat

Focus en tunnelvisie zijn dezelfde fenomenen. Voor architectuurdoelstellingen is een tunnelvisie vaak een handicap. Het is nodig om diffuus te denken, te kijken vanuit een helikopter. Daardoor ontbreekt de korte feedbackloop in de praktijk. Hoe kan ik als ontwikkelaar weten dat ik geen steken heb laten vallen op het vlak van architectuur? Was ik me bij veel projecten überhaupt wel bewust van de toegepaste architectuur? Hoeveel ‘tijdelijke’ afwijkingen zijn nog steeds niet aangepakt? Eigenlijk komt de feedback pas later: bij een impactanalyse voor een grote wijziging. Zo’n lange feedbackloop zou je eigenlijk geen feedback mogen noemen. Deze komt gewoonweg te laat.

Wel belangrijk, nooit urgent

Als ontwikkelaar heb ik werken onder architectuur wel altijd als belangrijk beleefd, maar nooit als iets urgent. Daar zit volgens mij de pijn en de opgave voor nu.

Urgentie zorgt voor een gevoel van druk en onder druk wordt alles vloeibaar. Met de huidige beleving wint de doelstelling om werkende software op te leveren het te makkelijk van het belang van werken onder architectuur. Architectuur en codekwaliteit moeten een eigen feedbackloop krijgen, naast het huidige instrumentarium: kaders, richtlijnen, besef, discipline, collegiale reviews en beroepstrots van de ontwikkelaar. Vergeet niet dat belangrijke, abstracte zaken altijd speelbal zijn van allerlei groepsprocessen en voor hoger management lastiger vast te pakken. De natuurlijke neiging van mensen is om abstracte problemen door te schuiven, als dat op de korte termijn een concreet probleem oplost. De architect verliest.

Software ontwikkelen onder architectuur betaalt zich terug

Mijn wens is dat werken onder architectuur dezelfde ontwikkeling doormaakt als bijvoorbeeld Test Driven Development (TDD). Het coderen van unittests vooraf aan het daadwerkelijk coderen? Als ontwikkelaar vond ik datmaar inefficiënt. Ik kon me toen niet nog voorstellen dat het me bij het ontwikkelen zoveel zekerheid zou geven. Nu is het de norm. De weerstand die ik voelde op het moment dat ik met TDD te maken kreeg, lijkt veel op de beleving en weerstand die ik nu zie rond werken onder architectuur. Terwijl we wél weten dat onder architectuur werken aan software zich gewoon terugbetaalt.

Feedback op architectuur kan tegenwoordig wel

Laten we dus vaart maken met die feedbackloop. Net zoals de werking van de code getest wordt, is het zaak om ook de onzichtbare kant van software te testen. Dat betekent een helder kader en bewustzijn op alle niveaus. En het betekent instrumenten om ‘architectuur compliance’ objectief in beeld te brengen. Zo bouwen we tegenwicht voor de overtuigingskracht die uit gaat van korte termijnproblemen. Die tools zijn er tegenwoordig, want toetsing van belangrijke onzichtbare zaken hoort net zo gewoon te zijn als testen ‘of het werkt’.