Development

Software-ontwikkeling
probleem

Zo bereken je 'technical debt' van software

De ontwikkelkeuzes uit het verleden leiden regelmatig tot onvoorspelbaar gedrag.

© CC BY 2.0 - Flickr Steve Collis
13 april 2018

De ontwikkelkeuzes uit het verleden leiden regelmatig tot onvoorspelbaar gedrag.

Technical debt is de verzamelnaam voor het vervelende probleem dat voortbouwen op bestaande code een riskante zaak kan zijn. Probleem netjes oplossen kan veel tijd en dus geld kosten. Dekken de baten in dat geval wel de kosten?

Het achterliggend probleem van technical debt is vaak de druk op developers om snel, werkende code af te leveren omdat de lijnmanagers jagen op een snelle 'time to market'. Dat probleem neemt alleen maar toe. In de haast aan de vraag van de opdrachtgevers tegemoet te komen, worden ontwerpbeslissingen genomen die voor het moment werken, maar later bijvoorbeeld bij opschalen of uitbreiden tot problemen leiden, bijvoorbeeld voor de prestaties van de toepassing.

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.

Lees meer over
Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.