211service.com
Varför programvara är så dålig
Det är ett av de äldsta skämten på Internet, oändligt vidarebefordrat från e-postlåda till e-postlåda. En mjukvarumogul - vanligtvis Bill Gates, men ibland en annan - håller ett tal. Om bilindustrin hade utvecklats som mjukvaruindustrin, proklamerar mogulen, skulle vi alla köra $25-bilar som når 1 000 miles till gallon. Till vilket en bilchef svarar, ja, och om bilar var som mjukvara, skulle de krascha två gånger om dagen utan anledning, och när du ringde efter service, skulle de säga åt dig att installera om motorn.
Skämtet kapslar in ett av den samtida teknikens stora pussel. På otroligt kort tid har mjukvara blivit avgörande för nästan alla aspekter av det moderna livet. Från bankvalv till stoppljus i staden, från telefonnät till DVD-spelare, från bilkrockkuddar till flygledningssystem, världen runt oss regleras av kod. Ändå fungerar mycket mjukvara helt enkelt inte tillförlitligt: fråga alla som har sett en datorskärm bli blå, vilket tar bort timmar av ansträngning. Alltför ofta, säger mjukvaruingenjörer, är koden uppsvälld, ful, ineffektiv och dåligt utformad; även när program fungerar korrekt, tycker användarna att de är för svåra att förstå. Stönande under tyngden av tegelliknande manualer, vittnar bokhandelshyllor över hela landet om mjukvarans ihållande dysfunktionalitet.
Mjukvaran är helt enkelt hemsk idag, säger Watts S. Humphrey, en kollega vid Carnegie Mellon Universitys Software Engineering Institute som har skrivit flera välkända böcker om mjukvarukvalitet. Och det blir värre hela tiden. Bra programvara, enligt Humphreys uppfattning, är användbar, pålitlig, defektfri, kostnadseffektiv och underhållsbar. Och mjukvara nu är ingen av dessa saker. Du kan inte ta något ur lådan och veta att det kommer att fungera. Under årens lopp, enligt Edsger W. Dijkstra, en emeritus datavetare vid University of Texas i Austin, har den genomsnittliga datoranvändaren fått så dålig service att han förväntar sig att hans system kraschar hela tiden, och vi ser en enorm världsomspännande distribution av buggaren mjukvara som vi borde skämmas djupt för.
Jim McCarthy är mer generös. Grundaren, tillsammans med sin fru Michele, av ett utbildningsföretag för mjukvarukvalitet i Woodinville, WA, McCarthy tror att de flesta mjukvaruprodukter har de nödvändiga funktionerna för att vara värda att köpa och använda och adoptera. Men, han tillåter, bara den extrema användbarheten av programvara låter oss tolerera dess enorma brister. McCarthy börjar ibland samtal på sin skola med en PowerPoint-presentation. Den första bilden lyder: Most Software Sucks.
Det är svårt att överbetona det unika med mjukvarans problem. När bilingenjörer diskuterar bilarna på marknaden säger de inte att fordonen idag inte är bättre än de var för tio eller femton år sedan. Detsamma gäller för flygingenjörer: ingen påstår att Boeing eller Airbus gör usla plan. Elektroingenjörer klagar inte heller över att chips och kretsar inte förbättras. Som ingenjörshistorikern Henry Petroski föreslog i sin bok från 1992 Utvecklingen av användbara saker , ständig förfining är den vanliga regeln inom teknik. Ingenjörer märker ständigt brister i sina konstruktioner och fixar dem lite i taget, en process som Petroski snett beskrev som form följer på misslyckande. Som ett resultat förbättras produkterna stegvis.
Programvara, tyvärr, verkar annorlunda. Man skulle förvänta sig att ett program med 45 miljoner rader som Windows XP, Microsofts senaste operativsystem, skulle ha några buggar. Och mjukvaruteknik är en nyare disciplin än mekanik eller elektroteknik; de första riktiga programmen skapades för bara 50 år sedan. Men vad som faktiskt är förvånande-häpnadsväckande är att många mjukvaruingenjörer tror att mjukvarukvaliteten inte förbättras. Om något, säger de, så blir det värre. Det är som om bilarna Detroit tillverkade 2002 var mindre tillförlitliga än de som byggdes 1982.
När programvaran blir allt viktigare kommer den potentiella effekten av dålig kod att öka för att matcha, enligt Peter G. Neumann, en datavetare vid SRI International, ett privat FoU-center i Menlo Park, Kalifornien. Bara under de senaste 15 åren har mjukvarudefekter förstört en europeisk satellituppskjutning, försenat öppnandet av den enormt dyra flygplatsen i Denver i ett år, förstört ett NASA-uppdrag på Mars, dödat fyra marinsoldater i en helikopterkrasch, fått ett fartyg från den amerikanska flottan att förstöra ett civilt flygplan och stängde av ambulanssystemen i London, vilket ledde till så många som 30 dödsfall. Och på grund av vårt växande beroende av nätet, säger Neumann, har vi det mycket sämre än vi var för fem år sedan. Riskerna är värre och försvaret inte lika bra. Vi går baklänges - och det är en skrämmande sak.
Vissa mjukvaruföretag svarar på denna kritik genom att förnya sina rutiner; Microsoft, stött av anklagelser om att dess produkter är buggiga, leder offentligt vägen. Ändå har problem med mjukvarukvalitet pågått så länge, och verkar så svårlöst inbäddade i mjukvarukulturen, att vissa kodare börjar tänka det otänkbara. Till sin egen förvåning har dessa människor kommit på att de undrar om det verkliga problemet med programvara är att inte tillräckligt många advokater är inblandade.
Brist på logik
Microsoft släppte Windows XP den 25 oktober 2001. Samma dag, vilket kan vara ett rekord, publicerade företaget 18 megabyte av patchar på sin webbplats: buggfixar, kompatibilitetsuppdateringar och förbättringar. Två patchar fixade viktiga säkerhetshål. Eller snarare, en av dem gjorde det; den andra patchen fungerade inte. Microsoft rådde (och råder fortfarande) användare att säkerhetskopiera viktiga filer innan de installerar patchar. Köpare av hemversionen av Windows XP upptäckte dock att systemet inte gav något sätt att återställa dessa säkerhetskopior om det skulle gå snett. Som Microsofts kunskapsbas online intetsägande förklarade, fungerar inte de speciella backupdisketter som skapats av Windows XP Home med Windows XP Home.
Sådana misstag, säger kritiker, är bara ytliga brister - tecken på att mjukvarans utvecklare var för bråttom eller för slarvig för att fixa uppenbara defekter. De verkliga problemen ligger i mjukvarans grundläggande design, enligt R. A. Downes från Radsoft, ett mjukvarukonsultföretag. Eller snarare, det brist av design. Microsofts populära Visual Studio-programmeringsprogram är ett exempel på Downes sätt att tänka. Genom att helt enkelt placera markören över Visual Studio-fönstret, har Downes upptäckt att det osynligt spärrar centralenheten med tusentals onödiga meddelanden, även om programmet inte gör någonting. Det är katastrofalt. Det är totalt kaos, klagar han.
Problemet, enligt Dan Wallach, en datavetare vid Rice University, är inte det meningslösa tjusandet av processorn - trots allt, noterar han, är processorkraften billig. Inte heller Microsofts programvara är särskilt felaktig; kritiker använder ofta företagets produkter som exempel mer för att de är bekanta än för att de är ovanligt dåliga. I stället, enligt Wallachs uppfattning, förråder den blommande, surrande förvirringen i Visual Studio och så många andra program hur teknikerna för att skriva programvara har misslyckats med att hålla jämna steg med den explosiva ökningen av dess komplexitet.
Programmerare skriver kod på språk som Java, C och C++, som kan läsas av människor. Specialiserade program som kallas kompilatorer omvandlar denna kod till strängarna av ettor och nollor som används av datorer. Viktigt är att kompilatorer vägrar att kompilera kod med uppenbara problem - de spottar ut felmeddelanden istället. Fram till 1970-talet satt kompilatorer på stora stordatorer som ofta bokades dagar eller veckor i förväg. Eftersom de inte ville att fel skulle orsaka förseningar, stannade kodare - som i de första dagarna tenderade att utbildas till matematiker eller fysiker - sent på sina kontor och kontrollerade uttömmande sitt arbete. Att skriva programvara var ungefär som att skriva vetenskapliga artiklar. Rigor, dokumentation och peer-review-granskning var sedvanligt.
Men i takt med att datorer blev utbredda förändrades attityderna. Istället för att noggrant planera kod, höll programmerare uppe i koffeinhaltiga hacksessioner hela natten och studsade ständigt resultat från kompilatorn. Om och om igen skulle kompilatorn spotta tillbaka felmeddelanden; programmerarna skulle fixa misstagen ett efter ett tills programvaran kompilerades ordentligt. Attityden idag är att du kan skriva vilken slarvig kod som helst och kompilatorn kör diagnostik, säger SRI:s Neumann. Om det inte spottar ut ett felmeddelande måste det göras korrekt, eller hur?
När programmen växte i storlek och komplexitet, blev dock gränserna för denna kod och fix-strategi uppenbara. I genomsnitt gör professionella kodare 100 till 150 fel i varje tusen rader kod de skriver, enligt en flerårig studie av 13 000 program av Humphrey från Carnegie Mellon. Med hjälp av Humphreys siffror skulle affärsoperativsystemet Windows NT 4, med sina 16 miljoner rader kod, alltså ha skrivits med cirka två miljoner misstag. De flesta skulle ha varit för små för att ha någon effekt, men några - många tusen - skulle ha orsakat allvarliga problem.
Naturligtvis testade Microsoft uttömmande NT 4 före release, men i nästan alla testfaser hittar du mindre än hälften av defekterna, säger Humphrey. Om Microsoft hade gått igenom fyra testomgångar, en dyr och tidskrävande procedur, skulle företaget ha hittat som mest 15 av 16 buggar. Det kommer att lämna dig med ungefär fem defekter per tusen rader kod, säger Humphrey. Vilket är väldigt lågt, men programvaran skulle fortfarande ha så många som 80 000 fel.
Mjukvaruingenjörer vet att deras kod ofta är fylld av luckor, och de har länge letat efter ny teknik för att förhindra dem. För att hantera allt mer utbredda projekt som Windows, till exempel, har de utvecklat en mängd olika tekniker, varav den kanske mest kända är komponentbaserad design. Precis som hus byggs med standardiserade två gånger fyra och elektriska kopplingar, byggs komponentbaserade program av modulära, utbytbara element: ett exempel är den nästan identiska menyraden överst på alla Windows- eller Macintosh-program. Sådana standardiserade komponenter, enligt Wallach, är inte bara god ingenjörssed, de är det enda sättet du kan få något i storleken av Microsoft Office att fungera överhuvudtaget. Microsoft, säger han, var en tidig, aggressiv promotor för detta tillvägagångssätt - det är det enskilt bästa tekniska beslut de någonsin tagit.
Tyvärr, säger kritiker, är komponenterna ofta limmade ihop utan någon egentlig central plan - som om entreprenörer försökte uppföra stora strukturer utan ritningar. Otroligt nog, säger Humphrey, är designen för stora programvaruprojekt ibland bara ett par bubblor på baksidan av ett kuvert. Vad värre är, av marknadsföringsskäl kopplar företag in så många funktioner som möjligt i ny mjukvara, vilket motverkar fördelarna med modulär konstruktion. Det mest utbredda exemplet är själva Windows, som Bill Gates vittnade om i en aprilsession av Microsofts antitrusträttegång helt enkelt inte skulle fungera om kunderna tog bort enskilda komponenter som webbläsare, filhanterare eller e-postprogram. Det är ett otroligt påstående, säger Neumann. Det betyder att det inte finns någon struktur eller arkitektur eller rim eller anledning i sättet de har byggt dessa system, annat än att göra dem så buntade som möjligt, så att om du tar bort någon del kommer allt att misslyckas.
Den otillräckliga designen i slutprodukterna, menar kritiker, återspeglar otillräcklig planering i processen att skapa dem. Enligt en studie av Standish Group, ett konsultföretag i West Yarmouth, MA, är kommersiella programvaruprojekt i USA så dåligt planerade och hanterade att år 2000 nästan en fjärdedel avbröts direkt, vilket inte skapade någon slutprodukt. De inställda projekten kostade företag 67 miljarder dollar; överskridanden av andra projekt samlade in ytterligare 21 miljarder dollar. Men eftersom kod och fix leder till så omfattande, kostsamma testrundor, kan även framgångsrika projekt vara väldigt ineffektiva. Otroligt nog ägnar programvaruprojekt ofta 80 procent av deras budgetar för att reparera brister som de själva producerat - en siffra som inte inkluderar den ännu mer kostsamma processen att tillhandahålla produktsupport och utveckla patchar för problem som hittats efter release.
Systemtestning pågår under nästan halva processen, säger Humphrey. Och även när de äntligen får det att fungera, finns det fortfarande ingen design. Följaktligen kan programvaran inte uppdateras eller förbättras med någon garanti för att uppdateringarna eller förbättringarna inte kommer att medföra större fel. Det är så mjukvara designas och byggs överallt - det är så i rymdskepp, för guds skull.
Är programvara ett specialfall?
De potentiella riskerna med dålig programvara illustrerades dystert mellan 1985 och 1987, när en datorstyrd strålbehandlingsmaskin tillverkad av den regeringsstödda Atomic Energy of Canada överdoserade patienter kraftigt i USA och Kanada och dödade minst tre. I en uttömmande granskning tilldelade Nancy Leveson, nu en MIT-datavetare, mycket av skulden på tillverkarens otillräckliga programvarutekniker. Eftersom programmet som användes för att ställa in strålningsintensiteten inte utformades eller testades noggrant, utlöste enkla skrivfel dödliga sprängningar.
Trots denna tragiska upplevelse överdoserade liknande maskiner med mjukvara tillverkade av Multidata Systems International i St. Louis patienter i Panama under 2000 och 2001, vilket ledde till ytterligare åtta dödsfall. Ett team från Internationella atomenergiorganet tillskrev dödsfallen till inmatningen av data på ett sätt som programmerare inte hade räknat med. Som Leveson noterar bör enkla datainmatningsfel inte ha dödliga konsekvenser. Så även detta misslyckande kan bero på otillräcklig programvara.
Programmeringsexperter tenderar att hålla med om att sådana katastrofer är beklagligt vanliga. Tänk på Mars Climate Orbiter och Polar Lander, som båda förstördes 1999 av bekanta, lätt förhindrade kodningsfel. Men vissa hävdar att mjukvara helt enkelt inte kan bedömas, mätas och förbättras på samma sätt som andra tekniska produkter. Det är bara ett faktum att det finns saker som andra ingenjörer kan göra som vi inte kan göra, säger Shari Lawrence Pfleeger, senior forskare vid Rand tankesmedjan i Washington, DC, och författare till 2001 års volym. Programvaruteknik: teori och praktik . Om en bro överlever en vikt på 500 kilo och en vikt på 50 000 kilo, konstaterar Pfleeger, kan ingenjörer anta att den kommer att bära alla värden däremellan. Med mjukvara, säger hon, kan jag inte göra det antagandet - jag kan inte interpolera.
Dessutom arbetar mjukvarutillverkare under extraordinära krav. Ford och General Motors har tillverkat samma produkt - en fyrhjulig låda med en förbränningsmotor - i årtionden. Som en konsekvens, säger Charles H. Connell, tidigare chefsingenjör för Lotus Development (nu en del av IBM), har de kunnat förbättra sina produkter stegvis. Men mjukvaruföretag uppmanas ständigt att skapa produkter - webbläsare i början av 1990-talet, nya mobiltelefongränssnitt idag - till skillnad från allt som tidigare sett. Det är som en biltillverkare säger: I år ska vi göra ett raketskepp istället för en bil, säger Connell. Självklart kommer de att få problem.
Det klassiska dilemmat inom mjukvara är att människor ständigt vill ha mer och mer och mer saker, säger Nathan Myhrvold, tidigare teknikchef på Microsoft. Tyvärr, konstaterar han, innebär den ständiga efterfrågan på nyhet att mjukvara alltid befinner sig i den nya fasen, när produkterna i sig är mindre tillförlitliga. 1983, säger han, hade Microsoft Word bara 27 000 rader kod. Problemet är att det inte gjorde så mycket - vilket kunder idag inte skulle acceptera. Om Microsoft inte hade fortsatt att pumpa upp Word med nya funktioner, skulle produkten inte längre existera.
Användare är oerhört icke-självmedvetna, tillägger Myhrvold. Hos Microsoft, säger han, krävde företagskunder ofta att företaget samtidigt skulle lägga till nya funktioner och sluta lägga till nya funktioner. Bokstavligen, jag har hört det i ett enda andetag, en enda mening. Vi är inte säkra på varför vi ska uppgradera till den här nya utgåvan – den har allt det här som vi inte vill ha – och när ska du lägga in dessa tre saker?” Och du säger, Whaaat?” Myhrvolds sardoniska sammanfattning: Mjukvara suger eftersom användare kräver det.
Högre standarder
I januari utfärdade Bill Gates en uppmaning till Microsofts anställda att göra pålitlig och säker datoranvändning till sin högsta prioritet. I vad företaget ansåg som ett av dess viktigaste initiativ på flera år, krävde Gates att Microsoft dramatiskt skulle minska antalet defekter i sina produkter. En månad senare tog företaget det oöverträffade steget att avbryta all ny kodskrivning i nästan två månader. Istället samlade den ihop programmerare, tusen åt gången, för massträningspass om tillförlitlighet och säkerhet. Med hjälp av enorma skärmar i ett gigantiskt auditorium visade företagsledare pinsamma fragment av felaktig kod som producerats av de i publiken.
Gates initiativ var uppenbarligen inspirerat av kritiken som uppslukade Microsoft i juli 2001 när ett buffertspill - en sedan länge välkänd typ av fel - i dess Internet Information Services webbserverprogramvara lät Code Red-masken ta tusentals av dess företagskunder till offer. (I ett buffertspill tar ett program emot mer data än förväntat - som om man fyllde i utrymmet för ett postnummer med ett 50-siffrigt nummer. I en dator kommer den extra informationen att spilla in i angränsande delar av minnet, korrumpera eller skriva över data där, om den inte är noggrant blockerad.) Två månader senare utnyttjade Nimda-masken andra brister i programvaran för att attackera ytterligare tusentals maskiner.
Slagda av sådana erfarenheter blir mjukvaruutvecklare mer uppmärksamma på kvalitet. Till och med när Gates samlade sina trupper utvecklade tankesmedjor som Kestrel Institute i Palo Alto, CA, korrekta programmeringsverktyg som nästan tvingar kodare att skriva tillförlitliga program ( se Första hjälpen för felaktig kod ). Hos Microsoft själv, enligt Amitabh Srivastava, chef för företagets Programmer Productivity Research Center, arbetar kodare med nya språk på högre nivå som C# som inte tillåter vissa fel. Och i maj grundade Microsoft $30 miljoner Sustainable Computing Consortium-baserat på Carnegie Mellon-tillsammans med NASA och 16 andra företag för att främja standardiserade sätt att mäta och förbättra programvarans pålitlighet. Kvalitetskontrollinsatser kan löna sig rejält: för att hjälpa Lockheed Martin att förnya programvaran i sitt C130J-flygplan använde Praxis Critical Systems, Bath, England, sådana metoder för att minska utvecklingskostnaderna med 80 procent samtidigt som de producerade programvara som klarade stränga prov från Federal Aviation Administration med väldigt få fel.