In de wereld van softwareontwikkeling is technische schuld geen onbekend begrip. Het staat voor het prijskaartje dat je betaalt voor de extra inspanningen die je in de toekomst zal moeten doen omdat je bewust of onbewust niet altijd gaat, of kan gaan, voor de beste of ideale oplossing, maar voor de op dat moment meest aanvaardbare oplossing. Zoals in een vorige blog aan bod is gekomen, kunnen de redenen van technische schuld divers zijn en is het hebben ervan niet inherent slecht, zelfs onoverkomelijk, zolang het kritische niveau ervan niet wordt overschreden.
De misvatting zit echter in het feit dat technische schuld vaak wordt geassocieerd met ‘verouderde’ legacysystemen, eerder dan met ‘moderne’ agile softwareontwikkelingen. Nochtans ontstaat net door het iteratieve en incrementele karakter van agile, en het willen halen van de vooropgestelde sprints, ook het risico dat je mogelijk sneller geneigd bent om shortcuts of binnenwegen te nemen en zo technische schuld introduceert in je softwareproject. Het is dus belangrijk om je ook in agile projecten bewust te zijn van technische schuld en de mogelijke opbouw ervan.
Essentiële en toevallige complexiteit als ijkpunt voor technische schuld
Op zich heeft iedereen binnen softwareontwikkeling wel een bepaalde intuïtieve notie van technische schuld. Concepten als essentiële en toevallige complexiteit kunnen helpen om die notie op een concrete manier te verscherpen, als maatstaf voor bewustwording en remediëring.
De insteek van essentiële en toevallige complexiteit komt van Fred Brooks1, waarbij hij stelt dat software – de oplossing, nu eenmaal een bepaalde essentiële complexiteit heeft die inherent is aan de complexiteit van het probleem dat je ermee wenst op te lossen. Toevallige complexiteit daarentegen is zelf toegevoegde, vermijdbare complexiteit. Het is een gevolg van menselijk handelen – gewild of ongewild, en daarmee komen we op het raakvlak met technische schuld.
Essentiële complexiteit heeft intrinsiek te maken met waardecreatie en is in se dus onvermijdbaar. Als je hieraan raakt of deze (te veel) probeert in te perken, leidt dit vaak tot een vereenvoudiging en waardevermindering en dat wil je uiteraard vermijden. Het komt er dus op neer om vooral de toevallige complexiteit zo laag mogelijk te houden, net omdat ze geen enkele waarde toevoegt, in tegendeel.
Speel geen verstoppertje
Het klinkt misschien allemaal eenvoudig of vanzelfsprekend, maar dat is het zeker niet altijd. Softwareontwikkeling is vaak een complex gegeven. Het is daarom belangrijk om de toevallige complexiteit, en de technische schuld die deze doet ontstaan, transparant te maken en ze net zoals de essentiële complexiteit in kaart te brengen en tastbaar te maken voor alle stakeholders, dus ook de business.
Door ook de toevallige complexiteit systematisch in de product backlog op te nemen, creëer je die nodige transparantie. De backlog is trouwens een levend artefact dat zich perfect hiertoe leent. De product owner kan dan samen met het ontwikkelteam en in samenspraak met de business beslissen welke technische schuld wanneer wordt aangepakt en welke (nog) niet. Dat moet een bewuste keuze zijn, wetende dat er technische schuld er is en dat je die, indien niet weggewerkt, zal meedragen naar de toekomst toe.
Een pareto-gewijze prioritering (kort gezegd, de gekende 80/20-regel) in functie van waardecreatie is daarbij een gezond principe. Want de volledige technische schuld tot nul herleiden is een illusie, mede ook door de ‘economie’ achter de feiten. Het niet wegwerken van een bepaalde schuld is trouwens ook een valabele keuze, zolang deze dus maar bewust gebeurt.