När jag läste data runt 2000 så fattade jag ingenting av vad vi fick lära oss om processerna runt själva kodandet. På OS-kursen fick vi skriva en kravspecifikation och ett design-dokument, vilket vi skulle lägga lika mycket tid på som kodandet och testningen. Eftersom specifikationen naturligtvis visade sig vara omöjlig att implementera utan ändring så fick vi uppdatera den allt eftersom vi upptäckte problem. På kursen som hette Software Engineering så fick vi lära oss en väldig massa detaljer om metoder för att ta fram specifikationer av olika slag.
Jag vet inte riktigt var de här avancerade metoderna används, men jag föreställer mig att det rör sig om hemliga försvarsanläggningar, kärnkraftverk, banker och myndigheter. Jag kände absolut inte igen mig från de open source-projekt jag var bekant med. Däremot visste jag att akademiker var av uppfattningen att en utvecklingsmetod som den som användes för Linux-kärnan helt enkelt inte kunde fungera. Det gjorde att de inte kändes helt trovärdiga.
Agile fanns redan på 90-talet, och en gästföreläsare från Nya Zeeland la i alla fall någon föreläsning på att lära oss om Extreme Programming. Under 00-talet har Agile slagit igenom, men kursbeskrivningen för Software Engineering i Uppsala ser fortfarande ut som den gjorde för 10 år sedan. Samma kursbok används dessutom, Software Engineering av Ian Sommerville.
Jag tog fram mitt exemplar, 3 upplagor gammalt, och bläddrade lite i det. De avsnitt som innehåller något som jag skulle kunna tillämpa är minimala, om de finns över huvud taget. Jag kollade upp vad som har förändrats under de senaste upplagorna, och det verkade inte vara mycket, även om det har tillkommit ett kapitel som under rubriken "Rapid Software Development" bland annat tar upp Agile, exemplifierat av Extreme Programming.
Jag tittade igenom de slides som finns tillgängliga för nedladdning. Författaren är inte positiv till Agile. Agile används för att utveckla mjukvara fort, men leder till sämre kvalitet. Och det är svårt att testa, för det finns ingen specifikation. Det är svårt att avgöra vad som har gjorts, för det finns ingen dokumentation. Koden blir svår att underhålla, för om man gör ändringar hela tiden så går strukturen sönder. Principen att hålla designen så enkel som möjligt är också problematisk: "Maintaining simplicity requires extra work". Och så går det givetvis inte att skala upp Agile till större projekt: "Agile methods are probably best suited to small/medium-sized business systems or PC products." Damn, den gamla klassikern, riktig utveckling sker på mainframes. Hemliga försvarsanläggningar och banker var det.
En av anledningarna till att Agile har tagit över under de senaste 15 åren är att all utveckling inte längre sker på storföretag eller myndigheter. Utvecklarna har makt över sin situation, snarare än att det är en kille i slips sju nivåer upp från närmsta ingenjör i hierarkin som bestämmer hur det ska gå till. Men bland de gamla akademikerna så skrivs fortfarande all riktig kod i Cobol och Ada, och handlar om pengatransaktioner. Designspecifikationen specificerar arkitekturen hela vägen ner till algoritmer och datastrukturer. Programmeraren översätter specifikationen till program. Moduler utvecklas parallellt och integreras först framåt slutet av projektet, precis innan den livströtte testaren kallas in, hittar fel och får skäll för att han är ansvarig för att projektet blir försenat (han gästföreläste på Software Engineering-kursen, och beskrev sitt arbete just så). För projektet blir försenat, det blir det alltid. Och lösningen heter ännu mer detaljerade specifikationer, som gärna ska verifieras formellt, så att den kan implementeras rätt av utan att en enda bugg uppstår, att ett enda krav ändras under projektets gång eller att ett enda tankefel upptäcks.
Ett problem jag hade både med Software Engineering och på andra kurser var att det aldrig berättades hur, var och när saker tillämpas. Idéerna är alltid abstrakta. Av den anledningen vet man inte vad som är viktigt, vad man faktiskt ska lära sig, och vad man kan glömma bort, eftersom det bara är av akademiskt intresse.
2009-12-29
Vilse i vattenfallet
Prenumerera på:
Kommentarer till inlägget (Atom)
5 kommentarer:
haha, när jag flyttade kastade jag Ian Sommervilles bok i soporna. 10 år utan användning fick vara nog. :D
Jag lade Ian Sommerville i soporna när jag kastade flytt senast!
Ian Sommerville - vilken sopa!
[wv: dista]
Programledaren för Åtta Dagar är en sopa, så mycket vet jag. Annars är lösningen på diskrepansen mellan yrkeslivet och skolan en extra inriktning på entreprenörskap, tror jag. Studenterna måste lära sig att gå den där extra milen och exempelvis verifiera sin OS-kod mha det de lärt sig i semantiken.
WV: cysidom
Skicka en kommentar