Technical debt: durf te kiezen voor korte termijn pijn, lange termijn fijn

Meer dan 65 procent van de kosten van software zit in onderhoud, nog geen tien procent in het ontwikkelen van de eerste versie. Als je dus bij één product zou moeten sturen op de Total Cost of Ownership (TCO) dan is het wel software. Dat betekent dat je agile teams de tijd zou moeten geven om software onderhoudbaar op te leveren zonder technical debt.

Technical debt (technische schuld) is al het (ontwikkel)werk dat later ontstaat doordat wordt gekozen voor oplossingen die op korte termijn weliswaar makkelijk te implementeren zijn, maar die op lange termijn moeilijk te onderhouden zijn. Het concept is breder dan code alleen, het gaat ook om de mate waarin je de tijd neemt om tests te automatiseren, documentatie up-to-date te houden et cetera.

De rente op technical debt is torenhoog

Het woord technical debt geeft prima in businesstaal aan wat het probleem is: geld lenen kost geld. En anders dan in ons huidige financiële klimaat is de rente op technical debt hoog. Het kan om tientallen procenten per jaar gaan! Rood staan op je creditcard valt erbij in het niet.

Als dit zo helder is, waarom kiezen dan toch zoveel bedrijven voor ‘korte termijn fijn, lange termijn pijn’? Want dat is wat je doet als je de lage TCO op lange termijn aan de kant schuift onder het mom van ‘de tijdsdruk is zo groot’. Natuurlijk, in onze snel veranderende wereld is de tijdsdruk vaak ook hoog. De business is als de dood dat een concurrent sneller op de markt komt met een nieuw idee. En Den Haag strooit maar al te graag nieuwe wet- en regelgeving over ons uit, waar dan in no-time de systemen op moeten worden aangepast. De product owner staat daardoor met zijn rug tegen de muur en weet vaak helemaal niet goed waar hij ja tegen zegt.

Risico’s blijven onduidelijk

En misschien zit daar wel het echte probleem. Want als een agile team zelf niet in staat is om te verwoorden (en liefst ook berekenen) hoe groot de technical debt is die ontstaat als wordt gekozen voor de korte klap, hoe kunnen een product owner en de business het dan weten? Zij zijn net als die naïeve mensen die voor het uitbreken van de crisis gingen beleggen met geleend geld. Kon je dat die beleggers verwijten? Nee, zij konden de risico’s niet overzien en werden door de mensen die hen hadden moeten waarschuwen in de val gelokt. Natuurlijk waren die beleggers zelf ook dom, ze hadden zich moeten verdiepen in de risico’s van beleggen. Maar zoals het zo vaak gaat: verblind door de voorgespiegelde winst hadden ze daar geen zin meer in.

Stop met het opvoeren van de druk op de time-to-market

Nu zullen agile teams de business heus niet bewust in de val lokken, maar onbewust gebeurt het vaak wel. De business heeft een plan voor nieuwe functionaliteit en zet daar meteen druk op. Ze vragen de agile teams om een tijdsinschatting. De teams geven aan voor die tijdsinschatting twee weken voor nodig te hebben, maar die krijgen ze niet. ‘Je kunt toch wel zo uit de losse pols zeggen hoe lang je nodig denkt te hebben?’, is wat ze te horen krijgen. Natuurlijk valt de inschatting dan net iets te positief uit. Dat is niet anders dan wanneer je je huis gaat verbouwen: als de ruwbouw af is en de stucadoor is geweest, voelt het alsof je bijna klaar bent. Daarna begint de afwerking en die valt altijd vies tegen. Bij een verbouwing roept daarom iedereen al snel: ‘nou, tel daar maar drie maanden bij op’. Maar tegen een agile team wordt dat nooit gezegd. Die krijgen van hun opdrachtgever hooguit te horen: ‘kun je niet toch nog ergens tijdwinst halen?’

Die druk op tijdwinst komt ook doordat de waarde van het oplossen van technical debt niet direct zichtbaar is. Het kost veel tijd, maar het is lastig in geld uit te drukken wat je krijgt. Zie hier dan nog maar eens een prioriteit van te maken.

Herken de signalen van technical debt

Werk jij in de business en vraag je je af of technical debt in jouw organisatie een probleem is? Let dan op de signalen. Het eerste wat je ziet gebeuren is dat schattingen die het team maakt steeds onbetrouwbaarder worden. Zij kunnen namelijk zelf de complexiteit ook niet goed overzien. Ook zal het ontwikkelen van nieuwe functionaliteit steeds meer tijd kosten. En het aantal incidenten in productie stijgt.

Ook binnen de teams – vaak onzichtbaar voor de business – zijn er genoeg signalen: de afhankelijkheid van bepaalde personen wordt groter, het inwerken van nieuwe medewerkers duurt langer en de testinspanning per release neemt toe, niet in de laatste plaats omdat er steeds meer bugs aan het licht komen.

Herken je één van deze signalen? Doe er dan nu wat aan! Realiseer je dat je met z’n allen op een boot zit die op de ijszee vaart. De kapitein ziet alleen wat zich boven water afspeelt. Als hij goed wil navigeren, moet hij een beroep doen op de kennis van specialisten die ook weten wat er onder water gebeurt. Er zijn voorbeelden genoeg van organisaties die recht op de ijsberg bleven afvaren omdat de stem van mensen die waarschuwden voor de ijsberg niet werd gehoord. Eén van de meest schokkende is wellicht Knight Capital, de grootste online aandelenhandelaar in de VS die in drie kwartier failliet ging omdat een simulatieprogramma per ongeluk in productie werd gezet en vervolgens in de echte wereld transacties ging doen.

Laat technical debt alleen een dure les zijn

Wil jij niet de volgende Titanic of Knight Capital worden, ga dan nu als business en agile teams om tafel zitten en maak gezamenlijk een risico-inventarisatie. Want het goede nieuws is: het is nooit te laat om er iets aan te doen. Je zit alleen met veel hogere kosten dan nodig was geweest. Hopelijk is dat dan een dure les voor de volgende keer.

Begin met typen en druk op enter om te zoeken

x

Nieuws

Vooroplopen met je testing expertise? Volg Test Forward!

Lees meer