Hvorfor programvare er så dårlig

Det er en av de eldste vitsene på Internett, uendelig videresendt fra e-postkasse til e-postkasse. En programvaremogul - vanligvis Bill Gates, men noen ganger en annen - holder en tale. Hvis bilindustrien hadde utviklet seg som programvareindustrien, proklamerer mogulen, ville vi alle kjørt biler på 25 dollar som får 1000 miles til gallonen. Som en billeder svarer, ja, og hvis biler var som programvare, ville de krasjet to ganger om dagen uten grunn, og når du ringte etter service, ville de bedt deg om å installere motoren på nytt.





Vitsen innkapsler en av de store gåtene innen moderne teknologi. På utrolig kort tid har programvare blitt kritisk for nesten alle aspekter av det moderne livet. Fra bankhvelv til bylys, fra telefonnettverk til DVD-spillere, fra bilkollisjonsputer til lufttrafikkkontrollsystemer, verden rundt oss er regulert av kode. Likevel fungerer mye programvare rett og slett ikke pålitelig: spør alle som har sett en dataskjerm som er blå, og tørket ut timer med innsats. Alt for ofte, sier programvareingeniører, er kode oppblåst, stygg, ineffektiv og dårlig utformet; selv når programmer fungerer som de skal, synes brukere at de er for vanskelige å forstå. Bokhandlerhyller over hele landet stønner under vekten av mursteinslignende manualer og vitner om den vedvarende dysfunksjonaliteten til programvare.

Programvare er rett og slett forferdelig i dag, sier Watts S. Humphrey, en stipendiat ved Carnegie Mellon Universitys Software Engineering Institute som har skrevet flere kjente bøker om programvarekvalitet. Og det blir verre hele tiden. God programvare, etter Humphreys syn, er brukbar, pålitelig, defektfri, kostnadseffektiv og vedlikeholdbar. Og programvare nå er ingen av disse tingene. Du kan ikke ta noe ut av esken og vite at det kommer til å fungere. I løpet av årene, etter Edsger W. Dijkstra, en emeritus informatiker ved University of Texas i Austin, har den gjennomsnittlige databrukeren blitt servert så dårlig at han forventer at systemet hans vil krasje hele tiden, og vi er vitne til en massiv verdensomspennende distribusjon av programvare som er mye av feil, som vi burde skamme oss dypt over.

Jim McCarthy er mer sjenerøs. Grunnleggeren, sammen med sin kone Michele, av et opplæringsselskap for programvarekvalitet i Woodinville, WA, McCarthy mener at de fleste programvareprodukter har de nødvendige funksjonene for å være verdt å kjøpe og bruke og ta i bruk. Men, tillater han, bare den ekstreme nytten av programvare lar oss tolerere dens enorme mangler. McCarthy begynner noen ganger samtaler på skolen sin med en PowerPoint-presentasjon. Det første lysbildet lyder: Most Software Sucks.



Det er vanskelig å overvurdere det unike ved programvareproblemer. Når bilingeniører diskuterer bilene på markedet, sier de ikke at kjøretøy i dag ikke er bedre enn de var for ti eller femten år siden. Det samme gjelder for luftfartsingeniører: ingen påstår at Boeing eller Airbus lager elendige fly. Heller ikke elektroingeniører klager over at brikker og kretser ikke blir bedre. Som ingeniørhistorikeren Henry Petroski foreslo i sin bok fra 1992 Utviklingen av nyttige ting , kontinuerlig foredling er den vanlige regelen innen teknologi. Ingeniører legger stadig merke til mangler i designene deres og fikser dem litt etter litt, en prosess som Petroski lurt beskrev som form følger feil. Som et resultat forbedres produktene gradvis.

Programvare virker dessverre annerledes. Man kan forvente at et program på 45 millioner linjer som Windows XP, Microsofts nyeste operativsystem, har noen feil. Og programvareteknikk er en nyere disiplin enn maskin- eller elektroteknikk; de første virkelige programmene ble opprettet for bare 50 år siden. Men det som faktisk er overraskende-forbløffende, er at mange programvareingeniører tror at programvarekvaliteten ikke blir bedre. Om noe, sier de, blir det verre. Det er som om bilene Detroit produserte i 2002 var mindre pålitelige enn de som ble bygget i 1982.

Etter hvert som programvare blir stadig viktigere, vil den potensielle effekten av dårlig kode øke for å matche, mener Peter G. Neumann, en dataforsker ved SRI International, et privat FoU-senter i Menlo Park, CA. Bare i løpet av de siste 15 årene har programvaredefekter ødelagt en europeisk satellittoppskyting, forsinket åpningen av den enormt dyre flyplassen i Denver i ett år, ødelagt et NASA Mars-oppdrag, drept fire marinesoldater i en helikopterulykke, fått et amerikansk marineskip til å ødelegge et sivilt passasjerfly, og stengte ambulansesystemer i London, noe som førte til så mange som 30 dødsfall. Og på grunn av vår økende avhengighet av nettet, sier Neumann, vi har det mye verre enn vi var for fem år siden. Risikoen er verre og forsvaret er ikke like bra. Vi går bakover - og det er en skummel ting.



Noen programvareselskaper svarer på denne kritikken ved å fornye prosedyrene sine; Microsoft, stukket av anklager om at produktene deres er buggy, leder offentlig an. Likevel har problemer med programvarekvalitet vart så lenge, og virker så uløselig innebygd i programvarekulturen, at noen programmerere begynner å tenke det utenkelige. Til deres egen forbauselse har disse menneskene lurt på om det virkelige problemet med programvare er at ikke nok advokater er involvert.

Mangel på logikk

Microsoft lanserte Windows XP 25. oktober 2001. Samme dag, noe som kan være rekord, publiserte selskapet 18 megabyte av patcher på nettstedet: feilrettinger, kompatibilitetsoppdateringer og forbedringer. To patcher fikset viktige sikkerhetshull. Eller rettere sagt, en av dem gjorde det; den andre oppdateringen fungerte ikke. Microsoft rådet (og råder fortsatt) brukere til å sikkerhetskopiere kritiske filer før de installerer oppdateringene. Kjøpere av hjemmeversjonen av Windows XP oppdaget imidlertid at systemet ikke ga noen mulighet til å gjenopprette disse sikkerhetskopiene hvis ting gikk galt. Som Microsofts nettbaserte kunnskapsbase enkelt forklarte, fungerer ikke de spesielle backup-diskettene opprettet av Windows XP Home med Windows XP Home.



Slike utglidninger, sier kritikere, er bare overflatebortfall-tegn på at programvareutviklerne var for forhastede eller for uforsiktige til å fikse åpenbare defekter. De virkelige problemene ligger i programvarens grunnleggende design, ifølge R. A. Downes fra Radsoft, et programvarekonsulentfirma. Eller rettere sagt, det mangel på av design. Microsofts populære Visual Studio-programmeringsprogramvare er et eksempel på Downes måte å tenke på. Ved å bare plassere markøren over Visual Studio-vinduet, har Downes funnet ut, at det usynlig oversvømmer den sentrale prosessorenheten med tusenvis av unødvendige meldinger, selv om programmet ikke gjør noe. Det er katastrofalt. Det er totalt kaos, klager han.

Problemet, ifølge Dan Wallach, en dataforsker ved Rice University, er ikke den meningsløse churning av prosessoren - tross alt, bemerker han, er prosessorkraft billig. Heller ikke Microsoft-programvare er spesielt feil; Kritikere bruker ofte selskapets produkter som eksempler mer fordi de er kjente enn fordi de er uvanlig dårlige. I stedet, etter Wallachs syn, forråder den blomstrende, summende forvirringen i Visual Studio og så mange andre programmer hvordan teknikkene for å skrive programvare ikke har klart å holde tritt med den eksplosive økningen i kompleksiteten.

Programmerere skriver kode på språk som Java, C og C++, som kan leses av mennesker. Spesialiserte programmer kjent som kompilatorer transformerer denne koden til strengene med enere og nuller som brukes av datamaskiner. Viktigere, kompilatorer nekter å kompilere kode med åpenbare problemer - de spytter ut feilmeldinger i stedet. Fram til 1970-tallet satt kompilatorer på store stormaskiner som ofte ble bestilt dager eller uker i forveien. Siden de ikke ønsket at feil skulle forårsake forsinkelser, ble programmerere - som i de første dagene hadde en tendens til å bli opplært som matematikere eller fysikere - sent på kontoret og sjekket arbeidet sitt uttømmende. Å skrive programvare var mye som å skrive vitenskapelige artikler. Rigor, dokumentasjon og fagfellevurdering var skikken.



Men etter hvert som datamaskiner ble utbredt, endret holdningene seg. I stedet for omhyggelig å planlegge kode, holdt programmerere seg oppe i koffeinholdige hacking-økter hele natten, og stadig returnerte resultater fra kompilatoren. Igjen og igjen ville kompilatoren spytte tilbake feilmeldinger; programmererne ville fikse feilene én etter én inntil programvaren kompilerte riktig. Holdningen i dag er at du kan skrive hvilken som helst slurvet kode, og kompilatoren vil kjøre diagnostikk, sier SRIs Neumann. Hvis det ikke spytter ut en feilmelding, må det gjøres riktig, ikke sant?

Etter hvert som programmene vokste i størrelse og kompleksitet, ble grensene for denne kode- og rettelsesmetoden tydelige. I gjennomsnitt gjør profesjonelle kodere 100 til 150 feil for hver tusende kodelinje de skriver, ifølge en flerårig studie av 13 000 programmer av Humphrey fra Carnegie Mellon. Ved å bruke Humphreys tall ville dermed forretningsoperativsystemet Windows NT 4, med sine 16 millioner kodelinjer, blitt skrevet med rundt to millioner feil. De fleste ville vært for små til å ha noen effekt, men noen-mange tusen-ville ha forårsaket alvorlige problemer.

Naturligvis testet Microsoft uttømmende NT 4 før utgivelsen, men i nesten alle testfasene vil du finne mindre enn halvparten av defektene, sier Humphrey. Hvis Microsoft hadde gått gjennom fire runder med testing, en kostbar og tidkrevende prosedyre, ville selskapet ha funnet på det meste 15 av 16 feil. Det kommer til å etterlate deg med noe sånt som fem defekter per tusen linjer med kode, sier Humphrey. Noe som er veldig lavt, men programvaren vil fortsatt ha så mange som 80 000 feil.

Programvareingeniører vet at koden deres ofte er full av lakuner, og de har lenge lett etter ny teknologi for å forhindre dem. For å administrere stadig mer utvidede prosjekter som Windows, for eksempel, har de utviklet en rekke teknikker, hvorav kanskje den mest kjente er komponentbasert design. Akkurat som hus bygges med standardiserte to ganger fire og elektrisk utstyr, bygges komponentbaserte programmer av modulære, utskiftbare elementer: et eksempel er den nesten identiske menylinjen på toppen av hvert Windows- eller Macintosh-program. Slike standardiserte komponenter er ifølge Wallach ikke bare god ingeniørskikk, de er den eneste måten du i det hele tatt kan få noe på størrelse med Microsoft Office til å fungere. Microsoft, sier han, var en tidlig, aggressiv promotør av denne tilnærmingen – det er den beste ingeniørbeslutningen de noen gang har tatt.

Dessverre, sier kritikere, er komponentene ofte limt sammen uten noen reell sentral plan - som om entreprenører prøvde å bygge store strukturer uten tegninger. Utrolig, sier Humphrey, er designet for store programvareprosjekter noen ganger ikke annet enn et par bobler på baksiden av en konvolutt. Enda verre, av markedsføringsmessige årsaker kobler bedrifter så mange funksjoner som mulig inn i ny programvare, noe som motvirker fordelene med modulær konstruksjon. Det mest utbredte eksemplet er selve Windows, som Bill Gates vitnet i en april-sesjon av Microsoft antitrust-rettssaken rett og slett ikke ville fungere hvis kundene fjernet individuelle komponenter som nettlesere, filbehandlere eller e-postprogrammer. Det er en utrolig påstand, sier Neumann. Det betyr at det ikke er noen struktur eller arkitektur eller rim eller grunn i måten de har bygget disse systemene på, annet enn å gjøre dem så buntet som mulig, slik at hvis du fjerner en del, vil alt mislykkes.

Det utilstrekkelige designet i sluttproduktene, hevder kritikere, gjenspeiler utilstrekkelig planlegging i prosessen med å lage dem. I følge en studie fra Standish Group, et konsulentfirma i West Yarmouth, MA, er kommersielle programvareprosjekter i USA så dårlig planlagt og administrert at i 2000 ble nesten en fjerdedel kansellert direkte, noe som ikke skapte noe sluttprodukt. De kansellerte prosjektene kostet bedrifter 67 milliarder dollar; overskridelser på andre prosjekter samlet inn ytterligere 21 milliarder dollar. Men fordi kode og rettelse fører til så omfattende, kostbare testrunder, kan selv vellykkede prosjekter være veldig ineffektive. Utrolig nok bruker programvareprosjekter ofte 80 prosent av budsjettene deres til å reparere feil de selv produserte - et tall som ikke inkluderer den enda mer kostbare prosessen med å levere produktstøtte og utvikle patcher for problemer funnet etter utgivelsen.

Systemtesting fortsetter i nesten halve prosessen, sier Humphrey. Og selv når de endelig får det til å fungere, er det fortsatt ingen design. Som en konsekvens kan ikke programvaren oppdateres eller forbedres med noen forsikring om at oppdateringene eller forbedringene ikke vil introdusere store feil. Det er slik programvare er designet og bygget overalt - det er slik i romskip, for guds skyld.

Er programvare et spesielt tilfelle?

Den potensielle risikoen ved dårlig programvare ble dystert illustrert mellom 1985 og 1987, da en datastyrt strålebehandlingsmaskin produsert av den regjeringsstøttede Atomic Energy of Canada overdoserte pasienter massivt i USA og Canada, og drepte minst tre. I en uttømmende undersøkelse tildelte Nancy Leveson, nå en MIT-dataforsker, mye av skylden til produsentens utilstrekkelige programvareutviklingspraksis. Fordi programmet som ble brukt til å stille inn strålingsintensiteten ikke ble designet eller testet nøye, utløste enkle skrivefeil dødelige eksplosjoner.

Til tross for denne tragiske opplevelsen overdoserte lignende maskiner med programvare laget av Multidata Systems International i St. Louis pasienter i Panama i 2000 og 2001, noe som førte til åtte flere dødsfall. Et team fra Det internasjonale atomenergibyrået tilskrev dødsfallene til inntasting av data på en måte programmerere ikke hadde forutsett. Som Leveson bemerker, bør enkle datainntastingsfeil ikke ha dødelige konsekvenser. Så denne feilen kan også skyldes utilstrekkelig programvare.

Programmeringseksperter har en tendens til å være enige om at slike katastrofer er foruroligende vanlige. Tenk på Mars Climate Orbiter og Polar Lander, begge ødelagt i 1999 av kjente, lett forhindret kodefeil. Men noen hevder at programvare rett og slett ikke kan bedømmes, måles og forbedres på samme måte som andre ingeniørprodukter. Det er bare et faktum at det er ting som andre ingeniører kan gjøre som vi ikke kan gjøre, sier Shari Lawrence Pfleeger, seniorforsker ved Rand-tenketanken i Washington, DC, og forfatter av bindet fra 2001 Programvareteknikk: teori og praksis . Hvis en bro overlever en vekt på 500 kilo og en vekt på 50 000 kilo, bemerker Pfleeger, kan ingeniører anta at den vil bære alle verdiene mellom. Med programvare, sier hun, kan jeg ikke gjøre den antagelsen - jeg kan ikke interpolere.

Dessuten arbeider programvareprodusenter under ekstraordinære krav. Ford og General Motors har produsert det samme produktet - en firehjuls boks med forbrenningsmotor - i flere tiår. Som en konsekvens, sier Charles H. Connell, tidligere hovedingeniør i Lotus Development (nå en del av IBM), har de vært i stand til å forbedre produktene sine gradvis. Men programvareselskaper blir stadig bedt om å lage produkter - nettlesere på begynnelsen av 1990-tallet, nye mobiltelefongrensesnitt i dag - ulikt noe tidligere. Det er som en bilprodusent sier: I år skal vi lage et rakettskip i stedet for en bil, sier Connell. Selvfølgelig vil de ha problemer.

Det klassiske dilemmaet innen programvare er at folk stadig vil ha mer og mer og mer ting, sier Nathan Myhrvold, tidligere teknologisjef i Microsoft. Dessverre, bemerker han, betyr den konstante etterspørselen etter nyhet at programvare alltid er i en ny fase, når produktene i seg selv er mindre pålitelige. I 1983, sier han, hadde Microsoft Word bare 27 000 linjer med kode. Problemet er at det ikke gjorde så mye - noe kunder i dag ikke ville akseptert. Hvis Microsoft ikke hadde fortsatt å pumpe opp Word med nye funksjoner, ville ikke produktet eksistert lenger.

Brukerne er enormt ikke-selvbevisste, legger Myhrvold til. Hos Microsoft, sier han, krevde bedriftskunder ofte at selskapet samtidig skulle legge til nye funksjoner og slutte å legge til nye funksjoner. Bokstavelig talt, jeg har hørt det i et enkelt åndedrag, en enkelt setning. Vi er ikke sikre på hvorfor vi skal oppgradere til denne nye utgivelsen – den har alt dette vi ikke vil ha – og når skal du legge inn disse tre tingene?» Og du sier, Whaaat?» Myhrvolds sardoniske oppsummering: Programvare suger fordi brukere krever det.

Høyere standarder

I januar sendte Bill Gates ut en oppfordring til Microsoft-ansatte om å gjøre pålitelig og sikker databehandling til høyeste prioritet. I det selskapet regnet som et av de viktigste initiativene på mange år, krevde Gates at Microsoft dramatisk skulle redusere antallet defekter i produktene sine. En måned senere tok selskapet det enestående skrittet å suspendere all ny kodeskriving i nesten to måneder. I stedet samlet den programmerere, tusen om gangen, for massetreningsøkter om pålitelighet og sikkerhet. Ved å bruke store skjermer i et gigantisk auditorium viste bedriftsledere pinlige kodebiter produsert av de i publikum.

Gates sitt initiativ var tilsynelatende inspirert av kritikken som oppslukte Microsoft i juli 2001, da et bufferoverløp - en lenge kjent type feil - i Internet Information Services-nettserverprogramvaren lot Code Red-ormen gjøre ofre for tusenvis av bedriftskunder. (I et bufferoverløp mottar et program mer data enn forventet - som om man fylte ut plassen for et postnummer med et 50-sifret nummer. I en datamaskin vil den ekstra informasjonen søles inn i tilstøtende deler av minnet, ødelegge eller overskrive dataene der, med mindre de er nøye blokkert.) To måneder senere utnyttet Nimda-ormen andre feil i programvaren til å angripe flere tusen maskiner.

På grunn av slike opplevelser blir programvareutviklere mer oppmerksomme på kvalitet. Selv mens Gates samlet troppene sine, utviklet tenketanker som Kestrel Institute i Palo Alto, CA, programmeringsverktøysett for konstruksjon som nesten tvinger kodere til å skrive pålitelige programmer ( se Førstehjelp for feilkode ). Hos Microsoft selv, ifølge Amitabh Srivastava, leder av firmaets Programmer Productivity Research Center, jobber kodere med nye språk på høyere nivå som C# som ikke tillater visse feil. Og i mai grunnla Microsoft $30 millioner Sustainable Computing Consortium-basert på Carnegie Mellon-sammen med NASA og 16 andre firmaer for å fremme standardiserte måter å måle og forbedre programvarepålitelighet. Kvalitetskontrollinnsats kan lønne seg: i å hjelpe Lockheed Martin med å fornye programvaren i C130J-flyet, brukte Praxis Critical Systems, fra Bath, England, slike metoder for å kutte utviklingskostnadene med 80 prosent mens de produserte programvare som besto strenge eksamener fra Federal Aviation Administration med svært få feil.

gjemme seg