Enhver form for software har en begrænset levetid. Selvom denne udløbsdato ikke nødvendigvis er synlig som en stempel på dagligvarer, findes den et sted under overfladen. Uanset om det drejer sig om et programmeringssprog,
et framework, et bibliotek, et operativsystem eller en cloud-baseret dynamisk platform, så har de alle en udløbsdato.
Selv Voyager-sondernes kodebase har en udløbsdato. Dette kan skyldes enten den enorme afstand, der
gør det umuligt at opdatere koden, eller manglen på kvalificeret arbejdskraft, der kan arbejde inden for de givne begrænsninger. Link til Voyager artiklen i Popular Mechanics.
Selvom vi ikke kan se disse udløbsdatoer, så er deres påvirkning ikke statisk. De intensiveres over tid, hvilket er grunden til, at udtrykket"
brændende platform" er mere passende. Det begynder som en ulmende brand i et hjørne, og hvis det ikke håndteres aktivt, udvikler det sig voldsomt, indtil det bliver uoverskueligt.
Java som et eksempel
Når vi ser på Java, går det nu over til at have en Long Term Support (LTS) version hvert andet år. Hvis man undlader at opdatere sin software regelmæssigt, risikerer man at stå over for en enorm opdatering, der kræver
en stor indsats for at undgå problemer. De versioner, man springer over, kan betragtes som ankre, der bliver tilføjet til ens software. Begrebet teknisk gæld bruges ofte til at beskrive denne form for forsømmelse, selvom
det normalt er ens egne valg, der sænker udviklingstakten for ens softwareportefølje.
Technical debt eller Friction
For nylig har Kent Beck blogget om, at begrebet "Technical Debt" måske er misvisende, da det oprindeligt var rettet mod folk med kendskab til gældshandel og ikke den almindelige befolkning. Beck foretrækker udtrykket "friction" og foreslår
også mislyd, disharmoni og træghed som alternative termer. Essensen er et ubehag, som man kan leve med i en kort periode, men det betyder også, at det er nødvendigt - ikke blot anbefales, men nødvendigt - at ændre
det til noget bedre. Dette kræver ressourcer: tid, penge, mennesker - uden umiddelbar synlig nytte. Det samme gælder for brandslukning eller rengøring, selvom folk typisk kan se en vis nyttig effekt i disse aktiviteter.
Vedligeholdelse af både udstyr og kode er af afgørende betydning.
Det giver mulighed for at opnå følgende fordele:
1. Hurtigere reaktion på nye sårbarheder: Vedligeholdelse muliggør hurtigere håndtering af nye sikkerhedsrisici og sårbarheder, da man kan
foretage nødvendige opdateringer og rettelser i tide.
2. Ansættelse af nye udviklere: Ved at opretholde opdateret teknologi og kodebase bliver det muligt at tiltrække og ansætte nye udviklere. Uddannelsesinstitutioner
har sjældent interesse i at uddanne folk i forældet teknologi, og derfor er det vigtigt at holde sig opdateret for at tiltrække kompetent arbejdskraft.
3. Brug af nyere frameworks og biblioteker for øget produktivitet:
Nyere versioner af frameworks og biblioteker kan bidrage til øget produktivitet. For eksempel kræver Spring version 6 (fra november 2022) mindst Java-version 17. Hibernate 6 (siden marts 2022) kræver Java 11 eller nyere, og version
6.0 er allerede blevet markeret som End of Life.
4. Fastholdelse af medarbejdere, der ønsker at følge med udviklingen: Vedligeholdelse af en moderne teknologi stack og en opdateret kodebase kan hjælpe med at fastholde
medarbejdere, der ønsker at udvikle sig og holde sig ajour med den teknologiske udvikling.
5. Skabe et bedre arbejdsmiljø. Skal man lave mad, er der er stor forskel på at skulle navigere mellem beskidt service i et rodet køkken, eller have et rent køkken med fri bordplads. På samme måde er det rart og
en bedre oplevelse at kunne arbejde med ren kode i et ryddeligt miljø uden cowboy hacks og manuelle processer.
Udfordringerne ved kun at scanne for sikkerhedsproblemer i byggeprocessen
Den applikation, der sidst blev bygget for 4 år siden, er en ukendt faktor, der sandsynligvis gemmer på nogle ubehageligheder, hvis man kun scanner for sikkerhedsproblemer i byggeprocessen. Kan applikationen overhovedet bygges? Og hvem har
egentlig kendskab til den? Er det måske den medarbejder, der forlod virksomheden for 2 år siden?
Det er unødvendigt at have begrænset indsigt i, hvor mange steder f.eks. Log4J anvendes i direkte eller afledt kode
(Unknown unknown). Opgraderingen af en LTS-version kan være besværlig og kræve flere mere eller mindre kaotiske "yak-shaving"-processer.
Hvis Javas nye LTS-kadence skal omskrives fra hvert tredje år til hvert andet år, vil det øge den tekniske gældsrente med 50% - eller blot tilføre mere brændstof til bålet. "It takes all the
running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!". Man fristes til at sige "IT takes ..."At hugge en hæl og klippe en tå kan måske få skoen
til at passe, men det er svært at konkurrere både i sprint og på den lange bane, hvis man har mishandlet sine fødder.
Andre Frameworks og fordelene ved opgradering
Java er et nemt bytte, fordi det er så udbredt. En større opgraderingsopgave ligger i at følge med tiden i Angular 2, som har en LTS hvert år - man kan så spørge sig selv, hvad det har med "long term" at gøre.
I
Java er det teoretisk muligt at springe fra version 8 til version 17, men i Angular er man nødt til at opgradere trinvist, f.eks. fra 10 til 11, fra 11 til 12 osv. Selvom der findes vejledninger til opgradering, kræver det en fuldstændig gennemgang, og der er ingen fordel ved at udskyde opgraderingen.
Det kan se let ud på papiret, men det handler om at opgradere, teste, foretage de nødvendige ændringer, gentage processen indtil testen er acceptabel, og så fortsætte til næste opgradering. Angular
kommer med en ny version hvert halve år. Version 16 kommer primo maj 2023, og det varsler samtidig end of life for version 13 LTS, der kom i november 2021.
Udnyttelse af nye funktioner ved opgradering
Når man opgraderer til en nyere version, handler det ikke kun om selve opgraderingen, men også om at drage fordel af de nye funktioner. Dette kan betyde, at man kan omskrive sin eksisterende kode til en mindre kodebase, hvilket normalt fører
til færre fejl og nemmere vedligeholdelse.
En af fordelene ved opgradering er, at man kan undvære visse libraries og frameworks. For eksempel løfter Java records noget af det arbejde, som tidligere blev udført
af IDE'ens automatiske generering af getter og setter. Dette blev også hjulpet af værktøjer som Lombok ved hjælp af annotations. Det betyder, at man ikke længere behøver at teste disse klasser individuelt for
at opnå en høj testdækning. Derudover kan man centralisere dokumentationen og undgå redundante beskrivelser af getter og setter for hvert enkelt felt.
Hibernate 6 har indbygget JSON-support, hvilket eliminerer behovet
for et tredjeparts library. Ved at anvende konstanter i stedet for tekst får man fejlmeddelelser fra IDE'en eller under kompileringen i stedet for først at opdage dem som runtime-fejl. Der er mange andre fordele afhængigt af ens
brug af Hibernate. Derfor er det forventeligt, at der kan afsættes tid til at udnytte de nye teknologier, når man alligevel er i gang med at opgradere.
Hvad gør vi fremadrettet?
Der er flere muligheder for at komme ovenpå - eller undgå, at det bliver værre, men det kræver et kulturskifte i virksomhederne - både for drift, udviklere, projektledere og ledelse. Det er svært, fordi mange af de
elementer, der har med software at gøre, er usynlige for de fleste og værdisætningen af en opgradering virker måske som en ubetydelig gevinst i forhold til omkostningen. Men som forsøgt at forklare ovenstående,
så er der mange facetter i spil. Hvor hurtigt kan en sårbarhed udbedres og hvad er prisen?
DevOps - Det vil kræve noget mere disciplin og en kontinuert proces, hvor kode bliver bygget jævnligt, især
hvis det er her, det er eneste sted man systematisk leder efter sårbarheder i afhængighederne.
SRE - En Software Reliability Engineer bør stille spørgsmålstegn ved forskellige applikationers
sårbarheder. Her vil det være nemmest at svare på nogle af disse spørgsmål, hvis man f.eks. ved, at man holder sig til nogle bestemte versioner af libraries og frameworks. En SRE burde så kunne svare, hvor stort
et problem f.eks. Log4j er for hele virksomheden. Hvilke applikationer, der først skal tages hånd om.
Standarder - build tools, CI/CD pipelines, versionsstyring (when to merge to main), dækkende testscenarier.
Faste versioner, kendte afhængigheder, hvornår er det godt at opgradere, hvilke fordele kan høstes.
Årshjul for opgraderinger - dvs. planlægning. Hvornår frigives et release - hvor lang tid skal man vente
på at børnesygdommene er rettet? Hvordan undgås karambolage med egne releases og tredje parts platform opgraderinger? Hvordan overdrages viden til dem, der ikke deltog i projekt A opgraderingen?
team trailblazer - som finder
ud af, hvilke udfordringer der skal overvindes og gevinster, der kan høstes ved næste opgradering.
Ledelsesmæssigt buy-in - hvis ledelsen ikke er med på kulturskiftet, så bliver det til mere
af det samme: flere cowboy hacks, mere teknisk gæld, flere paniske fejlrettelser, mere stress, mindre glæde.
Boy scout rule - Altså den gode regel om at efterlade koden i en lidt bedre version, end
du fandt den.
Application & Platform full stack monitoring - hvis man kører dette, så er der nogle af produkterne, der trækker værdifuld data ud af de kørende applikationer, så
man kan se hvilke kendte sikkerhedshuller, der optræder og om de er offentligt tilgængelige. Det kan hjælpe en med at sætte bedst muligt ind, og det kræver ikke at man bygger jævnligt for at opdage problemerne. Den
rigtige APM løsning gør den kørende software mere synlig.
Arbejder du på en brændende platform og mangler sparring på, hvordan du kommer videre, enten med opgradering af dit nuværende system eller gerne vil bygge et nyt, så kontakt os på +45
61 77 70 70 eller på mail: rasmus.halvor@soprasteria.com
Kontakt os
Læs mere
Change Management Testing af HBO Max Brugen af AI i økonomi Brugerdrevet Udvikling