Technical debt

Wat is technical debt en hoe dit te herkennen en te voorkomen

Technical debt, je hebt er misschien nooit van gehoord maar de kans is groot dat je er mee te maken hebt. Technical debt of tech debt zijn de verborgen kosten van het nemen van shortcuts of het maken van compromissen in softwareontwikkeling om iets snel gedaan te krijgen, in plaats van het op de juiste manier te doen. Deze shortcuts kunnen leiden tot code die moeilijk te onderhouden is, gevoelig is voor bugs en inefficiënt is.

Blijf alert voor technical debt

Na verloop van tijd kan technical debt zich opstapelen, waardoor het steeds moeilijker wordt om wijzigingen of verbeteringen aan de software aan te brengen. Op den duur kan het zelfs zo erg worden dat er niet meer omheen te werken is en dat eigenlijk een compleet nieuwe applicatie schrijven een beter idee is. Dit lijkt een drastische oplossing, maar als de applicatie dusdanig verouderd is past hij misschien ook niet meer goed bij jouw bedrijfsprocessen. Het komt zelfs voor dat bedrijfsprocessen worden aangepast naar wat wel mogelijk is in de applicatie. En dat is juist het tegengestelde van wat je wil; jouw applicatie moet een verlengde zijn van jouw bedrijf en het moet de processen ondersteunen en niet anders om.

Soorten technical debt

Al met al is het een hele opgave om met technical debt om te gaan. Vaak zijn er in het verleden keuzes gemaakt die op dat moment goed leken, maar waar men nu tegen aanloopt of die jouw bedrijfsvoering nu tegenwerken.
Er zijn verschillende soorten technical debt, waaronder:

• Design debt: Dit is wanneer de architectuur of het ontwerp van de software niet goed is gepland, waardoor de code moeilijk te onderhouden of uit te breiden is.
• Code debt: Dit is wanneer de code van de software niet goed is geschreven en niet aan de standaarden voldoet, waardoor deze moeilijk te begrijpen en te wijzigen is.
• Testing debt: Dit is wanneer de software niet goed wordt getest, waardoor er bugs en fouten in de code achterblijven.
• Documentation debt: Dit is wanneer de documentatie van de software niet goed wordt bijgehouden, waardoor het moeilijk is om te begrijpen hoe de code werkt.

Alle bovenstaande varianten hebben veel met elkaar te maken, wanneer jouw applicatie last heeft van een van deze vormen zijn de andere waarschijnlijk ook aanwezig.

Herkennen van technical debt

Het herkennen van technical debt is de eerste stap en dat kan op verschillende manieren. Echter is het voor de eindgebruiker van de software vaak lastig om te herkennen.

• Code review: Code review is een proces waarbij een ontwikkelaar de code van een andere ontwikkelaar bekijkt en controleert op naleving van de standaarden, kwaliteit, enzovoort. Tijdens deze review kan er worden gezocht naar signalen van technische schuld, zoals complexe code, inconsistente naming conventions, redundante code en dergelijke.
• Code metrics: Er zijn verschillende tools beschikbaar om code metrics te meten, zoals cyclomatic complexity, code coverage en duplicatie van code. Een lage code coverage, hoge cyclomatische complexiteit of een hoge mate van duplicatie kunnen indicaties zijn van technische schuld.
• Bug reports: Als er veel bugrapporten zijn voor een bepaalde functie of module, kan dit duiden op technische schuld in de code.
• Performance problemen: Als de prestaties van de software slecht zijn, kan dit te wijten zijn aan technische schuld in de code, zoals inefficiënte algoritmen of slechte database-optimalisatie.

Het is belangrijk om regelmatig naar deze signalen te zoeken om zo de tech debt te identificeren en indien nodig aan te pakken. Dit kan helpen om de kosten op lange termijn te verminderen en de kwaliteit en het onderhoud van de software te verbeteren.

Oplossen van technical debt

Het oplossen van tech. debt. is per applicatie een puzzel op zich. Allereerst moet er gekeken worden naar de huidige staat van de applicatie, is deze nog "te redden" of is het eigenlijk geen vruchtbare situatie om hier nog in te investeren.
Indien gekozen wordt om wel door te gaan met de huidige applicatie is het belangrijk om kleine, losse stukjes van de applicatie te vernieuwen. Planning en prioriteiten stellen is een belangrijk onderdeel van de eerste stap. Dan het implementeren van nieuwe delen software is heel afhankelijk van hoe de situatie er uit ziet. Sommige applicaties lenen zich er goed voor om een "mouw" aan te passen zodat er makkelijk nieuwe delen geïmplementeerd kunnen worden. Andere applicaties gaat dit wat lastiger. Een belangrijk onderdeel van bijna elke applicatie is de database. Hierin staan alle belangrijke gegevens opgeslagen. Nieuwere technologieën gaan anders om met deze databases en zijn over het algemeen wel te koppelen aan databases van applicaties met technical debt. Echter is het vaak beter om naast de bestaande database tabellen een nieuwe database op te zetten voor de nieuwe gegevens.

Wil je graag eens sparren over technical debt of denk je dat jouw software te maken heeft met technical debt, neem gerust contact met mij op tim@teaminova.nl.