I Version2's artikel-serie om modernisering kontra nyudvikling har vi ofte brugt begrebet 'teknisk gæld' uden at have en klar definition af, hvad teknisk gæld er, og hvordan man egentlig kan opgøre mængden af teknisk gæld i et system.
Bevares, vi har henvist til både Howard Cunninghams og Martin Fowlers beskrivelse af begrebet, men hvordan finder man ud af, hvor stor den tekniske gæld er i et givent system?
Principper for god kode
Hos Kombit har man siden december 2018 været i gang med at finde svaret på det spørgsmål.
Kommunernes it-fællesskab anvender nemlig et system, der analyserer kodekvaliteten i it-systemer.
Hvis kvaliteten af koden er lav, vil den tekniske gæld være stor.
Det er Software Improvement Groups Sigrid-platform, som Kombit de seneste otte måneder har anvendt til at måle softwarekvaliteten i 14 systemer udviklet af leverandører til Kombit.
»Vi indkøber store it-systemer til anvendelse i kommunerne, og sommetider kan der være problemer med softwarekvaliteten. Vi ønskede et værktøj, der kunne give os et indblik i, hvad det er, leverandørerne leverer,« fortæller Jan Dynnesen, it-arkitekt hos Kombit.
Sigrid analyserer et systems kildekode ud fra otte faktorer, som baserer sig på veletablerede principper for god kode.
Metoder/funktioner bør eksempelvis ikke være længere end 15 linjer, metoder/funktioner bør ikke være for komplekse, og softwarearkitekturen bør bestå af løst koblede komponenter (se boksen ’Gode koderåd’ for en liste over principper for god softwarekvalitet).
På baggrund af kodeanalysen udregnes en score, og systemets overordnede kodekvalitet tildeles en stjernemarkering, hvor 1 stjerne tildeles systemer med lavest kodekvalitet, og 5 stjerner systemer med den bedste kvalitet i koden.
Transparens og dialog
Jan Dynnesen understreger, at kvalitetsmålingerne ikke skal bruges til at slå leverandørerne i hovedet, men skal være med til at skabe en dialog om projekternes fremdrift og prioritering.
»Kvalitetsscoren bliver brugt som udgangspunkt for en konstruktiv dialog og en måde at få mere transparens om softwarekvalitet på. Det kan bruges sammen med leverandøren til at prioritere udviklingen. Hvis en leverandør leverer dårlig softwarekvalitet, er det ikke nødvendigvis leverandørens skyld,« siger Dynnesen og fortsætter:
»Vi kan måske have en masse ændringskrav, processer, der forhindrer leverandøren i at levere det optimale, meget rigide dokumentationskrav og andet, der begrænser udviklernes produktivitet. Det er vigtigt for os at vide, så vi kan adressere eventuelle problemer vi har hos os selv.«
Modtagelsen af kvalitetsmålingerne blandt leverandørerne har været blandet.
»Nogle leverandører har været meget positive, andre har været negative, og nogle har været neutrale – de anvender ofte selv lignende værktøjer til at måle softwarekvalitet,« siger Jan Dynnesen.
Kan softwarekvalitet måles?
Nogle af leverandørernes udviklere har stillet spørgsmål til, om alt vedrørende softwarekvalitet kan måles, og om kriterierne for god kode også er rimelige.
»De fleste godtager kriterierne, men nogle brokker sig eksempelvis over, hvor mange linjer en metode højst bør have. Der er også dem, der siger, at softwarekvalitet består af andre ting end dem, vi måler. Det kan være korrekt brug af design patterns, den rigtige anvendelse af en given teknologi og lignende. Det er sandt, men vi har brug for en objektiv måde at måle på, og det her er den bedste, vi har,« siger Jan Dynnesen.
En konsistent kodeevaluering
En veldefineret og konsistent måling af softwarekvaliteten er vigtig for Kombit.
»Vi har prøvet at have en tredjepart inde og vurdere kodekvalitet, men det var en subjektiv evaluering, så det kunne altid diskuteres. Hvis en tredjeparts-kodeekspert vurderede, at koden ikke var af høj kvalitet, så kunne leverandøren argumentere for det modsatte. Med de otte objektive kriterier er der ingen diskussion. Du får altid den samme score for den samme kildekode. Du kan selvfølgelig altid diskutere, om kriterierne er retfærdige, men da de er baseret på veletablerede principper for god kode, så er det svært at argumentere for, at en lav score betyder, at din kode har en høj kvalitet,« forklarer Jan Dynnesen.
De 14 systemer, der for tiden monitoreres, er skrevet i C#, Java og en enkelt i ABAP, som er sproget i SAP-løsninger.
Over 4.000 systemer som reference
Det giver kvalitets-scoren pondus, at scoren sammenholdes med en benchmark, der er etableret på baggrund af kodeanalyser for kørende systemer verden over.
Senior Management Consultant hos Software Improvement Group Nordic Rasmus Petersen forklarer:
»Vi har indsamlet data fra over 4.000 systemer verden over. og vi bruger en delmængde af dem til at etablere en benchmark.«
Software Improvement Group inddrager kun data til benchmarken fra systemer, der stadig er i drift.
5 procent af systemerne rangeres lavest med 1 stjerne, mens 5 procent får den bedste rangering med 5 stjerner. De resterende rangeringer med 2, 3, og 4 stjerner udgør hver især 30 procent.
Ifølge Software Improvement Group er det dobbelt så hurtigt at lave ændringer og udvidelser i systemer med en firestjernet kodekvalitet som i systemer med en tostjernet kvalitet.
Hvert år bliver benchmarken justeret efter de seneste målinger, og der sker som regel en lille forbedring.
I bogen ’Building Maintainable Software’ af Joost Visser fra Software Improvement Group hedder det om de årlige benchmarkændringer: »Det er ikke de store ændringer. Overordnet set er det en tiendedel af en stjerne per år.«
Den lille kvalitetsstigning betyder, at kravene til stjernemarkeringerne også langsomt strammes, så det eksempelvis bliver lidt sværere at opnå et 4-stjernet kvalitetsstempel.
Softwarekvalitet verden over
Benchmark-målingerne kan ses som en indikator for softwarekvaliteten globalt set, dog mest i store organisationer og virksomheder, da det oftest er den type virksomheder, der anvender Software Improvement Groups kodeanalyse.
I bogen ’Building Maintainable Software’ fra 2015 hedder det om softwarekvalitet:
»Hos SIG (Software Improvement Group, red.) har vi set systemer, som basalt set ikke er til at vedligeholde. I de systemer bliver bugs ikke rettet og funktionaliteten ikke ændret eller udvidet, fordi det tager for meget tid og er for risikabelt. Desværre er det noget, som ses alt for tit i dagens it-industri, men det behøves ikke at være sådan.«
Hvis der kun sker små gradvise ændringer er det vel også tilfældet i dag?
»Ja, jeg er ked af at sige det, men situationen er stadig den samme. Dog er høj softwarekvalitet begyndt at blive et successkriterium, som softwarekøbere lægger vægt på, og i fremtiden vil højkvalitetssoftware med lave vedligeholdelsesomkostninger blive en nøglekonkurrenceparameter,« vurderer Rasmus Petersen.
Hvad koster vedligehold fremover?
Software Improvement Groups værktøjer kan estimere de totale vedligeholdelsesomkostninger fremover på baggrund af systemets kodetilstand sammenlignet med virksomhedens benchmark fra andre projekter.
Der udregnes en Total Cost of Ownership (TCO) med konkrete tal på, hvad det vil koste at refaktorere og vedligeholde et eksisterende system. På den baggrund kan man vurdere, om der skal bygges nyt, eller om man skal videreudvikle det gamle system.
Hverken Kombit eller Software Improvement Group ønsker at udtale sig om nuværende eller tidligere projekters kodekvalitet, men Version2 har før berettet om, hvordan Software Improvement Group betegnede Domstolsstyrelsens Juridiske Fagsystemer som et meget komplekst system, der ikke burde sættes i drift grundet forventede store TCO-omkostninger..
Når projekter ikke lytter
Version2 har også tidligere rapporteret om Software Improvement Groups kvalitetstjek af koden til Skats skandaleramte EFI-system. Et kvalitetstjek, som blev ignoreret:
»Kvalitetssikring af koden har ingen effekt. SIG, som på ugentlig basis maskinelt kvalitetssikrer den udarbejdede programmeringskode med rapportering til leverandørerne, melder om et voksende antal brud på retningslinjerne for programmering foretaget af KMD og CSC. Men begge leverandører har gennem længere tid ignoreret de ugentlige rapporter fra SIG, som blot kasseres uden læsning,« som Version2 kunne fortælle i 2016 på baggrund af en aktindsigt i en rapport fra PA Consulting.
Skat accepterede, at leverandørerne skulle ignorere kvalitetstjekket af koden. Af rapporten fremgik det videre:
»CSC og deres underleverandører er principielt uenige med SIG omkring anvendeligheden af SIG's værktøjer og analyser, hvorfor dialogen parterne imellem er ophørt, og CSC har fra Skat fået accept af dette.«
Proaktivt vedligehold
I de seneste tre-fire år har Kombit anvendt Software Improvement Group og andre uafhængige eksperter til enkeltstående reviews af projekter, men det er først de seneste otte måneder, at Kombit er begyndt at anvende kvalitetstjekket mere proaktivt, idet Jan Dynnesen og hans kollegaer sammen med leverandørerne løbende kan følge med i kodekvalitetens udvikling.
»Her er det mere proaktivt, da vi monitorerer koden fra uge til uge og identificerer trends, så hvis et projekt af en eller anden årsag begynder at få dårlig kodekvalitet, så kan vi gøre noget ved det, inden det bliver et problem,« siger Jan Dynnesen.
Igen understreger han, at leverandørerne ikke skal se monitoreringen af kodekvalitet som noget negativt:
»Vi holder kurser for leverandørerne, hvor de bliver undervist i, hvordan de kan bruge Sigrid-platformen i deres dialog med os. De kan dokumentere en korrekt leverance, høj kodekvalitet og dokumentere, at de arbejder på ting, som vi har bedt dem om. Hvis vi eksempelvis har bedt om en ændring, der bliver dyrere, end vi havde regnet med, så kan de dokumentere, at koden, som skulle ændres, måske var meget kompleks og derfor tog ekstra lang tid at ændre,« siger Jan Dynnesen.
Udviklerproduktivitet og TCO
Systemet giver også mulighed for at estimere udviklerproduktivitet, ligesom det giver mulighed for Kombit at prioritere ressourcer på tværs af projekter i Kombits portefølje.
»Vi har et råt estimat for, hvor mange kodelinjer en udvikler kan skrive om dagen, baseret på data fra flere tusinde projekter. Det kan bruges til at udregne udviklingstiden for et system i mandår. Vi kan sammenligne systemerne med hinanden og prioritere udviklingen af systemerne,« siger Dynnesen og fortsætter:
»Projektejerne kan lave budgetestimering baseret på TCO for et projekt samt for hele projektporteføljen for de næste ti år. Det er en god ting ved projektudbud.«
