Det tycks uppenbart att hårdvaruutvecklare gör rätt och mjukvaruutvecklare fel. I något centralt avseende.

Båda grupperna producerar källkod. Men när den förra gruppen är klar levererar den en produkt som både fungerar och har förutspådd prestanda. Dessutom levereras den enligt tidsplan.

Den senare gruppens misslyckas istället ofta i alla tre avseendena.

–Om man hårdrar det en smula: hur kommer det sig att hårdvara aldrig har buggar och mjukvara alltid har buggar? säger Erik Hagersten.

Det här är något som han grubblar över.

Magi och hokus pokus

Först ger han en varning. Han är visserligen professor i datorarkitektur på Uppsala universitet. Men de här funderingarna ligger utanför forskningen.

–Jag har inte siffror för att belägga detta, men jag har pratat med folk inom industrin och jag tror att jag uttrycker något som det finns en stor samsyn om.

Han tror är att det ytterst handlar om att det i många mjukvaruprojekt saknas en ingenjörsmässig attityd.

–Det är mycket magi och hokus pokus runt hur man konstruerar mjukvara. Medan det är mer metodik, verktyg och processer kring hur man skapar hårdvara – mer strukturerad testning och mer respekt för den komplexitet man hanterar.

Mjukvarubranschen, till skillnad från hårdvarubranschen, är trendkänslig.

–Ena stunden ska det vara ”agile” och alla kastar sig på det spåret. Sedan kommer ”team programming” som en ny modenyck. Eller objektorienterat eller Java. Och plötsligt ska det vara tvärtom – inte Java!

Hårdvaruvärldens metoder har förändrats förhållandevis stillsamt, utan dramatiska revolutioner över åren.

Det finns exempel på misslyckanden i hårdvaruvärlden, som processorn Rock, som Sun till slut gav upp efter förseningar.

–I det projektet kan du nog hitta motexempel på allt jag säger. Men då kommer misslyckandet också på förstasidan i tidningarna.

Traditionen bjuder att det första en nytillverkad processor gör när strömmen slås på, är att själv skicka ett meddelande till alla i projektet, för att elegant visa att den lever.

–När du slår på strömmen är det en sensation om hårdvaran inte bootar direkt. Jag har varit med om det ett par gånger. Men då är alla verkligen förvånade – folk avskedas!

En synlig skillnad mellan hård- och mjukvaruutveckling är det stora utrymme som testning får ta inom hårdvaruutveckling.

–På min tid var testare och utvecklare ungefär lika många i hårdvauprojekten. Och testarna kan nog vara ännu fler idag.

Lika mycket arbete läggs alltså ner på att utveckla kod för hårdvaran, som på att utveckla testkod som utmanar och försöker hitta hålen i systemet.

Testandet sker systematiskt från minsta komponent upp till systemet som helhet.

–Man försöker hitta buggarna i sin linda, i stället för att sätta ihop alla komponenter och vänta på att buggar ska uppstå i det färdiga systemet.

Det är inte antalet testtimmar i sig som räknas, utan att täckningen är komplett – även ovanliga scenarier – udda torsdagar, fullmåne – måste testas.

–Inom mjukvaruområdet när man sätter ihop alla komponenterna första gången, så vidtar en fas där man sitter och jagar buggar. Istället för att förvänta sig att allt ska fungera direkt.

–Och när strömmen av buggrapporter klingat av lite grand, slår man sig för bröstet och deklarerar att man har version . klar, säger Erik Hagersten.

Parallellism gör problemet värre

Systematiken på hårdvaruområdet – via simuleringar – har också som effekt att systemets prestanda blir förutsägbar.

–Medan det finns ökända exempel på mjukvarusystem som gått tio eller hundra gånger långsammare än tänkt. Och då sätter man sig ner i rådslag och funderar över vad man ska göra. Men beslut fattade tidigt kan ha en enorm effekt på prestanda!

Mjukvaruområdet – för att fortsätta generaliseringarna – är alltid på jakt efter en silverkula som ska lösa alla problem. Nya programspråk är en klassisk lösning.

Redan  deltog Erik Hagersten själv i ett projekt som skulle lösa utmaningen att programmera parallella processorer en gång för alla.

–Många smarta människor har ägnat många år att försöka hitta silverkulan. Visst, det kommersiella intresset har kommit först på sistone, men jag är skeptisk mot att det skulle kunna finnas en silverkula.

Han noterar att mjukvaruvärldens utmaning redan finns för seriell kod. Multikärnorna gör problemet etter värre, vilket Erik Hagersten och andra profeterat ett antal år.

–Programmen blir både svårare att testa och att debugga. En av förklaringarna är att systemen blir ickedeterministiska och buggar ofta inte kan återskapas i en ny körning.

Återigen ligger hårdvaruutvecklarna steget före. Enligt Erik Hagerstens syn på  saken har de utvecklat parallell kod sedan länge.

–Hårdvarubeskrivningen av en processor är inget annat än ett gigantiskt parallellt program. Den parallellism som dessa ingenjörer hanterar är i själva verket mycket större än den parallellism som hanteras i dagens mjukvara för multikärnor. Ändå kommer hårdvaran tillbaka buggfri – noll buggar!

Men hämmas kreativiteten?

Som den forskare Erik Hagersten är försöker han skjuta hål på sin tes – tänk om kvalitetsskillnaden är ett pris man betalar för någonting som också har en positiv sida?

Det finns en märklig skillnad i ”individuell variation i produktivitet” mellan hårdvara och mjukvara. En duktig mjukvaruutvecklare kan vara tio gånger mer produktiv än en dålig. Bland hårdvaruutvecklare är skillnaden snarare bara en faktor två.

–Det var en intressant upptäckt på Acumem när vi rekryterade programmerare – om man kunde få några av dem som är en faktor tio bättre, kunde det göra hur stor skillnad som helst.

–Det kanske är så att mjukvaruvärlden tillåter kreativa programmerare att vara enormt produktiva? Artister av det slaget kanske skulle vantrivas enormt av att stängas in i processer och fyrkantiga lådor?

Det finns lysande undantag i mjukvaruvärlden. Mjukvaran i flygplan och kärnkraftverk förväntas faktiskt fungera från start. Det är skillnad mellan programvara och programvara – kanske finns sammanhang där ingenjörskvalitet kostar mer än den smakar? Ingen dör om mobilspelet Angry Birds kraschar.

När man utvecklar säkerhetskritisk mjukvara används faktiskt processer, och det ställs krav på att programvaran granskas och certifieras till hög kostnad.

Mjukvara måste bli ingenjörskonst

Kostnaden att provtillverka en halvledare är avskräckande. En misslyckad ”spinn” innebär en försening på månader. Moores lag föreskriver hårda straff för förseningar – de ger konkurrenterna möjlighet att komma ikapp. Motsvarande straff finns inte på mjukvarusidan.

–Där får du bara ytterligare en liten bugg att hantera, i sinom tid. Och kanske en kund som blir lite sur och får boota om lite oftare. Men det är han så van vid redan.

En annan förklaring kan vara att det finns betydligt fler ickeprofessionella, icke utbildade utvecklare – bokstavligen vem som helst med tillgång till dator kan utveckla programvara.

Däremot avskriver Erik Hagersten tanken att mjukvarubranschens problem skulle bero på att området är såpass nytt – hårdvarukonstruktion är lika gammal.

Istället tror han att grunden till problemet är avsaknaden av ett ingenjörsmässigt förhållningssätt.

–Man måste acceptera att programvarukonstruktion är en ingenjörskonst. Som att bygga en bro. Man måste lägga ner de resurser som behövs för att förvissa sig om att konstruktionen är korrekt och använda sig av sunda processer i sitt arbete.

– Läran om detta kallas software engineering på engelska och programvaruteknik på svenska. Ett viktigt område för att få bukt med problemen.

Dessutom föreskriver professor Hagersten goda verktyg. Det är särskilt relevant inför den extra utmaningen att programmera de nya multikärnorna.

Han nämner svenskgrundade företaget Virtutech och dess simulator Simics. Den kan backa körningen och därmed göra avlusning av parallella system deterministisk.

–Ickedeterminismen är en av de otäckaste utmaningarna för parallell programutveckling.

På verktygsområdet är han också själv engagerad som affärsman. Det amerikanska företaget Rogue Wave har just köpt hans företag Acumem och dess cacheoptimerare. Rogue Wave har en portfölj av verktyg – från programbibliotek till debuggrar – för utveckling av parallell programvara.

–Nu talar jag lite i egen sak. Men det finns också en skillnad mellan mjukvaru- och hårdvaruutvecklare i det att de senare använder mer kommersiella verktyg.

–Den snabba fixen vad gäller multicore under de kommande åren är inte att vänta på ett språk som automatiskt parallelliserar, utan att använda mer kraftfulla verktyg.