Als je in de software development zit, is de kans groot dat je te maken hebt gehad met technical debt: de ‘schuld’ die je opbouwt wanneer je geen of onvoldoende tijd investeert in ontwikkeling, architectuur en innovatie. Of: de opstapeling van al het coderen dat je morgen opnieuw moet doen omdat je gisteren een shortcut nam.
Een deel van bestaande codering opnieuw moeten doen, kost veel tijd. Van alle tests die gedaan moeten worden om te testen of de applicatie werkt, tot het begrijpen van de bestaande en ‘oude’ code die waarschijnlijk jaren geleden door verschillende mensen is geïmplementeerd. Een doolhof waardoor het zweet je uitbreekt. Maar wat nog belangrijker is, is de impact die deze shortcuts en de daardoor veroorzaakte tech debt hebben op bedrijven:
- Trager ontwikkeltempo: wanneer je een grote hoeveelheid tech debt hebt, vereist elke verandering die je in een app aanbrengt, het wijzigen van code op veel verschillende plaatsen.
- Behoefte aan meer ontwikkelingsexpertise: een complexe app met slechte architectuur vereist meer deskundige ontwikkelaars om die problemen aan te pakken en de app efficiënter te maken. En we weten allemaal hoe moeilijk het tegenwoordig is om deze te vinden.
- Verhoogde IT-achterstand: verzoeken van bedrijven blijven zich opstapelen omdat ontwikkelteams de vraag niet aankunnen, wat invloed heeft op de flexibiliteit van bedrijven om waarde te leveren, voortdurend te innoveren en concurrerend te blijven.
- Verhoogde veiligheidsrisico’s: de kortere wegen die worden bewandeld om de time-to-market te halen, kunnen veiligheidsrisico’s met zich meebrengen.
Dus, als technical debt zo slecht is, moeten we er dan niet naar streven om het volledig te elimineren? En is het, nu bedrijven onder druk staan om nieuwe digitale producten sneller dan ooit op te leveren, wel mogelijk om zonder deze schuld te leven?
Waarom is het zo moeilijk om schuldenvrij te zijn?
Laten we beginnen met het beantwoorden van het eerste deel van de vraag: het elimineren van tech debt is moeilijk te bereiken. Tech debt gaat niet alleen over het introduceren van slechte code en het overslaan van best practises voor ontwikkeling van een snellere go-to-market. Het probleem is dat er onbeheersbare interne en externe factoren zijn die leiden tot een verhoogde schuld. Factoren als:
- Gebrek aan expertise in het team.
- Gebrek aan details en veel last-minute wijzigingen: vaak hebben ontwikkelaars geen volledig beeld van wat er nodig of vereist is.
- Gebrek aan documentatie en kennisoverdracht: ontwikkelteams slaan het schrijven van documentatie over om een project te versnellen, denkend dat ze er in de toekomst wel zullen zijn om de documentatie te onderhouden. Dit is vaak niet het geval. De teams die de documentatie uiteindelijk moeten bijhouden en ontwikkelen, hebben daardoor geen toegang tot de hele context.
- Gebrek aan visie: teams denken bij ontwikkelingen niet aan de toekomstige evolutie. Dit heeft invloed op de ontwerpen en in hoeverre deze kunnen voldoen aan de toekomstige vereisten.
- Onvoorspelbare marktveranderingen: technical debt is ook een gevolg van de tumultueuze markt waar we ons niet op kunnen voorbereiden.
De meeste van deze factoren zijn onmogelijk te voorspellen en daarmee dus onmogelijk te plannen. Dus om de vraag “moeten we streven naar zero tech debt?” te beantwoorden, kunnen we kort zijn: nee. Technical debt brengt de wendbaarheid van een bedrijf en het vermogen om te reageren op de druk van de markt in gevaar. Dat is waar. Maar het is onmogelijk om het volledig te elimineren. De vraag is dus niet hoe je technical debt kunt elimineren, maar hoe je er controle over kunt krijgen, zodat je kunt blijven inspelen op de vraag en de urgentie van het bedrijf.
Tips om technical debt te beheersen
De beste optie is om het bestaan van de tech debt te erkennen en het onder controle te houden. Dit stelt ontwikkelteams in staat om sneller te produceren, terwijl de risico’s beheerst blijven. Er zijn een paar dingen die teams kunnen doen:
- Bepaal met welk niveau van tech debt ze zich comfortabel voelen, dat biedt de nodige wendbaarheid om te voldoen aan de eisen van de business.
- Beoordeel het risico van het tijdelijk behouden van wat tech debt om de time-to-market aan te kunnen.
- Beoordeel hoe impactvol en moeilijk het zal zijn om er later mee om te gaan door de juiste vragen te stellen. Zoals: “Heeft het gevolgen voor partners van systemen van derden die API’s van mijn systeem gebruiken?”
Een andere tip is om ontwikkelplatforms te gebruiken die al de nodige tools bevatten om je vanaf dag één te helpen bij het beheren van technical debt.
Wil je meer horen over dit onderwerp? Overweeg dan te luisteren naar de interactieve discussie met professor Rick Kazman, auteur van het onlangs verschenen MIT Press boek “Technical Debt in Practice: How to Find it and Fix It.“
Dit is een ingezonden bijdrage van OutSystems. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.