Peter S. Magnusson
Förra året, 1994, var året som CD-ROM, virtual reality och Internet blev vardagsmat. Visst lever vi mitt i IT-revolutionen?
Nja. Vi firar snarare 50-års jubileum. Det var nämligen år 1944 som von Neumann arbetade i ENIAC-projektet, och i ett berömt memo formulerade grundidéerna till dagens datorer.
Eller är det till och med ett 150-års jubileum som passerats? År 1843 publicerade Lady Ada Lovelace sina kommentarer till Babbage:s Analytic Engine, vari några av de första programmen ingick.
Dagens persondator är 10000 ggr snabbare än de första digitala datorerna, men frågan är om vi kan programmera så värst mycket bättre eller snabbare än Lady Lovelace.
Speciellt när program blir riktigt stora så blir det besvärligt. Bland de mer katastrofala exempel kan nämnas USAs nya system för flygkontroll - fem år försenat och 8 miljarder dollar över budget - och datorsystemet för bagagehantering på Denvers flygplats har hittills inte fåtts att fungera. Kostnad: 10 miljoner kronor om dagen.
Studier av andra stora projekt är inte heller uppmuntrande: 90 procent kräver omfattande omarbete, och tar ändå 50 procent längre tid än projekterat. Sannolikheten att ett projekt misslyckas stiger med logaritmen på projektets storlek!
En dag kommer vi att inse att häri ligger en naturlag.
Orsaken är att mängden "buggar" är proportionell mot mängden kod. Idag är felsnittet kring 20 fel per tusen rader kod i vanliga projekt. Med befintliga metoder kan siffran förbättras avsevärt. Men de framgångsrika projekten har krävt rigorösa kontroller, som kostat 5000 kronor per rad kod.
För att komma runt dessa lamslående risker och kostnader har en mängd magiska metoder föreslagits genom åren: stukturerad programmering, Case, 4GL, objektorientering, komponentprogramvara, formella metoder, återanvändning, "inspection" och så vidare. Redan 1968 myntades begreppet software engineering för att beskriva den mognad som programmerare ansågs vara i behov av.
Men dessa idéer är bara modenycker. Formella metoder har lovat mirakel i årtionden. Återanvändning av kod är fundamentalt svårt för stora projekt på grund av kommunikationsproblem. Alltför strukturerade lösningar skapar prestandaproblem.
Programvara som komponenter är dagens lösen. Men ingen har lyckats visa att det är ett generellt fungerande koncept. De enda framgångsrika lösningarna har varit mycket begränsade teknologier, som Visual Basics VBXer. Som kontrast kan nämnas grafiska gränssnitt - när de lanserades kommersiellt hade fullt fungerande forskningsprototyper funnits i flera år.
Och slutligen verkar alla helt plötsligt tycka att C++ löser alla problem - det är det snabbast växande språket i datahistorien.
Vad alla dessa metoder och idéer egentligen går ut på är enkelt: programmera noggrant och strukturerat, och utnyttja datorns unika möjlighet att programmera sig själv. Detta visste redan Ada Lovelace.
Kort sagt, ingen av de här metoderna löser grundproblemet: stora projekt är oerhört komplexa. Och riktigt stora projekt klarar man helt enkelt inte av. Hittills har problemet inte direkt berört folk i allmänhet. Men stora system närmar sig vardagen. Redan idag har en rakapparat omkring 2 kbyte kod och en teve 500 kbyte. Och allt eftersom persondatorer blir snabbare och har mer minne, och en allt större marknad medger större utvecklingskostnader, så närmar sig problemet våra skrivbord. Ta Windows'95 som exempel. Den betatestades under 1994 av 20000 användare. Efter debaclet med Pentium så skräms man till ännu en betaomgång med 400000 testare. Hur många betatestare kommer Windows'97 att ha?
Och tro inte annat än att folk vill ha mer avancerade program. Både Microsoft och Wordperfect har släppt bantade versioner av sina ordbehandlare, utan att lyckas speciellt bra.
Problemet är att man i programutvecklingsjobbet strävar efter att få ner felfrekvensen. Men målet bör inte vara att minska felfrekvensen i samma takt som programmen växer, utan att skriva program som från början tål en ekonomisk felprocent!
Vi måste börja lära oss av den störste programmeraren av dem alla: Naturen.
Naturen har "programmerat" i flera miljarder år. Det finns visserligen bara fyra olika instruktioner, men redan en blygsam E.Coli-cell har 10 miljoner kvävebaser i sin DNA. En människa har 5 miljarder! Och dessa program är mycket feltoleranta.
Det finns en rad kännetecken för naturens lösningar. Duplicering äv vanligt: vi har inte en stor blodcell som distribuerar syre, utan väldigt många små.
Djur är liksom människan feltolerant på flera plan: flera celler i ett öga, två ögon, och flera individer i ett jaktlag. Det kan bli fel på alla plan samtidigt utan att funktionen "hitta byte" hotas. Eventuella prestandaproblem löses med massiv parallellism.
Forskningen har länge sneglat på naturens algoritmer. Bland idéerna kan nämnas neurala nätverk, genetiska algoritmer, och agenter. Neurala nätverk försöker efterlikna inlärningsförmågan hos människan hjärna. Genetiska algoritmer använder evolutionens principer för att mutera fram en lösning. Agenter efterliknar naturens packetering och borde väl närmast motsvara en bakterie, med det kanske är en lite väl elak liknelse.
Alla dessa anstängningar verkar lovande, och jag tror de är vårt bästa hopp om att tämja mycket komplicerade system.
Framtidens program kommer att bestå av många små moduler som tillsammans löser problem, emellanåt genom att pröva sig fram tills något fungerar, och hela tiden med ett öga på grannen.
Dilemmat är att dessa nya programmeringsmodeller kräver betydligt mer datorkraft än vad vi har idag. Vi är därför på väg in i en övergångsperiod där befintliga metoder inte klarar av nya stora system. Förbättringar av existerande metoder och koncept kan skjuta tidpunkten framför oss, men de löser inte problement.
Slutsatsen blir att den snabba ökningen i komplexitet hos våra vanliga applikationer kommer att sakta av de närmaste åren. Dessutom kan vi förvänta oss att flera riktigt stora projekt kommer att misslyckas helt.
Peter S. Magnusson
