Det vanskeligste faget

---

Programmering er det eneste nye håndtverksfaget på mange år, men håndtverk kommer til kort når det trengs ingeniørvirksomhet.

---

nn Denver i USA, har bygget en ny internasjonal flyplass. Dobbelt så stor som New Yorks Manhatten, ti ganger bredere enn Heathrow i Storbritannia. Målet er tre samtidige landinger i meget dårlig vær. Med så store ambisjoner er det ikke uvanlig med forsinkelser. Forsinkelsene skyldes byggeproblemer -- ikke anleggsproblemer, men programvareproblemer. Det avanserte systemet for bagasjetransport har sviktet fullstendig på grunn av feil i programvaren. 4.000 datastyrte bagasjetraller skal frakte bagasje langs 34 kilometer med skinnegang. Rundt 100 datamaskiner i et nettverk med 5.000 følere, over 50 strekkodelesere og 400 radiomottakere skal sørge for rask og effektiv bagasjehåndtering. På grunn av lus i programmet har åpningen av flyplassen vært utsatt i mange måneder. For hver dag taper investorene 1,1 millioner dollar.

nn Studier har vist at for hvert sjette omfattende programvaresystem som tas i bruk, er det to som blir kansellert. Verre er det at tre fjerdeler av alle store programvaresystemer enten ikke fungerer som planlagt, eller forblir ubenyttet. Ett av de første norske feilslagene var et lønningsystem til en Bull-maskin for omtrent 20 år siden. Lønningsystemets programmeringsspråk hadde svakheter, og programmererene visste ikke hvordan de skulle omgå problemene. Leveransen ble ikke fullført, og striden endte i retten. Andre fagfolk sluttførte systemet for den opprinnelige kunden. Den samme historien gjentar seg i forbindelse med Tress 90. Først ble Trygdedata hevet ut, nå er prosjektledelsen satt på porten.

nn De fleste store programvaresystemer er bygget som min gamle hytte. Den startet som en ettroms tømmerkoie. Siden ble det bygget på to soveværelser og det var greit med et kjøkken istedenfor grua i peisen. I dag er kjøkkenet det mest sentrale rommet i hytta med dører på samtlige vegger. Rom på rom ble bygget utenpå de andre, inntil det ikke lenger var praktisk å bygge på noe mer. Selv den opprinnelige utedoen var del av en bod. Skal det gjøres noe mer nå, er den beste løsningen en fyrstikk, for så å begynne med blanke ark. Tilsvarende gjaldt for mitt første store prosjekt, et DAK-konstruksjonsprogram til bruk i undervisningen på et amerikansk universitet. Da konstruksjonsprogrammet var ferdig programmert, skjønte vi hva vi virkelig hadde gjort, til tross for at vi hadde brukt subrutiner for å utnytte felles kode. Å konstruere om systemet fra grunnen av hadde ingen tid eller råd til.

nn DAK-systemet illustrerte to viktige forhold. I store prosjekter har ikke prosjektansvarlig fullstendig oversikt, og systemet er alt for mye knyttet til den spesielle maskinen systemet er laget for. Tress 90 illustrerer nok en gang at prosjektansvarlig ikke har nødvendig oversikt. Cap Computas måtte foreta en gjennomgang av systemet før trygdeledelsen kunne bestemme seg for videre fremdrift. Det er et tankekors at for hver ny datamaskinplattform som blir laget, må en så generell programvarerutine som sortering, skrives på nytt, for virkelig å være effektiv. Da Vesta skulle bygge nittiårenes forsikringssystem, benyttet de tre store norske IT-konsulentfirmaer til realiseringen. For hvert styringsgruppemøte vokste systemet. Onde tunger sa at kostnaden økte med 10 millioner kroner i måneden. Til slutt trakk Vestas ledelse i nødbremsen og stoppet hele utviklingen som var på vei mot hundre millioner kroner.

nn At store programvaresystemer gjør nytte for seg er American Airlines reservasjonssystem -- Sabre -- et glimrende eksempel på. Dette strategiske systemet gjorde American Airlines til verdens største flyselskap. To milliarder dollar kostet Sabre, som ble en av de viktigste komponentene i reiselivsnæringens infrastruktur. Americans ambisjoner stoppet ikke med reservasjonssystemet. Også hotel og bilutleie skulle integreres. I 1992 brøt det utvidete systemet fullstendig sammen, og American Airlines måtte ta et tap på 165 millioner dollar. Grunnen til at så store systemer svikter er manglen på ingeniørmessig utvikling. Programvaresystemer bygges ikke med utskiftbare standardkomponenter, de håndlages med mer eller mindre gode hjelpemidler.

nn Helt siden 1968 -- da nederlenderen Dijkstra påpekte at programvareinstruksjonen GOTO var livsfarlig for forståelsen av programmets virkemåte -- har fagfolk jobbet med å finne en vidundermedisin. Først var det strukturert programmering som skulle realisere et paradigmeskifte i programvareutviklingen. Deretter var det fjerdegenerasjonspråk, så CASE, og nå er det objektorientering som er lyset i tunnelen. Den historiske utviklingen tilsier at spådommer om store effektivitetsgevinster blir gjort til skamme. De ivrigste tilhengerne av objektorientert analyse og programmering har tro på over ti gangers forbedring i forhold til alternative utviklingsmetoder. Hvis det er tilfelle, vil det være et paradigmeskifte. Først ved årtusenskiftet vil vi kunne foreta realistiske vurderinger av den nyeste programvarereligionen.

nn Vi vil se en massiv forandring i datamaskinbruk de nærmeste fem årene. Den opprinnelige PC-revolusjonen vil blekne ved sammenligning, har ledere for programvareutvikling fra forskning, industri og universitetshold konkludert. Studier hos Philips i Nederland tilsier at programvarekoden i forbrukerartikler dobler hvert annet år. En elektrisk barbermaskin krever et 2 KB program, et TV-apparat 500 KB. Bilene til General Motors kjører 30.000 linjer programkode. Når lysbryteren benytter en mikroprosessor for å styre lyset, må programmet virke, for det er ikke mulig å forandre det. Riktig første gang, er et mål som er umulig å oppnå, uten en annen måte å foreta programmering på. Feil i programvaren er like vanskelige å finne som opphavet til den mistenkelige lyden i bilmotoren, som bare er der når den er mest irriterende, og aldri når verkstedet skal feilsøke.

nn Utsettelser eller katastrofe vil være et stadig vanligere fenomen hvis ikke programvareutvikling blir gjort mer profesjonelt. Ofte oppstår katastrofen fordi systemet glemmer å forvente det uforventede. Nettverksløsninger forsterker problemet. Forskere innen programvareutvikling må begynne å eksperimentere. For å få det til må vi begynne å måle programvarearbeidet. Ikke noe norsk IT-konsulentselskap har oversikter over hvor mange feil det produseres i løpet av en times programmering i et program på f.eks. 3.000 kodelinjer. Ingen vet om programmeringen har blitt mer effektiv med nye metoder og andre programmeringsspråk. Først når vi har lært av å eksperimentere, vil vi være istand til å lage generelle programvarekomponenter som kan benyttes om igjen.

Artikkel automatisk generert, 11/11-94, kl. 16.56 cw@oslonett.no