211service.com
Waarom software zo slecht is
Het is een van de oudste grappen op internet, eindeloos doorgestuurd van e-mailbox naar e-mailbox. Een softwaremagnaat - meestal Bill Gates, maar soms ook een ander - houdt een toespraak. Als de auto-industrie zich had ontwikkeld zoals de software-industrie, zegt de mogul, zouden we allemaal in auto's van $ 25 rijden die 1.000 mijl op de gallon krijgen. Waarop een automanager antwoordt: ja, en als auto's als software waren, zouden ze twee keer per dag zonder reden crashen, en als je belde voor service, zouden ze je vertellen om de motor opnieuw te installeren.
De grap omvat een van de grote puzzels van de hedendaagse technologie. In een verbazingwekkend korte tijd is software van cruciaal belang geworden voor bijna elk aspect van het moderne leven. Van bankkluizen tot stoplichten in de stad, van telefoonnetwerken tot dvd-spelers, van airbags voor auto's tot luchtverkeersleidingssystemen, de wereld om ons heen wordt gereguleerd door code. Toch werkt veel software gewoon niet betrouwbaar: vraag het aan iedereen die een computerscherm blauw heeft zien spoelen, waardoor urenlange inspanning is weggevaagd. Maar al te vaak zeggen software-ingenieurs dat code opgeblazen, lelijk, inefficiënt en slecht ontworpen is; zelfs als programma's correct werken, vinden gebruikers ze te moeilijk om te begrijpen. Kreunend onder het gewicht van baksteenachtige handleidingen, getuigen boekwinkelplanken in het hele land van de blijvende disfunctionaliteit van software.
Software is tegenwoordig gewoon verschrikkelijk, zegt Watts S. Humphrey, een fellow van het Software Engineering Institute van Carnegie Mellon University, die verschillende bekende boeken heeft geschreven over softwarekwaliteit. En het wordt steeds erger. Goede software is volgens Humphrey bruikbaar, betrouwbaar, foutloos, kosteneffectief en onderhoudbaar. En software is nu geen van die dingen. Je kunt niet iets uit de doos halen en weten dat het gaat werken. Volgens Edsger W. Dijkstra, emeritus computerwetenschapper aan de Universiteit van Texas in Austin, is de gemiddelde computergebruiker in de loop der jaren zo slecht geholpen dat hij verwacht dat zijn systeem voortdurend crasht, en we zijn getuige van een enorme wereldwijde distributie van door bugs geteisterde software waarvoor we ons diep zouden moeten schamen.
Jim McCarthy is genereuzer. De oprichter, met zijn vrouw Michele, van een opleidingsbedrijf voor softwarekwaliteit in Woodinville, WA, McCarthy is van mening dat de meeste softwareproducten de nodige functies hebben om het waard te zijn om te kopen, te gebruiken en te adopteren. Maar, geeft hij toe, alleen het extreme nut van software laat ons de enorme tekortkomingen ervan tolereren. McCarthy begint soms gesprekken op zijn school met een PowerPoint-presentatie. De eerste dia luidt: Most Software Sucks.
Het is moeilijk om de uniciteit van de problemen van software te overschatten. Wanneer auto-ingenieurs de auto's op de markt bespreken, zeggen ze niet dat voertuigen van vandaag niet beter zijn dan tien of vijftien jaar geleden. Hetzelfde geldt voor luchtvaartingenieurs: niemand beweert dat Boeing of Airbus slechte vliegtuigen maakt. Evenmin klagen elektrotechnici dat chips en circuits niet verbeteren. Zoals de technische historicus Henry Petroski suggereerde in zijn boek uit 1992: De evolutie van nuttige dingen , is voortdurende verfijning de gebruikelijke regel in technologie. Ingenieurs merken voortdurend tekortkomingen in hun ontwerpen op en repareren deze beetje bij beetje, een proces dat Petroski wrang omschreef als vorm volgt mislukking. Als gevolg hiervan worden producten stapsgewijs beter.
Software lijkt helaas anders. Je zou verwachten dat een programma met 45 miljoen regels, zoals Windows XP, het nieuwste besturingssysteem van Microsoft, een paar bugs bevat. En software-engineering is een nieuwere discipline dan werktuigbouwkunde of elektrotechniek; de eerste echte programma's werden pas 50 jaar geleden gemaakt. Maar wat verrassend en verbazingwekkend is, is dat veel software-engineers geloven dat de kwaliteit van de software niet verbetert. Als er iets is, zeggen ze, wordt het erger. Het is alsof de auto's die Detroit in 2002 produceerde minder betrouwbaar waren dan die van 1982.
Naarmate software steeds belangrijker wordt, zal de potentiële impact van slechte code ook groter worden, meent Peter G. Neumann, een computerwetenschapper bij SRI International, een particulier R&D-centrum in Menlo Park, CA. Alleen al in de afgelopen 15 jaar hebben softwarefouten een Europese satellietlancering verwoest, de opening van de enorm dure luchthaven van Denver een jaar vertraagd, een NASA Mars-missie vernietigd, vier mariniers gedood bij een helikoptercrash, een Amerikaans marineschip ertoe aangezet om een burgervliegtuig, en het stilleggen van ambulancesystemen in Londen, wat leidde tot maar liefst 30 doden. En vanwege onze groeiende afhankelijkheid van internet, zegt Neumann, zijn we veel slechter af dan vijf jaar geleden. De risico's zijn erger en de verdediging is niet zo goed. We gaan achteruit - en dat is eng.
Sommige softwarebedrijven reageren op deze kritiek door hun procedures te vernieuwen; Microsoft, gestoken door beschuldigingen dat zijn producten bugs bevatten, loopt publiekelijk voorop. Toch bestaan problemen met de kwaliteit van de software al zo lang en lijken ze zo hardnekkig ingebed in de softwarecultuur, dat sommige programmeurs het ondenkbare beginnen te denken. Tot hun eigen verbazing vragen deze mensen zich af of het echte probleem met software is dat er niet genoeg advocaten bij betrokken zijn.
Een gebrek aan logica
Microsoft bracht Windows XP uit op 25 oktober 2001. Diezelfde dag, in wat misschien een record is, plaatste het bedrijf: 18 megabyte van patches op zijn website: bugfixes, compatibiliteitsupdates en verbeteringen. Twee patches hebben belangrijke beveiligingslekken verholpen. Of beter gezegd, een van hen deed dat; de andere patch werkte niet. Microsoft adviseerde (en adviseert nog steeds) gebruikers om een back-up te maken van kritieke bestanden voordat ze de patches installeren. Kopers van de thuisversie van Windows XP ontdekten echter dat het systeem deze back-upbestanden niet kon herstellen als er iets mis zou gaan. Zoals de online Knowledge Base van Microsoft flauw uitlegde, werken de speciale back-updiskettes gemaakt door Windows XP Home niet met Windows XP Home.
Dergelijke misstappen, zeggen critici, zijn slechts oppervlakkige tekenen dat de ontwikkelaars van de software te gehaast of te onvoorzichtig waren om duidelijke gebreken te repareren. De echte problemen liggen in het basisontwerp van software, volgens R.A. Downes van Radsoft, een softwareadviesbureau. Of beter gezegd, het is gebrek van ontwerp. De populaire Visual Studio-programmeersoftware van Microsoft is een voorbeeld van de manier van denken van Downes. Door simpelweg de cursor over het Visual Studio-venster te plaatsen, ontdekte Downes, wordt de centrale verwerkingseenheid onzichtbaar versperd met duizenden onnodige berichten, ook al doet het programma niets. Het is catastrofaal. Het is totale chaos, klaagt hij.
Volgens Dan Wallach, een computerwetenschapper aan de Rice University, is het probleem niet het zinloze karnen van de processor - hij merkt tenslotte op dat de verwerkingskracht goedkoop is. Microsoft-software is ook niet bijzonder gebrekkig; critici gebruiken de producten van het bedrijf vaak meer als voorbeeld omdat ze bekend zijn dan omdat ze ongewoon slecht zijn. In plaats daarvan verraadt volgens Wallach de bloeiende, zoemende verwarring in Visual Studio en zoveel andere programma's hoe de technieken voor het schrijven van software de explosieve toename van de complexiteit ervan niet hebben kunnen bijhouden.
Programmeurs schrijven code in talen als Java, C en C++, die door mensen kan worden gelezen. Gespecialiseerde programma's die bekend staan als compilers, zetten deze code om in de reeksen enen en nullen die door computers worden gebruikt. Belangrijk is dat compilers weigeren code te compileren met duidelijke problemen - in plaats daarvan spugen ze foutmeldingen uit. Tot de jaren zeventig zaten samenstellers op grote mainframes die vaak dagen of weken van tevoren waren volgeboekt. Omdat ze niet wilden dat fouten vertragingen veroorzaakten, bleven codeurs - die in het begin meestal werden opgeleid als wiskundige of fysicus - laat in hun kantoor om hun werk uitputtend te controleren. Het schrijven van software leek veel op het schrijven van wetenschappelijke artikelen. Striktheid, documentatie en collegiale toetsing waren de gewoonte.
Maar toen computers wijdverbreid werden, veranderde de houding. In plaats van de code minutieus te plannen, bleven programmeurs de hele nacht wakker in hacksessies met cafeïne, waarbij ze constant de resultaten van de compiler weerkaatsten. Keer op keer spuugde de compiler foutmeldingen uit; de programmeurs zouden de fouten één voor één repareren totdat de software correct was gecompileerd. De houding van tegenwoordig is dat je elk slordig stukje code kunt schrijven en de compiler zal diagnostiek uitvoeren, zegt SRI's Neumann. Als het geen foutmelding geeft, moet het correct worden gedaan, toch?
Naarmate programma's in omvang en complexiteit groeiden, werden de limieten van deze code en fix-aanpak echter duidelijk. Volgens een meerjarige studie van 13.000 programma's door Humphrey van Carnegie Mellon maken professionele programmeurs gemiddeld 100 tot 150 fouten in elke duizend regels code die ze schrijven. Als we de cijfers van Humphrey gebruiken, zou het zakelijke besturingssysteem Windows NT 4, met zijn 16 miljoen regels code, dus met ongeveer twee miljoen fouten zijn geschreven. De meeste zouden te klein zijn geweest om enig effect te hebben, maar enkele - vele duizenden - zouden ernstige problemen hebben veroorzaakt.
Natuurlijk heeft Microsoft NT 4 uitgebreid getest voordat het werd uitgebracht, maar in bijna elke testfase zul je minder dan de helft van de defecten vinden, zegt Humphrey. Als Microsoft vier testrondes had doorlopen, een dure en tijdrovende procedure, zou het bedrijf maximaal 15 van de 16 bugs hebben gevonden. Dan krijg je zo'n vijf defecten per duizend regels code, zegt Humphrey. Dat is erg laag, maar de software zou nog steeds maar liefst 80.000 fouten bevatten.
Software-ingenieurs weten dat hun code vaak vol lacunes zit en ze zijn al lang op zoek naar nieuwe technologieën om ze te voorkomen. Om steeds grotere projecten zoals Windows te beheren, hebben ze een verscheidenheid aan technieken ontwikkeld, waarvan misschien wel de bekendste component-gebaseerd ontwerp is. Net zoals huizen worden gebouwd met gestandaardiseerde two-by-fours en elektrische voorzieningen, zijn op componenten gebaseerde programma's opgebouwd uit modulaire, uitwisselbare elementen: een voorbeeld is de bijna identieke menubalk bovenop elk Windows- of Macintosh-programma. Dergelijke gestandaardiseerde componenten zijn volgens Wallach niet alleen goede technische praktijken, ze zijn de enige manier om iets ter grootte van Microsoft Office te laten werken. Microsoft, zegt hij, was een vroege, agressieve promotor van deze aanpak - het is de beste technische beslissing die ze ooit hebben genomen.
Helaas, zeggen critici, zijn de componenten vaak aan elkaar gelijmd zonder echt centraal plan - alsof aannemers grote constructies probeerden te bouwen zonder blauwdrukken. Het is ongelooflijk, zegt Humphrey, dat het ontwerp voor grote softwareprojecten soms niets anders is dan een paar luchtbellen op de achterkant van een envelop. Erger nog, om marketingredenen verbinden bedrijven zoveel mogelijk functies in nieuwe software, waardoor de voordelen van modulaire constructie teniet worden gedaan. Het meest voorkomende voorbeeld is Windows zelf, waarvan Bill Gates tijdens een aprilsessie van de Microsoft-antitrustproef getuigde dat het gewoon niet zou werken als klanten afzonderlijke componenten, zoals browsers, bestandsbeheerders of e-mailprogramma's, zouden verwijderen. Dat is een ongelooflijke claim, zegt Neumann. Het betekent dat er geen structuur of architectuur of rijm of reden is in de manier waarop ze die systemen hebben gebouwd, behalve om ze zo gebundeld mogelijk te maken, zodat als je een onderdeel verwijdert, het allemaal zal mislukken.
Het gebrekkige ontwerp in de eindproducten weerspiegelt volgens critici een gebrekkige planning bij het maken ervan. Volgens een onderzoek van de Standish Group, een adviesbureau in West Yarmouth, MA, zijn commerciële softwareprojecten in de VS zo slecht gepland en beheerd dat in 2000 bijna een kwart werd geannuleerd, waardoor er geen eindproduct ontstond. De geannuleerde projecten kosten bedrijven $ 67 miljard; overschrijdingen van andere projecten brachten nog eens $ 21 miljard op. Maar omdat code en fix tot zulke uitgebreide, kostbare testrondes leiden, kunnen zelfs succesvolle projecten enorm inefficiënt zijn. Ongelooflijk, softwareprojecten besteden vaak 80 procent van hun budget voor het repareren van fouten die ze zelf produceerden - een cijfer dat nog geen rekening houdt met het nog duurdere proces van het leveren van productondersteuning en het ontwikkelen van patches voor problemen die na de release zijn gevonden.
Systeemtesten duren bijna de helft van het proces, zegt Humphrey. En zelfs als ze het eindelijk aan het werk krijgen, is er nog steeds geen ontwerp. Als gevolg hiervan kan de software niet worden bijgewerkt of verbeterd met enige zekerheid dat de updates of verbeteringen geen grote fouten zullen veroorzaken. Dat is de manier waarop software overal wordt ontworpen en gebouwd - zo is het in ruimteschepen, in godsnaam.
Is software een speciaal geval?
De potentiële risico's van slechte software werden grimmig geïllustreerd tussen 1985 en 1987, toen een computergestuurde bestralingstherapie-machine vervaardigd door de door de overheid gesteunde Atomic Energy of Canada een massale overdosis aan patiënten in de Verenigde Staten en Canada gaf, waarbij ten minste drie werden gedood. Bij een grondig onderzoek wees Nancy Leveson, nu een computerwetenschapper van het MIT, een groot deel van de schuld toe aan de gebrekkige software-engineeringpraktijken van de fabrikant. Omdat het programma dat werd gebruikt om de stralingsintensiteit in te stellen niet zorgvuldig was ontworpen of getest, veroorzaakten eenvoudige typefouten dodelijke explosies.
Ondanks deze tragische ervaring, zorgden vergelijkbare machines met software van Multidata Systems International uit St. Louis voor een massale overdosering van patiënten in Panama in 2000 en 2001, wat leidde tot nog eens acht doden. Een team van het International Atomic Energy Agency schreef de sterfgevallen toe aan het invoeren van gegevens op een manier die programmeurs niet hadden verwacht. Zoals Leveson opmerkt, mogen eenvoudige fouten bij het invoeren van gegevens geen dodelijke gevolgen hebben. Dus ook deze storing kan te wijten zijn aan ontoereikende software.
Programmeerdeskundigen zijn het erover eens dat dergelijke rampen schrijnend vaak voorkomen. Denk aan de Mars Climate Orbiter en de Polar Lander, beide vernietigd in 1999 door bekende, gemakkelijk te voorkomen coderingsfouten. Maar sommigen beweren dat software eenvoudigweg niet op dezelfde manier kan worden beoordeeld, gemeten en verbeterd als andere technische producten. Het is gewoon een feit dat er dingen zijn die andere ingenieurs kunnen doen die wij niet kunnen, zegt Shari Lawrence Pfleeger, een senior onderzoeker bij de denktank Rand in Washington, DC, en auteur van het volume van 2001 Software-engineering: theorie en praktijk . Als een brug een gewicht van 500 kilogram en een gewicht van 50.000 kilogram overleeft, merkt Pfleeger op, kunnen ingenieurs aannemen dat het alle waarden ertussen zal dragen. Met software, zegt ze, kan ik die veronderstelling niet maken - ik kan niet interpoleren.
Bovendien werken softwaremakers onder buitengewone eisen. Ford en General Motors maken al tientallen jaren hetzelfde product: een bak met vier wielen en een verbrandingsmotor. Als gevolg daarvan, zegt Charles H. Connell, voormalig hoofdingenieur van Lotus Development (nu onderdeel van IBM), hebben ze hun producten stapsgewijs kunnen verbeteren. Maar softwarebedrijven worden voortdurend gevraagd om producten te maken - webbrowsers in het begin van de jaren negentig, nieuwe mobiele telefooninterfaces vandaag - in tegenstelling tot wat eerder is gezien. Het is alsof een autofabrikant zegt: dit jaar gaan we een raket maken in plaats van een auto', zegt Connell. Natuurlijk zullen ze problemen hebben.
Het klassieke dilemma in software is dat mensen steeds meer en meer spullen willen, zegt Nathan Myhrvold, voormalig chief technology officer van Microsoft. Helaas, merkt hij op, betekent de constante vraag naar nieuwigheid dat software zich altijd in de bloedstollende fase bevindt, wanneer producten inherent minder betrouwbaar zijn. In 1983, zegt hij, had Microsoft Word slechts 27.000 regels code. Het probleem is dat het niet veel deed, wat klanten vandaag de dag niet zouden accepteren. Als Microsoft Word niet was blijven oppompen met nieuwe functies, zou het product niet meer bestaan.
Gebruikers zijn enorm onbewust, voegt Myhrvold toe. Bij Microsoft, zegt hij, eisten zakelijke klanten vaak dat het bedrijf tegelijkertijd nieuwe functies toevoegt en stopt met het toevoegen van nieuwe functies. Letterlijk, ik heb het in één ademteug, één enkele zin gehoord. We weten niet zeker waarom we zouden moeten upgraden naar deze nieuwe release - het heeft al deze dingen die we niet willen - en wanneer ga je deze drie dingen toevoegen?' En je zegt, Whaaat?' Myhrvold's sardonische samenvatting: Software zuigt omdat gebruikers het eisen.
Hogere normen
In januari deed Bill Gates een oproep aan Microsoft-medewerkers om betrouwbaar en veilig computergebruik tot hun hoogste prioriteit te maken. In wat het bedrijf bestempelde als een van zijn belangrijkste initiatieven in jaren, eiste Gates dat Microsoft het aantal defecten in zijn producten drastisch zou verminderen. Een maand later nam het bedrijf de ongekende stap om het schrijven van alle nieuwe code bijna twee maanden op te schorten. In plaats daarvan verzamelde het duizenden programmeurs tegelijk voor massale trainingssessies over betrouwbaarheid en veiligheid. Met behulp van enorme schermen in een gigantisch auditorium toonden bedrijfsleiders gênante fragmenten van gebrekkige code die door degenen in het publiek waren geproduceerd.
Het initiatief van Gates was blijkbaar geïnspireerd door de golf van kritiek die Microsoft in juli 2001 overspoelde toen een bufferoverloop - een al lang bekend type fout - in zijn Internet Information Services-webserversoftware de Code Red-worm duizenden van zijn zakelijke klanten het slachtoffer liet worden. (Bij een bufferoverloop ontvangt een programma meer gegevens dan verwacht - alsof men de ruimte voor een postcode invult met een 50-cijferig nummer. de gegevens daar, tenzij ze zorgvuldig worden geblokkeerd.) Twee maanden later maakte de Nimda-worm gebruik van andere fouten in de software om duizenden andere machines aan te vallen.
Gehavend door dergelijke ervaringen gaan softwareontwikkelaars steeds meer letten op kwaliteit. Zelfs toen Gates zijn troepen aan het verzamelen was, ontwikkelden denktanks zoals het Kestrel Institute, van Palo Alto, CA, correct-by-construct programmeertoolkits die programmeurs bijna dwingen om betrouwbare programma's te schrijven ( zie Eerste hulp bij foutieve code ). Bij Microsoft zelf werken codeurs volgens Amitabh Srivastava, hoofd van het Programmer Productivity Research Center van het bedrijf, met nieuwe, hogere talen zoals C# die bepaalde fouten niet toestaan. En in mei richtte Microsoft samen met NASA en 16 andere bedrijven het Sustainable Computing Consortium van $ 30 miljoen op, gevestigd in Carnegie Mellon, om gestandaardiseerde manieren te promoten om de betrouwbaarheid van software te meten en te verbeteren. Inspanningen op het gebied van kwaliteitscontrole kunnen veel opleveren: bij het helpen van Lockheed Martin bij het vernieuwen van de software in zijn C130J-vliegtuig, gebruikte Praxis Critical Systems uit Bath, Engeland dergelijke methoden om de ontwikkelingskosten met 80 procent te verlagen, terwijl het software produceerde die slaagde voor strenge examens van de Federal Aviation Administration met zeer weinig fouten.