ITU-forsker: Overfokus på nye platforme og sprog giver os skrøbelige systemer

Lysten til altid at arbejde med det nyeste it betyder, at legacy-systemer underprioriteres, advarer adjunkt på ITU.

»Inden for softwarefeltet har man ikke tendens til at se fortiden som værdifuld – og hvorfor skulle man også kode på samme måde, som man gjorde i 90’erne? Sammen med presset for konstant at levere nyudviklinger betyder det, at man glemmer, hvordan man vedligeholder legacy-systemer, altså it-systemer, der blev kodet for lang tid siden.«

Den kritik kommer fra adjunkt Marisa Cohn, ITU, der har studeret fænomenet gamle systemer ud fra et kulturelt og organisatorisk perspektiv, frem for et teknisk, ved at udnytte etnografiske metoder, hvor hun udfører feltarbejde ude i tekniske teams, tilbringer tid i software-faglige netværk og udføre kvalitative interviews med ingeniører om deres arbejde.

En negativ konsekvens af det konstante fokus på nyt, er, at systemerne bliver mindre robuste, fordi opmærksomheden eller hypen omkring en bestemt teknologi har det med at forsvinde hurtigt igen.

Læs også: Topdanmark pensionerer 30 år gammelt PL/1-system: »Vi skal skifte, før det bliver et problem«

Kompetencerne til at holde systemerne i luften fader ud:

»Og det er derfor for eksempel ikke ønskværdigt, at et it-system på et hospital kører på det nyeste sprog eller platform,« siger hun.

Men mange unge programmører er mere interesserede i at arbejde med de nyeste platforme og programmeringssprog, og de bliver ikke samme sted særligt længde, siger hun og forklarer hvorfor:

»Det er hårdt arbejde at trawle igennem gammel software. Men hvis softwaren altid skal være helt ny, ender man med at skære historien og relationen til brugerne fra,« siger hun.

Presset på at arbejde på den seneste platform eller programmeringssprog er udbredt inden for alle grene af softwareudvikling og er mindre bundet til krav fra bestemte domæner.

Undersøgelser, bl.a. fra midten af 90'erne, har vist, at tendensen kom med dot-com-boomet, hvor et nyt paradigme indebar, at softwareprogrammører i høj grad bliver iværksættere, der investerer i egen individuel arbejdskraftudvikling og dermed nogle gange på bekostning af de ressourcer, der er til rådighed i teknologivirksomheder.

Socioteknisk hukommelsestab kan være dyrt

Ud over at nye systemer kan ende som døgnfluer, så kan nyhedsfokusset betyde, at man glemmer, hvordan man vedligeholder legacy-systemerne, og det er et problem.

»Man forsømmer betydningen af ældre systemer, og vi undervurderer de færdigheder, der er nødvendige for at vedligeholde og sikre et generationsskifte, da it-systemer udvikler sig over lang tid,« siger Marisa Cohn.

Der sker altså ikke nødvendigvis en egentlig forsømmelse af systemerne i sig selv. Det handle mere om, at nogle af de færdigheder, der skal til for at opretholde ældre systemer, kan blive glemt. Situationen betyder bl.a., at man er nødt til at indkalde pensionerede programmører til at vedligeholde legacy-systemer.

Læs også: COOP giver 40 år gammel legacy-kode øksen: Må indkalde pensionister til support

»Det er ikke for at sige, at vi skal være nostalgiske om eksisterende systemer, der ikke fungerer eller opfylder nutidens behov, men at vi bør være på vagt over for et socioteknisk hukommelsestab - for at glemme den organisatoriske og kulturelle viden, der er viklet ind med ældre systemer,« siger hun.

I nogle tilfælde skal man selvfølgelig implementere et nyt system, men ældre systemer kan stadig være rumme værdifulde historiske oplysninger.

»Jeg har set i forskellige sammenhænge, at nye it-systemer er ved at blive indført, hvor der er mere opmærksomhed på de funktioner, der vil blive tilføjet, og mindre opmærksomhed på dem, der vil blive tabt,« lyder det fra ITU-adjunkten.

Med andre ord kan ændringer i kode gribe forstyrrende ind i organisationskulturer og struktur.

Det betyder, at vi skal være mere interesserede i at arbejdet med software-vedligehold. Men kvalifikationer og viden herfra er også uvurderlig for implementeringen af nyere systemer.

Det gælder f.eks. inden for rumforskning, hvor software ofte er nedarvet fra generation til generation, fordi sattellitterne bruges i mange år til at studere naturfænomener.

Lær af rumforskningens it-teams

Eksempelvis flyver Orbiter-robotter rundt i det ydre rum i over et årti, og de kører på nogle af de ældste programmeringssprog.

»Men kunne lære meget af deres vedligeholdsteam og deres evne til forsigtigt at tune og opdatere gamle systemer,« lyder det fra Marisa Cohn.

Andre sektorer, som adskiller sig fra tendensen, og hvor man sætter større pris på legacy-software, er eksempelvis i det offentlige, på hospitaler, i banker og i skoler.

Militæret er også et eksempel - det amerikanske atomprogram kører f.eks. stadig på floppy-disketter.

Læs også: Amerikansk forsvar bruger stadig disketter

»Jeg tror, vi først bliver opmærksomme på legacy-systemer nu, fordi den første generation af udviklere er ved at gå på pension,« siger hun.

Blandt andet skal man holde op med at bruge legacy som et skældsord.

For vi kan lære meget fra specialister, der arbejder med at bevare ældre systemer, siger hun.

»Jeg ser det som et kollektivt ansvar at sikre, at vi implementerer og vedligeholder systemer med en lang levetid. Selv den nyeste mode i softwaremanagement bliver ældre. Så ud over at skabe mere vedligeholdelsesvenlig og evolverbare softwaresystemer bør vi også værdsætte det arbejde, som er nødvendig for at opretholde den organisatoriske og kulturelle viden, der er en del af it-systemer på lang sigt.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Allan Ebdrup Blogger

Når du opbygger dit system som microservices med en maksimal størrelse, så de kan genskrives på 2-4 uger. Så kan har du ihvertfald muligheden for at genskrive en hel service når den er legacy. Specielt nemt er det når du kan genbruge de automatiserede integrationstests du har lavet.
Det er et trick vi har brugt flere gange, at genskrive en hel microservice fra bunden, selv om vores ældste legacy systemer kun er 5 år gamle fra da vi startede.
Det vil jeg hellere vælge end at skulle vidreudvikle på 20 år gamle systemer om 15 år.

  • 3
  • 4
Henrik Dalsager

At skyde skylden på de unge programmører er simpelthen for nemt. Jeg har godt nok kun prøvet at overtage legacy kode 3 gange i større virksomheder, men det er min klare oplevelse at pilen peger på de manglende dokumentationer.

Når man arver 20-30 år gammel software uden kravspecifikationer, eller bare en oversigt over features, opdager man tit 2 ting.

Globale variabler var en gang løsningsmodellen for alle problemer.

Alt kode går med tiden mod fuld entropi.

Så min erfaring er at det kan tage årevis ar forstå koden godt nok til at man kan vedligeholde den uden at man skaber for mange nye bugs.

Tid som ledelsen tit ikke forstår de skal betale for, de får jo intet for de penge udover oplæring..

Så jeg er helt enig i at god segmentering af kode eller mikro services er vejen frem, hvis og kun hvis de gamle systemers kravspecifikationer er tilstede og opdaterede.
(Igen noget som ledelsen tit glemmer tager tid og koster penge)

  • 7
  • 0
Troels Henriksen

Når du opbygger dit system som microservices med en maksimal størrelse, så de kan genskrives på 2-4 uger. Så kan har du ihvertfald muligheden for at genskrive en hel service når den er legacy. Specielt nemt er det når du kan genbruge de automatiserede integrationstests du har lavet.

Hvordan laver du en oversætter som en microservice? Hvad et RDBMS? Styringsprogrammet til en rumsonde? Systemer med realtime-krav i almindelighed? Højtoptimerede programmer (f.eks. fysiske modeller) hvor det på ingen måde kan lade sig gøre at tune dem tilstrækkeligt på 2-4 uger?

Det er klart at man er nødt til at bygge sine systemer med henblik på fremtidig vedligeholdelse, men microservices fungerer kun til ganske bestemte typer af arkitekturer.

Jeg tror problemet med vedligehold er at intet program er "legacy" når det bliver skrevet, og derfor ikke bliver designet til at skulle vedligeholdes. Derudover:

Alt kode går med tiden mod fuld entropi.

Det er der nok noget deprimerende sandt i.

  • 4
  • 1
Allan Ebdrup Blogger

Hvordan laver du en oversætter som en microservice?


Vi bruger off the shelf oversættere.

Hvad et RDBMS?


Det bruger vi ikke, men hvis jeg skulle ville jeg købe en off the shelf.

Styringsprogrammet til en rumsonde? Systemer med realtime-krav i almindelighed? Højtoptimerede programmer (f.eks. fysiske modeller) hvor det på ingen måde kan lade sig gøre at tune dem tilstrækkeligt på 2-4 uger?

Sådan nogle bygger vi ikke.

Det er klart at man er nødt til at bygge sine systemer med henblik på fremtidig vedligeholdelse, men microservices fungerer kun til ganske bestemte typer af arkitekturer.

Ja, det er rigtigt. Til de systemer der kan bygges med micro-services er det vores erfaring at det virker godt. Det var egentlig det jeg gerne ville dele. Microservices vil virke til temmeligt mange systemer i verden, og det er dem jeg snakker om.

Til de andre systemer (disclaimer: som jeg ikke har prøvet at bygge, så dette er gæt-værk) ville jeg højst sandsynligt prøve at modularisere på andre måder, der lader dig omskrive systemet i dele. Det gør vi faktisk også ved siden af microservices, med små, single purpose node moduler. Her har vi flere gange skiftet node moduler ud, enten med en bedre FOSS version, eller vi har omskrevet en af vores egne moduler fra grunden.

Mit grundprincip er, at i stedet for at gå efter at vidreudvikle på samme system i mange år, som blogindlæget taler om, vil vi i stedet planlægge efter at systemet kan genskrives og moderniseres løbende. Vi har fx microservices der er blevet genskrevet fra bunden 3 gange, fordi vi hele tiden lærer og bliver klogere.

Jeg er ikke parat til at kaste håndklædet i ringen og konkludere at: alt kode går med tiden mod fuld entropi. Jeg er med på, at det er meget svært at lave store vedligeholdesesvenlige systemer. Men jeg tror godt at det kan lade sig gøre. Og har også hørt om at sådan nogle systemer eksisterer.

Jeg tror det ofte går galt, at mange forretninger nedprioterer refactoring og vedligehold af deres kodebaser, her taler jeg som en biks hvor vi bygger et produkt der skal holde i mange år. Jeg er med på at det er anderledes med one-off projekter. Og jeg er helt med på at det kan være en luksus at virkeligt kæle for din kodebase. Det er der ikke tid til hvis du ikke har nok kunder endnu. Men jeg har også set sunde store forretninger med ressoucer, der aldrig får taget fat om nældens rod og gjort noget ved systemer, der er en daglig smerte for dem der arbejder med dem. Jeg har set flere gange, at det kan være så slemt at man mister gode medarbejdere på det.

Slag på tasken vil jeg tro at 20-50% af vores udviklingstid går med konstant at refaktorere og rydde op i gammel kode. Der er høj prestige i at rydde op på teamet. Commits der fjerner mange flere kodelinjer end de tilføjer får klapsalver. Det gør at de andre 50-80% af tiden bevæger vi os hurtigt og kan blive ved med det i mange år endnu.

Det er min erfaring at udviklere også har det bedre, når de får lov til at rydde op i noget de synes burde ryddes op, noget kode der er frustrerende, langsomt og error-prone at arbejde med. Her er der selvfølgelig tale om en balancegang der skal findes, for der skal også leveres forretningsværdi. Det vi går efter er, at vi generelt er stolte af vores kode og hvor simpel den er.

  • 7
  • 1
Ole Tange Blogger

Nye sprog gør ofte ting nemmere, og hvis der er gode biblioteker, så kan det også gøre koden bedre (f.eks. ved automatisk at sikre mod buffer overflows eller give adgang til gennemtestede krypteringsfunktioner).

Så jeg er nok som udgangspunkt fortaler for at smide legacy kode ud.

I nogle tilfælde skal man selvfølgelig implementere et nyt system, men ældre systemer kan stadig være rumme værdifulde historiske oplysninger.

Her mener jeg, at automatisk testing er den mest værdifulde del. Hvis testene er veldokumenterede (hvorfor tester vi det som vi tester?) og automatiserede, så gør det det langt nemmere at skifte sprog: Hvis den nye version består alle tests, så bør koden være en drop-in-replacement.

Men det stiller naturligvis nogle krav til, at man får lavet denne automatiserede testing. I GNU Parallel har jeg gjort det til en hovedregel, at jeg ikke retter en bug, før jeg har en test, der fremprovokerer fejlen.

  • 4
  • 0
Jacob Volstrup

Men hvad så med de komponenter som ikke umiddelbart lader sig teste automatisk?
Det er så let altid at sige automatiseret testing, men i min verden tyder det på at man ser meget ensporet på softwareudvikling.
Og man glemmer også gerne de scenarier hvor man skal holde et system kørende uden eksisterende automatiserede tests - men så er det selvfølgelig så let bare at smide legacy ud, for hvem vil ikke gerne bruge måske 20.000+ timer på nyudvikling?

  • 4
  • 0
Log ind eller Opret konto for at kommentere