Het beroemde motto van Facebook 'Move Fast and Break Things' ('ga snel en maak dingen kapot') is door de internetgigant zelf al een tijdje losgelaten. Het motto lijkt op te roepen tot een zekere roekeloosheid in it-ontwikkeling, en is door velen buiten Facebook omarmd. Misschien is het tijd om de gevolgen van die roekeloosheid eens onder ogen te zien, en een periode van bezinning in te luiden: 'Move slow and fix things' ('beweeg langzaam en repareer').
Vier jaar geleden veranderde Facebook zijn beroemde motto ‘Move fast and break things’ in ‘Move fast with stable infra’ (iets minder aansprekend?). De meeste mensen brengen het oorspronkelijke motto in verband met het ontregelen van bestaande businessmodellen (zie bijvoorbeeld Jonathan Taplins boek). Mark Zuckerberg liet echter zelf doorschemeren dat het motto afkomstig is van een bepaalde houding ten opzichte van softwareontwikkeling: ‘Voor ons als ontwikkelaars was snelheid zo belangrijk dat we er zelfs een paar bugs voor tolereerden’. Maar zelfs Facebook kwam er achter dat die houding meer schade berokkent dan hij oplevert.
Snel nieuwe functionaliteit
Bij softwareontwikkeling gaat ‘move fast and break things’ over de noodzaak om in het begin van de levenscyclus van een product snel nieuwe functionaliteit te creëren. Dit heeft te maken met het eerste agile principe: ‘Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.’ Functionaliteit voegt direct business-waarde toe, en het ‘break things’-deel van het motto kent lagere prioriteit toe aan werk dat indirect business-waarde toevoegt – werk dat vaak wordt aangeduid met de term ‘enabler’ (‘mogelijkmaker’).
Agile principes acht en negen benadrukken echter het belang van constante ontwikkeling en hoge technische kwaliteit, en een tempo dat eeuwig volgehouden kan worden. Enablers creëren en onderhouden de architecturale ruggengraat van een product, ten behoeve van kwaliteit op lange termijn. Een organisatie die enablers verwaarloost ten gunste van functionaliteit bouwt technische schuld op; hoe langer enablers worden uitgesteld, hoe hoger de schuld en de impact ervan op productiviteit en kwaliteit. Een product of organisatie met technische schuld is niet in staat om een tempo eeuwig vol te houden.
Alle grotere organisaties die ik in mijn dagelijks werk tegenkom hebben op de één of andere manier behoorlijk last van technische schuld. In veel gevallen heeft de druk om snel voortgang te maken (‘move fast’) geleid tot gebrek aan budget en aandacht voor enablers als ‘onder de motorkap’ verbeteringen en het terugbetalen van technische schuld. Ze zijn snel gegaan, en nu zijn er dingen kapot.
Hoe is het zo ver gekomen?
Uit gesprekken met architecten, product owners en managers komen een aantal mogelijke oorzaken voor de technische schuldenlast naar voren:
- ‘Reguliere’ moderne business-praktijken: kpi’s (kritieke prestatie indicatoren) leiden vaak tot het prioriteren van meetbare korte-termijn successen boven lange-termijn investeringen.
- Onrealistische verwachtingen: het tijdelijk uitstellen van enablers (vaak vanwege gegronde zakelijke redenen) leidt kortstondig tot een sterkere groei in business-waarde, tot grote vreugde van klanten en andere belanghebbenden. Het wordt daardoor echter steeds moeilijker voor de teams om het teleurstellende nieuws te moeten brengen dat ze dit tempo niet eeuwig kunnen volhouden, waardoor ze zichzelf steeds meer onder druk zetten en doorgaan met het opbouwen van technische schuld.
- Cargo cult: door het succes van internetreuzen zijn veel organisaties geneigd de methodes, praktijken en frameworks van die reuzen over te nemen, vaak zonder eerst goed te kijken naar verschillen in cultuur en bedrijfsdoelstelling (en als die methodes dan falen roepen hun voorstanders om nog extremere implementaties, want ‘we hebben het dus niet ver genoeg doorgevoerd’ of ‘de tegenstribbelaars hebben de methode gesaboteerd’).
Andere potentiële oorzaken liggen in het verkeerd toepassen van agile praktijken, zoals:
- WSJF (Weighted Shortest Job First – gewogen korste taak eerst) prioritering (specifiek voor Safe, het Scaled Agile Framework): vanwege hun omvang en indirecte business-waarde kunnen enablers over het algemeen niet concurreren met features en functionaliteit bij WSJF prioritering. Om die reden adviseert Safe om afzonderlijk capaciteit te reserveren voor enablers; het negeren van dit advies leidt tot het ten onrecht toepassen van WSJF op enablers, en opeenhoping van technische schuld.
- MVP (Minimal Viable Product – minimaal werkbaar product): een eerste versie van een product met net voldoende kenmerken om vroege klanten te bedienen, en feedback op te halen voor toekomstige ontwikkelingen. MVP’s houden nog geen rekening met ‘edge cases’ (randgevallen of zelden voorkomende omstandigheden waaronder het product gebruikt wordt) en sommige non-functionele eisen (NFR’s, zoals beperkte schaalbaarheid). Edge cases en NFR’s kunnen echter grote impact hebben op de architectuur. Doorontwikkeling op basis van een MVP zonder de architectuur in ogenschouw te nemen (of helemaal opnieuw op te bouwen) is een verkeerde toepassing van het MVP concept die tot opbouw van technische schuld leidt.
Hoe nu verder
Bij de panel-discussie over de ‘dood van de architect’ op het Saturn-congres dit jaar, grapte ik dat de wereld verdrinkt in een moeras van technische schuld. Dat was behoorlijk overgedramatiseerd, maar niemand kan ontkennen dat we met een probleem zitten. De technische schuldenlast kost niet alleen capaciteit en budget die bedrijven liever aan innovatie besteden, maar hij leidt ook tot echte maatschappelijke problemen – zo afhankelijk zijn we geworden van goed werkende software. Architecturen zonder ondersteuning voor edge cases kunnen zelfs belangrijke ethische problemen veroorzaken door groepen klanten en burgers uit te sluiten van (soms essentiële) diensten. Een aantal schrijnende voorbeelden hiervan worden uitgebreid beschreven in ‘De Digitale Kooi’ van de Kafka Brigade.
Technische schuld veroorzaakt echte economische, maatschappelijke en ethische problemen. Het wordt tijd om daar iets aan te doen – te beginnen met het aanpakken van de hierboven genoemde oorzaken. Ik heb niet de illusie dat we makkelijk de korte-termijn focus in moderne bedrijfsvoering kunnen veranderen, maar we kunnen zeker transparanter zijn over wat er nodig is om duurzaam te ontwikkelen, en beter omgaan met de hooggespannen verwachtingen van belanghebbenden aangaande een tempo dat lang vol te houden is. We kunnen ook slimmer zijn in het toepassen van agile praktijken – door te zorgen dat we die praktijken en hun beperkingen leren begrijpen voordat we ze toepassen.
Meer aandacht voor enablers betekent dat er minder capaciteit voor nieuwe dingen zal zijn – aanvankelijk zullen we langzamer worden. Maar dat is misschien wel oké. Grady Booch tweette onlangs nog ‘What does software development look like in a post-agile world?‘ Ik hoop dat we ons duurzamer en realistischer zullen opstellen: ‘Move slow and fix things’.
