Zo bereken je 'technical debt' van software

In veel gevallen staat dan een andere ontwikkelaar dan degene die heeft gebouwd, voor het dillemma wanneer deze de code van de betreffende applicatie voor het eerst ziet. Als snel is duidelijk dat er veel verbetering mogelijk is. Maar verander je één ding, heeft het vaak gevolgen voor andere processen. De opdrachtgever wil ook graag optimale code hebben, maar wil vooraf weten hoeveel (tijd) dat gaat kosten en wat het oplevert. Maar hoe begin je aan die analyse?

Er zijn verschillende methoden om technical debt te meten, zegt Ipek Ozkayahoofd technische staf van het Software Engineering Institute van de Carnegie Mellon University tegen The Register. Eigenlijk zijn er drie hoofdcategorieën:

• code, waarbij het gaat om structuur en kwaliteit
• architectuur, dan draait het om besluiten gericht op quick wins ten koste van efficiëntere flexibele manieren om de software te bouwen.
• productie-omgeving. Het gereedschap dat het Devops-team gebruikt is allemaal software. Knelpunten daarin kunnen het hele proces van roll outs en de lifecycle van de software beïnvloeden.

Vanwege de brede problematiek van technical debt is het lastig tot een universele meetmethode te komen. Het komt er dus op aan eerst te analyseren waar de technical debt zit. Volgens Gartner zijn er zeven categorieën afgeleid uit de ISO 25010 standaard. Het gaat om betrouwbaarheid, veiligheid, bruikbaarheid, onderhoudbaarheid, portabiliteit, compatibiliteit en performance efficiency. Aan elk zitten verschillende kostenaspecten. Zo leveren problemen in de laatstgenoemde categorie hogere operationele kosten op. Een slechte gebruikersinterface (bruikbaarheid) verhoogt de bedrijfskosten door productiviteitsverlies en meer fouten. Hoewel de Gartners categorieën meer duidelijkheid bieden, verbindt de marktanalist er geen getallen aan.

De standaard voor geautomatiseerde analyse

Het Consortium for IT Software Quality (CISQ) hanteert ook een indeling in categorieën maar heeft daarbij de Automated Technical Debt Measure standard ontwikkeld. De opstellers maken verder onderscheid in hoofdkosten en 'rente'kosten. De eerste zijn kosten nodig om ernstige missers in codering of architectuurbeslissingen te repareren. De rentekosten zijn de steeds terugkerende IT-kosten die het niet oplossen van de problemen opleveren.

De twee vertalen zich in twee vormen van bedrijfsrisico's. Wat levert het op als je de beschikbare ontwikkelaars inzet voor het ontwikkelen van nieuwe functionaliteiten tegenover de voordelen die het oplossen van problemen oplevert?

Met betrekking tot de rentekosten gaat het om het risico van bedrijfscontinuïteit: Naar mate bedrijven steeds afhankelijker worden van IT, raken CEO's steeds vaker gefrustreerd doordat een ontwikkelaar ergens iets verkeerd heeft gedaan waardoor de systemen crashen en zij misschien wel een miljoen aan omzet kwijtraken. De CEO wordt in toenemende mate afgerekend op iets wat ze niet in de verste verte snappen.