San Francisco kæmper med 80’er-software

Illustration: San Diego Air & Space Museum Archives
Offentlige programmer kan ofte tage lang tid at skifte ud, og selv i high tech-storbyen San Francisco ved Silicon Valley, har de udfordringer med software, der er gammelt nok til at stemme, drikke og bekymre sig om sin pensionsopsparing

San Francisco ved Silicon Valley er nervecentret for en stor del af den amerikanske – og verdens – tech-industri. Alligevel kæmper de med software, som ikke kan betjenes med mus, ikke kan vise nok relevante informationer på et enkelt skærmbillede, og oprindeligt er skrevet i Cobol.

Det skriver forretningsmediet Bloomberg.

På ejendomsvurderingskontoret i San Francisco gør man brug af et program, der kører på IBM’s AS/400-platform fra starten af 1980’erne, hvor diske var floppy, og det var en nyskabelse, at de var kommet helt ned på 3,5-tommer.

Læs også: Derfor falder containeren ikke i vandet: 25 år gammel Maersk-software styrer placeringen

Indkøb af software kan være en politisk udfordring

Historien går igen på tværs af amerikanske byer, og det er ikke tilfældigt. Ifølge Bloomberg er det markant lettere for politikere, at opnå popularitet hos vælgerne ved at bruge penge på synlige infrastrukturprojekter som veje og broer, mens det politisk er mindre sexet at bruge penge på at opdatere gammel software.

Gammel software kan også blive hængene af andre årsager. For eksempel kan systemer være så kritiske og så gennemprøvede, at det betragtes som for dyrt, usikkert eller begge dele at skifte det ud.

Læs også: »Logikken i Cobol og mainframen giver mening for mig«

I San Francisco har man efter fire års kamp fået bevilliget 36 millioner dollar til ny software og hardware til ejendomsvurderinger, som blandt andet kan prioritere sager, hvor langsom en sagsbehandling kan blive dyr. Designkravene skal være udformede til sommer.

Arbejder du også med software, der er så gammel, at det ikke kan betjenes med mus - eller hvor skærmbilledet er uddateret? Og er det nødvendigvis et problem? Skriv gerne i debatten

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (14)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Christian Jørgensen

Det ville være rart hvis journalisten havde sat sig ind i, hvad en AS/400 var...

Den kom først på gaden i 1988, altså ikke først i firserne. Og den havde harddisk og brugte ikke disketter - man tog backup på tape. OS/400 var objekt orienteret med integreret database.

IBM gik i modsætning til andre op i "protection of investment" og sørgede for, at programmere kunne migreres til nyere hardware - uden kildekoden! Derfor kan software fra 80'erne køre den dag i dag - nu blot på 64-bit Power processor. Faktisk kan også software fra 70'erne gøre det, for programmer fra S/38 (forgængeren til AS/400) kunne migreres til AS/400 og dermed videre til i dag.

Se mere om IBM i på IBM Power server her:
https://en.m.wikipedia.org/wiki/IBM_i

Software er en ting - bruger interface er noget andet. Og i nogle situationer vil det være hurtigere og mere effektivt med et tekst baseret interface uden mus fremfor et grafisk interface med mus. Jeg tænker på regnskabs- og ordre kontorer, hvor brugerne indtaster transaktioner - der har jeg oplevet mange, som foretrækker det tekst baserede. Og jeg selv som system administrator foretrækker klart en kommandolinje fremfor et GUI interface.

Men selvfølgelig skal software vedligeholdes og fornys, ellers bliver det en klods om benet på virksomheden.

Thomas Toft

USA har store problemer med tusindevis af broer der er direkte farlige pga. misvedlighold og rigtig rigtig mange deres veje er i samme stand. Så det her må vidst være dagens joke:

Ifølge Bloomberg er det markant lettere for politikere, at opnå popularitet hos vælgerne ved at bruge penge på synlige infrastrukturprojekter som veje og broer

Simon Mikkelsen

For nogle år siden var jeg, med et højt profileret og politisk system, med til at erstatte et ældre administrativt system. Dette havde tekstinterface og man skulle benytte en masse kryptiske kommandoer og makroer for at gøre noget i det.

Det var en stejl indlæringskurve, men nogle tusinde folk havde lært det og var meget effektive. De tilhører en faggruppe hvor de færreste ville tænke, at de kunne finde på at bruge sådan noget.

Systemet som sådan virkede godt og havde gjort det i rigtig mange år. Man erstattede en masse mindre fagsystemer med ét stort.

Hvis der hvade været tid til det, ville vi gerne have lavet en emmulator af dette system, så man kunne gøre visse ting hurtigere, men det var der ikke. Folk er skam også ganske glade for vores nye system i dag.

Som udviklere bruger de fleste af os vel også kommandolinie dagligt. Det er meget hurtigere at lave et script til kommandolinien end at skulle til at lave grafisk brugergrænseflade og kommandoer kan kombineres.

Et system til veluddannede eksperter må gerne være kompliceret til fordel for overblik og fleksibilitet.

Denny Christensen

At noget er tekstbaseret og kører COBOL er ikke gode argumenter for at lave et hypermoderne system med den nyeste teknologi - formålet med systemudvikling er sjældent at lave det mest teknisk fantastiske system men snarere at lave en løsning der effektivt understøtter slutbrugeren.

At mange systemer så er overdesignede er så en anden sag - her hjælper de agile metoder (brugt korrekt) og stram budgetstyring med til at sikre at der ikke laves mere IT end nødvendigt og at løsningen understøtter de nødvendige krav på en nem og intuitiv måde.

Bjarke Jensen

At noget er tekstbaseret og kører COBOL er ikke gode argumenter for at lave et hypermoderne system med den nyeste teknologi


I en verden hvor størstedelen af de der tager beslutningerne kun kan finde ud af at bruge iPads, og forsyner børn fra vuggestuealderene med 1-finger brugerflader ender vi snart med (hvis vi ikke er der allerede) en generation af IT-forbrugere der løber skrigende væk, hvis de ser en tekstbasere brugerflade.

Tom Paamand

en stejl indlæringskurve, men nogle tusinde folk havde lært det

Jeg underviste i et par systemer, der havde mus og alt det fine, og gjorde meget ud af teknisk at forklare, hvorfor der skulle trykkes på hvad og hvornår. Lige til jeg omsider forstod, at de fleste hellere ville have at jeg hoppede direkte til en slags "strikkeopskrift", der fik opgaven til at blive løst. Klik der, klik der, skriv dette og klik her.

Det flotteste jeg oplevede var en direktionssekretær, der skabte og udskrev dybt komplicerede rapporter, men absolut intet teknisk forstod. Hun fulgte blot sin opskrift, og jeg blev kun kaldt til hjælp, når et vindue havde flyttet sig for meget eller lignende. For hende var al den grafiske brugerflade egentlig mest til besvær.

Log ind eller Opret konto for at kommentere