Hvorfor software er så dårligt

Det er en af ​​de ældste vittigheder på internettet, uendeligt videresendt fra e-mail til e-mail. En softwaremogul - normalt Bill Gates, men nogle gange en anden - holder en tale. Hvis bilindustrien havde udviklet sig som softwareindustrien, proklamerer mogulen, ville vi alle køre 25 dollars biler, der får 1.000 miles til gallonen. Hvortil en billeder svarer: Ja, og hvis biler var som software, ville de styrte ned to gange om dagen uden grund, og når du ringede til service, ville de bede dig om at geninstallere motoren.

Joken indkapsler et af de store gåder inden for moderne teknologi. På forbløffende kort tid er software blevet afgørende for næsten alle aspekter af det moderne liv. Fra bankbokse til bystoplys, fra telefonnetværk til dvd-afspillere, fra bilairbags til flyvekontrolsystemer, er verden omkring os reguleret af kode. Alligevel virker meget software ganske enkelt ikke pålideligt: ​​Spørg enhver, der har set en computerskærm, der blinker blåt, og udsletter timers anstrengelse. Alt for ofte, siger softwareingeniører, er kode oppustet, grim, ineffektiv og dårligt designet; selv når programmer fungerer korrekt, finder brugerne dem for svære at forstå. Stønnende under vægten af ​​murstenslignende manualer vidner boghandlerhylderne over hele landet om softwarens vedvarende dysfunktionalitet.

Software er simpelthen forfærdeligt i dag, siger Watts S. Humphrey, en stipendiat fra Carnegie Mellon Universitys Software Engineering Institute, som har skrevet adskillige velkendte bøger om softwarekvalitet. Og det bliver hele tiden værre. God software er efter Humphreys opfattelse brugbar, pålidelig, fejlfri, omkostningseffektiv og vedligeholdelsesvenlig. Og software nu er ingen af ​​disse ting. Du kan ikke tage noget ud af kassen og vide, at det kommer til at virke. I årenes løb er den gennemsnitlige computerbruger ifølge Edsger W. Dijkstra, emeritus-computerforsker ved University of Texas i Austin, blevet betjent så dårligt, at han forventer, at hans system går ned hele tiden, og vi er vidne til en massiv verdensomspændende distribution af fejlbehæftet software, som vi burde skamme os dybt over.

Jim McCarthy er mere generøs. Grundlæggeren, sammen med sin kone Michele, af et softwarekvalitetstræningsfirma i Woodinville, WA, mener McCarthy, at de fleste softwareprodukter har de nødvendige funktioner til at være værd at købe og bruge og adoptere. Men han tillader det, kun softwarens ekstreme anvendelighed lader os tolerere dens enorme mangler. McCarthy begynder nogle gange samtaler på sin skole med en PowerPoint-præsentation. Det første slide lyder, Most Software Sucks.

Det er svært at overbetone det unikke ved softwarens problemer. Når bilingeniører diskuterer bilerne på markedet, siger de ikke, at køretøjer i dag ikke er bedre, end de var for ti eller femten år siden. Det samme gælder for luftfartsingeniører: Ingen påstår, at Boeing eller Airbus laver elendige fly. Elektroingeniører klager heller ikke over, at chips og kredsløb ikke bliver bedre. Som ingeniørhistorikeren Henry Petroski foreslog i sin bog fra 1992 Udviklingen af ​​nyttige ting , konstant forfining er den sædvanlige regel inden for teknologi. Ingeniører bemærker konstant mangler i deres design og løser dem lidt efter lidt, en proces, som Petroski skævt beskrev som form følger fiasko. Som et resultat forbedres produkter trinvist.

Software virker desværre anderledes. Man ville forvente, at et program på 45 millioner linjer som Windows XP, Microsofts nyeste styresystem, har nogle få fejl. Og software engineering er en nyere disciplin end maskin- eller elektroteknik; de første rigtige programmer blev skabt for kun 50 år siden. Men det, der faktisk er overraskende-forbløffende, er, at mange softwareingeniører mener, at softwarekvaliteten ikke bliver bedre. Om noget, siger de, bliver det værre. Det er, som om de biler, Detroit producerede i 2002, var mindre pålidelige end dem, der blev bygget i 1982.

Efterhånden som software bliver stadig vigtigere, vil den potentielle virkning af dårlig kode blive større og matche, mener Peter G. Neumann, en datalog ved SRI International, et privat R&D-center i Menlo Park, Californien. Alene inden for de sidste 15 år har softwarefejl ødelagt en europæisk satellitopsendelse, forsinket åbningen af ​​den enormt dyre lufthavn i Denver i et år, ødelagt en NASA Mars-mission, dræbt fire marinesoldater i et helikopterstyrt, fået et amerikansk flådeskib til at ødelægge et civilt passagerfly, og lukkede ambulancesystemer i London, hvilket førte til så mange som 30 dødsfald. Og på grund af vores voksende afhængighed af nettet, siger Neumann, er vi meget værre stillet, end vi var for fem år siden. Risikoen er værre, og forsvaret er ikke så godt. Vi går baglæns - og det er en skræmmende ting.

Nogle softwarevirksomheder reagerer på denne kritik ved at forny deres procedurer; Microsoft, stukket af anklager om, at dets produkter er buggy, leder offentligt vejen. Alligevel har problemer med softwarekvalitet varet så længe og synes så uløseligt indlejret i softwarekulturen, at nogle programmerere begynder at tænke det utænkelige. Til deres egen forbløffelse har disse mennesker undret sig over, om det virkelige problem med software er, at der ikke er nok advokater involveret.

Mangel på logik

Microsoft udgav Windows XP den 25. oktober 2001. Samme dag, i hvad der måske er rekord, udsendte virksomheden 18 megabyte af patches på sit websted: fejlrettelser, kompatibilitetsopdateringer og forbedringer. To patches fiksede vigtige sikkerhedshuller. Eller rettere, en af ​​dem gjorde det; den anden patch virkede ikke. Microsoft rådede (og råder stadig) brugere til at sikkerhedskopiere vigtige filer, før de installerer programrettelserne. Købere af hjemmeversionen af ​​Windows XP opdagede dog, at systemet ikke gav nogen mulighed for at gendanne disse sikkerhedskopifiler, hvis tingene gik galt. Som Microsofts online Knowledge Base intetsigende forklarede, fungerer de specielle backup-disketter, der er oprettet af Windows XP Home, ikke med Windows XP Home.

Sådanne fejl, siger kritikere, er blot overfladebortfald - tegn på, at softwareudviklerne var for forhastede eller for skødesløse til at rette åbenlyse defekter. De virkelige problemer ligger i softwarens grundlæggende design, ifølge R. A. Downes fra Radsoft, et softwarekonsulentfirma. Eller rettere sagt, det mangel af design. Microsofts populære Visual Studio-programmeringssoftware er et eksempel på Downes måde at tænke på. Ved blot at placere markøren over Visual Studio-vinduet, har Downes fundet, at det usynligt spærrer centralenheden med tusindvis af unødvendige beskeder, selvom programmet ikke gør noget. Det er katastrofalt. Det er totalt kaos, klager han.

Spørgsmålet er ifølge Dan Wallach, en datalog ved Rice University, ikke den meningsløse kvælning af processoren - trods alt, bemærker han, er processorkraft billig. Microsoft er heller ikke særlig mangelfuld; kritikere bruger ofte virksomhedens produkter som eksempler mere, fordi de er velkendte, end fordi de er usædvanligt dårlige. I stedet forråder den blomstrende, summende forvirring i Visual Studio og så mange andre programmer efter Wallachs opfattelse, hvordan teknikkerne til at skrive software ikke har kunnet følge med den eksplosive stigning i dets kompleksitet.

Programmører skriver kode på sprog som Java, C og C++, som kan læses af mennesker. Specialiserede programmer kendt som compilere omdanner denne kode til strengene af eter og nuller, der bruges af computere. Det er vigtigt, at compilere nægter at kompilere kode med åbenlyse problemer - de spytter fejlmeddelelser ud i stedet. Indtil 1970'erne sad compilere på store mainframes, der ofte var booket dage eller uger i forvejen. Uden at ønske, at fejl skulle forårsage forsinkelse, blev kodere - som i de tidlige dage havde en tendens til at blive uddannet som matematikere eller fysikere - sent på deres kontorer og tjekkede deres arbejde udtømmende. At skrive software var meget som at skrive videnskabelige artikler. Rigor, dokumentation og peer-review-kontrol var kutyme.

Men efterhånden som computere blev udbredt, ændrede holdningerne sig. I stedet for omhyggeligt at planlægge kode, blev programmører oppe i koffeinholdige hacking-sessioner hele natten, hvor de konstant afviste resultater fra compileren. Igen og igen ville compileren spytte fejlmeddelelser tilbage; programmørerne ville rette fejlene én efter én, indtil softwaren kompileret korrekt. Holdningen i dag er, at du kan skrive et hvilket som helst sjusket stykke kode, og compileren vil køre diagnostik, siger SRIs Neumann. Hvis det ikke spytter en fejlmeddelelse ud, skal det gøres korrekt, ikke?

Efterhånden som programmer voksede i størrelse og kompleksitet, blev grænserne for denne kode- og rettelsestilgang tydelige. I gennemsnit laver professionelle kodere 100 til 150 fejl i hver tusinde linjer kode, de skriver, ifølge en flerårig undersøgelse af 13.000 programmer af Humphrey fra Carnegie Mellon. Ved at bruge Humphreys tal ville erhvervsoperativsystemet Windows NT 4 med sine 16 millioner linjer kode således være skrevet med omkring to millioner fejl. De fleste ville have været for små til at have nogen effekt, men nogle - mange tusinde - ville have forårsaget alvorlige problemer.

Naturligvis testede Microsoft udtømmende NT 4 før udgivelsen, men i næsten enhver fase af testene vil du finde mindre end halvdelen af ​​fejlene, siger Humphrey. Hvis Microsoft havde gennemgået fire testrunder, en dyr og tidskrævende procedure, ville virksomheden højst have fundet 15 ud af 16 fejl. Det vil efterlade dig med noget i retning af fem defekter pr. tusind linjer kode, siger Humphrey. Hvilket er meget lavt - men softwaren ville stadig have så mange som 80.000 fejl.

Softwareingeniører ved, at deres kode ofte er fyldt med huller, og de har længe ledt efter nye teknologier for at forhindre dem. For at styre stadigt mere udstrakte projekter som Windows, for eksempel, har de udviklet en række forskellige teknikker, hvoraf den måske bedst kendte er komponentbaseret design. Ligesom huse bygges med standardiserede to gange fire og elektriske fittings, er komponentbaserede programmer bygget ud af modulære, udskiftelige elementer: Et eksempel er den næsten identiske menulinje øverst på alle Windows- eller Macintosh-programmer. Sådanne standardiserede komponenter er ifølge Wallach ikke kun god ingeniørpraksis, de er den eneste måde, du overhovedet kan få noget på størrelse med Microsoft Office til at fungere. Microsoft, siger han, var en tidlig, aggressiv fortaler for denne tilgang - det er den bedste ingeniørbeslutning, de nogensinde har truffet.

Desværre, siger kritikere, er komponenterne ofte limet sammen uden nogen egentlig central plan - som om entreprenører forsøgte at opføre store strukturer uden tegninger. Utroligt, siger Humphrey, er designet til store softwareprojekter nogle gange ikke andet end et par bobler på bagsiden af ​​en konvolut. Hvad værre er, af markedsføringsmæssige årsager kobler virksomheder så mange funktioner som muligt ind i ny software, hvilket modvirker fordelene ved modulopbygning. Det mest udbredte eksempel er selve Windows, som Bill Gates vidnede i en april-session i Microsoft antitrust-sagen simpelthen ikke ville fungere, hvis kunder fjernede individuelle komponenter såsom browsere, filhåndteringer eller e-mail-programmer. Det er en utrolig påstand, siger Neumann. Det betyder, at der ikke er nogen struktur eller arkitektur eller rim eller grund i den måde, de har bygget disse systemer på, andet end at gøre dem så bundtede som muligt, så hvis du fjerner en del, vil det hele mislykkes.

Det utilstrækkelige design i de endelige produkter, hævder kritikere, afspejler utilstrækkelig planlægning i processen med at skabe dem. Ifølge en undersøgelse fra Standish Group, et konsulentfirma i West Yarmouth, MA, er amerikanske kommercielle softwareprojekter så dårligt planlagt og styret, at næsten en fjerdedel i 2000 blev annulleret uden videre, hvilket ikke skabte noget endeligt produkt. De aflyste projekter kostede virksomheder 67 milliarder dollars; overskridelser af andre projekter samlede yderligere 21 milliarder dollars. Men fordi kode og rettelse fører til så omfattende, dyre testrunder, kan selv vellykkede projekter være vildt ineffektive. Utroligt nok afsætter softwareprojekter ofte 80 procent af deres budgetter til at reparere fejl, de selv producerede - et tal, der ikke inkluderer den endnu dyrere proces med at levere produktsupport og udvikle patches til problemer fundet efter udgivelsen.

Systemtest fortsætter i næsten halvdelen af ​​processen, siger Humphrey. Og selv når de endelig får det til at virke, er der stadig intet design. Som følge heraf kan softwaren ikke opdateres eller forbedres med nogen forsikring om, at opdateringerne eller forbedringerne ikke vil introducere større fejl. Det er sådan software er designet og bygget overalt - det er sådan i rumskibe, for guds skyld.

Er software et særligt tilfælde?

De potentielle risici ved dårlig software blev dystert illustreret mellem 1985 og 1987, da en computerstyret strålebehandlingsmaskine fremstillet af den regeringsstøttede Atomic Energy of Canada massivt overdoserede patienter i USA og Canada og dræbte mindst tre. I en udtømmende undersøgelse tildelte Nancy Leveson, nu en MIT-datamatiker, en stor del af skylden til producentens utilstrækkelige software-engineeringspraksis. Fordi programmet, der blev brugt til at indstille strålingsintensiteten, ikke var designet eller testet omhyggeligt, udløste simple tastefejl dødelige eksplosioner.

På trods af denne tragiske oplevelse overdoserede lignende maskiner med software fremstillet af Multidata Systems International i St. Louis massivt patienter i Panama i 2000 og 2001, hvilket førte til yderligere otte dødsfald. Et hold fra Det Internationale Atomenergiagentur tilskrev dødsfaldene til indtastning af data på en måde, som programmører ikke havde forudset. Som Leveson bemærker, bør simple dataindtastningsfejl ikke have dødelige konsekvenser. Så denne fejl kan også skyldes utilstrækkelig software.

Programmeringseksperter er tilbøjelige til at være enige om, at sådanne katastrofer er foruroligende almindelige. Overvej Mars Climate Orbiter og Polar Lander, begge ødelagt i 1999 af velkendte, let forhindrede kodefejl. Men nogle hævder, at software simpelthen ikke kan bedømmes, måles og forbedres på samme måde som andre tekniske produkter. Det er bare et faktum, at der er ting, som andre ingeniører kan gøre, som vi ikke kan gøre, siger Shari Lawrence Pfleeger, seniorforsker ved Rand-tænketanken i Washington, DC, og forfatter til bindet fra 2001. Software Engineering: Teori og praksis . Hvis en bro overlever en vægt på 500 kilo og en vægt på 50.000 kilo, bemærker Pfleeger, kan ingeniører antage, at den vil bære alle værdierne imellem. Med software, siger hun, kan jeg ikke gøre den antagelse - jeg kan ikke interpolere.

Desuden arbejder softwareproducenter under ekstraordinære krav. Ford og General Motors har fremstillet det samme produkt - en firehjulet kasse med en forbrændingsmotor - i årtier. Som følge heraf, siger Charles H. Connell, tidligere chefingeniør i Lotus Development (nu en del af IBM), har de været i stand til at forbedre deres produkter gradvist. Men softwarevirksomheder bliver konstant bedt om at skabe produkter - webbrowsere i begyndelsen af ​​1990'erne, nye mobiltelefongrænseflader i dag - i modsætning til noget tidligere set. Det er ligesom en bilproducent, der siger: I år skal vi lave et raketskib i stedet for en bil,' siger Connell. Selvfølgelig vil de have problemer.

Det klassiske dilemma i software er, at folk hele tiden vil have flere og flere og flere ting, siger Nathan Myhrvold, tidligere teknologichef i Microsoft. Desværre, bemærker han, betyder den konstante efterspørgsel efter nyheder, at software altid er i den blødende fase, hvor produkter i sagens natur er mindre pålidelige. I 1983, siger han, havde Microsoft Word kun 27.000 linjer kode. Problemet er, at det ikke gjorde ret meget - hvilket kunder i dag ikke ville acceptere. Hvis Microsoft ikke var blevet ved med at pumpe Word op med nye funktioner, ville produktet ikke længere eksistere.

Brugerne er enormt ikke-selvbevidste, tilføjer Myhrvold. Hos Microsoft, siger han, krævede erhvervskunder ofte, at virksomheden samtidig tilføjede nye funktioner og stoppede med at tilføje nye funktioner. Bogstaveligt talt har jeg hørt det i et enkelt åndedrag, en enkelt sætning. Vi er ikke sikre på, hvorfor vi skal opgradere til denne nye udgivelse - den har alt det her, vi ikke vil have - og hvornår vil du lægge disse tre ting ind?' Og du siger, Whaaat?' Myhrvolds sardoniske opsummering: Software stinker, fordi brugerne kræver det.

Højere standarder

I januar udsendte Bill Gates en opfordring til Microsoft-medarbejdere om at give pålidelig og sikker databehandling deres højeste prioritet. I det, som selskabet anså som et af dets vigtigste initiativer i årevis, krævede Gates, at Microsoft dramatisk reducerede antallet af defekter i sine produkter. En måned senere tog virksomheden det hidtil usete skridt at suspendere al ny kodeskrivning i næsten to måneder. I stedet samlede den programmører, tusinde ad gangen, til massetræningssessioner om pålidelighed og sikkerhed. Ved at bruge store skærme i et kæmpe auditorium viste virksomhedsledere pinlige uddrag af mangelfuld kode produceret af publikum.

Gates' initiativ var tilsyneladende inspireret af den kritik, der opslugte Microsoft i juli 2001, da et bufferoverløb - en længe kendt type fejl - i dets Internet Information Services-webserversoftware lod Code Red-ormen ofre tusinder af dets virksomhedsklienter. (I et bufferoverløb modtager et program flere data end forventet - som om man udfyldte pladsen til et postnummer med et 50-cifret nummer. I en computer vil den ekstra information spildes ind i tilstødende dele af hukommelsen, korrumpere eller overskrive dataene der, medmindre de er omhyggeligt blokeret.) To måneder senere udnyttede Nimda-ormen andre fejl i softwaren til at angribe flere tusinde maskiner.

Plaget af sådanne oplevelser bliver softwareudviklere mere opmærksomme på kvalitet. Selv mens Gates samlede sine tropper, udviklede tænketanke som Kestrel Institute i Palo Alto, CA, programmeringsværktøjssæt, som næsten tvinger kodere til at skrive pålidelige programmer ( se Førstehjælp ved fejlkode ). Hos Microsoft selv, ifølge Amitabh Srivastava, leder af firmaets Programmer Productivity Research Center, arbejder kodere med nye sprog på højere niveau som C#, der ikke tillader visse fejl. Og i maj stiftede Microsoft sammen med NASA og 16 andre firmaer $30 millioner Sustainable Computing Consortium-baseret i Carnegie Mellon for at fremme standardiserede måder at måle og forbedre softwarepålidelighed. Kvalitetskontrolindsatsen kan betale sig pænt: For at hjælpe Lockheed Martin med at forny softwaren i deres C130J-fly, brugte Praxis Critical Systems, fra Bath, England, sådanne metoder til at reducere udviklingsomkostningerne med 80 procent, mens de producerede software, der bestod strenge Federal Aviation Administration-eksamener med meget få fejl.

skjule