Technical debt

Maak technische schuld zichtbaar, ook bij agile softwareontwikkeling

11 juni 2021

Application modernization

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.

Technical debt

Vermijd Babylonische spraakverwarring

Technische schuld draagt dan wel het label ‘technisch’, maar eigenlijk is het technische aspect slechts één van de redenen waarom technische schuld ontstaat. Het kan overal in het traject ontstaan, en vaak wordt het potentieel van technische schuld al gecreëerd voor de effectieve softwareontwikkeling, dus in de fasen ervoor.

Een belangrijke driver op strategisch niveau kan bijvoorbeeld zijn dat de business-strategie van een bedrijf niet goed is uitgeklaard zodat de IT-afdeling ook niet goed weet hoe ze hiermee moet omgaan of op moet anticiperen. Misschien zijn IT en strategie onvoldoende gealigneerd, waardoor er focus wordt gegeven aan de verkeerde IT-initiatieven.

Technische schuld is met andere woorden een end-to-endverantwoordelijkheid van zowel IT als business. En daar durft het schoentje wel eens wringen. IT kijkt traditioneel, en ook niet geheel onbegrijpelijk, vooral naar de oplossingsruimte, de software, en de business vooral naar de probleemruimte, datgene wat moet opgelost worden. Het is echter essentieel dat beide partijen de probleemruimte samen grondig verkennen en de bijbehorende essentiële complexiteit ervan voldoende bevatten vooraleer IT op een duurzame manier kan overgaan naar de oplossingsruimte. Dit wil niet zeggen dat er op voorhand uitgebreide studies dienen te gebeuren, maar dat er samen gewerkt wordt met de focus op deze complexiteit. Wat ook perfect kan in een Agile context.

Zowel business en IT moeten daarvoor enigszins uit hun comfortzone komen, waarbij een goede alignering zich pas kan manifesteren als beide partijen de moeite doen om een gemeenschappelijke, begrijpelijke taal te spreken en zich in een democratische setting van gelijkwaardigheid te begeven.

Het goede nieuws is… er zijn oplossingen

Door vooraf de juiste enablers te kiezen die de business en IT-alignering formaliseren. Domain Driven Design, met de cloud (microservices) als architecturale bouwsteen bijvoorbeeld. Domain Driven Design, DDD, is een ontwikkelaanpak waarbij business en IT vanuit de kern, het domeindenken, dichter bij elkaar worden gebracht door middel van een gemeenschappelijke taal, de zogenaamde ubiquitous language. Communicatie en samenwerking staan centraal en hebben als streefdoel de frictie tussen de stakeholders weg te halen en de agility te verhogen.

De focus ligt hierbij initieel op het probleem en pas later op de technische oplossing die voornamelijk als facilitator wordt gezien. Door de essentiële complexiteit voor iedereen behapbaar te maken, kan je grote stappen zetten in het verbeteren van de business agility van je organisatie. Tegelijkertijd kan dan ook de toevallige complexiteit beter geïdentificeerd worden en vermeden worden waar mogelijk. Doordat DDD de business als stakeholder bij de softwareontwikkeling betrekt, kan er sneller waarde worden gecreëerd en wordt de ruimte voor fouten verkleind. Net door hier expliciete aandacht aan te geven, wordt daarmee ook de kans op toevallige complexiteit tot een minimum beperkt. Mission accomplished, toch?

1 Frederick P. Brooks, 1987, “No silver Bullet - Essence and accident in software engineering”

Leg uw modernisatietraject niet alleen af

Wij staan voor u klaar om uw applicaties en IT workloads te transformeren en te optimaliseren op een manier die future proof is.  

Ontdek alle blogs
Lees meer

Schrijf je in en ontvang onze blogs in je mailbox