Dit is het eerste deel van een serie van drie blogartikelen waarin ik uitleg wat technische schuld (technical debt) is, hoe het kan ontstaan, waarom het negatieve impact heeft en wat organisaties eraan kunnen doen om dit terug te dringen.
Inleiding
Met de komst van agile werkvormen en multidisciplinaire teams gaan ontwikkelaars steeds meer werkzaamheden doen die vroeger belegd waren bij testers. Statische code-analysetools (als SonarQube) geven de ontwikkelaar dashboards met daarin allerlei kreten uit de testwereld. Zo ook de term technische schuld. Ik krijg hierover vaak vragen omdat het concept niet goed begrepen wordt.
Afgelopen jaar ben ik actief geweest voor meerdere klanten als kwaliteitsadviseur. Bij verschillende projecten ben ik getuige geweest van teams die per sprint steeds minder werk konden verzetten. Zowel de teams als de PO staan met hun handen in het haar en weten niet hoe ze het tij kunnen keren. Toevoegen van development capaciteit vertraagt in eerste instantie de voortgang en het doen van meer refinements ook.
Een opdrachtgever, die het probleem iedere sprint zag toenemen, vroeg aan mij: 'wat is acceptabele technische schuld?'
Wat is het?
Technische schuld is een jargon uit de IT-wereld binnen het domein van testen en kwaliteit. Het is een verzamelnaam voor herstelkosten (oplostijd, opgetelde mean-time-to-resolution) van achterstallig onderhoud of geïmplementeerde oplossingen die niet voldoen aan de kwaliteitseisen.
‘Technical debt’ wordt vaak uitgedrukt in tijd, dus uren of dagen van herstelwerkzaamheden. In het algemeen geldt dat bij meer technische schuld de algehele kwaliteit van het product lager is en bij een lagere technische schuld is de kwaliteit hoger.
Herkomst
De term is ooit bedacht in 1992 als een analogie met monetaire schuld[1]. Om sneller software op te kunnen leveren kunnen er concessies gedaan worden op de kwaliteit. Dit is net als een lening. Een lening kan handig zijn om snel een doel te behalen, bijvoorbeeld bij het doen van een pilot. Echter, een lening bouwt schuld op en dit geldt ook voor technische schuld. Naarmate de tijd vordert nemen, om verschillende redenen die hieronder worden uitgediept, de herstelkosten toe. Daarom is het ook belangrijk om de trend van de technische schuld te bewaken in plaats van alleen het aantal uur.
Voorbeeld
Je hebt goedkoop een autowrak op de kop weten te tikken en je hebt aan een enthousiast garageteam gevraagd om deze op te lappen zodat het een mooie oldtimer wordt. Het team gaat aan de slag en omdat ze snel iets willen demonstreren, gebruiken ze wat plastic buisjes in plaats van rubber in de motor. Ze zijn op tijd voor de eerste demo en ze kunnen een draaiende motor demonstreren aan je. Ze geven aan dat dit een prototype is omdat er wat concessies zijn gedaan en ze willen dat komende tijd oplossen. Dit zal niet meer dan een dag kosten. Echter, omdat je het liefst zo snel mogelijk de weg op wilt vraag je het team om hun energie te steken in het functioneel afronden van de auto zodat hij rijklaar is en toegestaan is op de openbare weg. Dit is nog een hele kluif voor het team, maar ze gaan ermee aan de slag. Na enkele weken is de auto rijklaar.
Iedereen is inmiddels de buisjes vergeten en met veel plezier neem je de auto in gebruik om lekker te toeren op zondag. Tot je verbazing merk je na een week verminderde prestaties, optrekken gaat steeds moeizamer.
Het garageteam kijkt ernaar en kan de oorzaak zo snel niet achterhalen omdat ze de buizen zijn vergeten. Niemand heeft daar destijds iets over opgeschreven. Om dit goed te onderzoeken zou de motor hiervoor uit elkaar moeten maar dit kost weken omdat de motor inmiddels helemaal is aangesloten. Dus brengen ze hier en daar wat ducttape aan, hier en daar en de auto lijkt het weer enigszins te doen.
Vanaf dat moment moet het garageteam steeds meer tijd en energie steken in reparaties om de auto op de weg te houden, tijd die ze liever besteden aan auto’s bouwen.
Wat in het bovenstaande voorbeeld gebeurt, zie ik vaak gebeuren in softwareontwikkelprojecten. Er wordt vooral energie gestoken in nieuwe features en daardoor worden de provisorische of tijdelijke implementaties niet structureel opgelost. Hoe langer het team wacht met dit onder handen nemen, hoe meer de oplostijd toeneemt omdat het in de vergetelheid raakt en de complexiteit van het systeem neemt toe.
Het team komt nu langzaam in de situatie waar ze het merendeel van de tijd bezig zijn met 'brandjes blussen'. Het lukt het team niet meer te ontwikkelen met dezelfde snelheid als in het begin en de moraal daalt.
Waar het mis gaat
Herkenbaar verhaal? Benieuwd naar de oorzaak? In mijn volgende blog ga ik in op welke fundamentele principes er zijn geschonden die hieraan ten grondslag liggen.
[1] Bron: https://en.wikipedia.org/wiki/Technical_debt#Consequences
Discussion (0)