Intervju med Lars Degerstedt

Intervjun genomfördes 29 mars på Linköpings universitet. Lars De- gerstedt har doktorerat i datavetenskap och undervisar och forskar vid Institutionen för datavetenskap, Linköpings universitet. Till hös- ten är han med och startar det nya kandidatprogrammet i Innovativ programmering vid Linköpings universitet. Nedan följer utdrag ur intervjun.

Problemrymd och lösningsrymd

LD: Där finns det ju en fundamental matematisk skillnad mellan problemrymden och lösningsrymden. Och det här det stora kreativa steget sker. Det är här det spän- nande sker när du går från problem till lösning. Och här finns ingen automatik alls. Det är här människan gör sin stora arbetsinsats, då man bygger system. Samtidigt som man då bygger upp förståelse kring problemet så hittar

man också en lösning. Eller ibland är det så att man ock- så kan förstå problemet i förväg och sen hitta en lösning efteråt. Det är ju lite olika det där, om det är stora och komplicerade problem, så måste man oftast upptäcka lösningen och problemet ihop. Det är väl en del av Naurs tanke, att man när man programmerar ett system så för- står man också problemet man utgick från.

Att utesluta lösningar

LD: I och med att du utesluter en lösning så har du of- tast lärt dig något mer om problemen, något som du inte hade tänkt på. Du hade antagligen en problembeskriv- ning som inte tog upp … något man måste ta hänsyn till. Därför var lösningen fel. När jag har insett det, då kan jag ta med mig den där erfarenheten tillbaks till problem- beskrivningen och säga att allt jag har sagt i problembe- skrivningen var rätt, men det var en observation som var kritisk, och som jag inte hade fått med tidigare.

Vattenfallsmodellen

LD: Det är många idag som jobbar med vattenfallsmo- dellen på vissa sätt. Man gör en kravspec först och sen implementerar man. Det ställer krav på den som ska an- vända den här processen att man måste lära sig att ställa kraven i förväg, innan man börjar realisera, det vill säga att det är svårare i någon mening. Och det löser man of- tast på företag genom att man har Senior Developers som har jobbat med det här i 20 år och en sådan person kan faktiskt ge en kravspec på förhand för så duktig är han på just den här typen av system. För han har gjort 200 sådana system, och de ser ungefär likadana ut allihop. Men när det blir mer explorativt, när det explorativa och innovativa inslaget ökar, då blir det svårare att jobba vat- tenfallsmässigt.

Iterativt arbete kontra vattenfallsmodellen

LD: Att iterera mycket kostar tid. Det är dyrt att iterera. Det är väldigt effektivt att jobba enligt vattenfallsmodel- len, om man bara gör rätt. Gör man fel blir det istället

oftast väldigt dyrt. Det betyder i princip att projektet ha- vererar, och du måste börja om igen. Medan en iterativ metod, med kortare iterationer, är mycket mer robust. Men den har en overhead i det här itererandet. Till viss del gör man om saker för varje varv. Med vattenfallsmo- dellen hade jag gjort det en gång för alla. Man lever i det gamla industriella tänkandet tror jag, det ska vara effek- tivt. Men sen blir kvaliteten sämre ibland.

Prototyper

LD: Det finns olika synsätt. Frågar du Alan Cooper skulle han sätta prototypen väldigt nära det här med krav och problem. Säger du prototyp till en mer programmerar- orienterad person från den agila metodiken, då tror jag att man hellre skulle säga att prototypen är den första lös- ningen. Prototypen är skissen på lösningen och har ing- enting med problemet att göra. Problemet är kravspecen, det är en kravinsamling. Men när det går till prototyp, det är just när vi tar steget över från problem till lösning. Och här vi får vi också problem för att man diskuterar lite förbi varandra.

Kompetens

LD: En dimension som jag tycker är viktig i Naurs syn- sätt är kompetens, det är en väldigt viktig aspekt. Och då menar jag kompetensen hos de som ska göra det här systemet, kompetensen hos de som ska bygga systemet i någon mening, antingen som en övergripande desig- ner eller som en konkret programmerare och så vidare. Alltså hur ser ditt team ut, vad har du för team? Du har ett team och nu ska du få teamet att fungera. Och det här är på något sätt ett självorganiserande team. Och då kan du inte komma och smaska på och säga att nu ska vi göra prototyper som är problembaserade här, om du har mest Perlprogrammerare. För de vill ha en lösningsorienterad prototyp, de vill ha nånting som hjälper dem.

Prototyper inom agil metodik

LD: Finns det överhuvudtaget prototyper i agil metodik? Det är mer tveksamt tycker jag om man kan tala om det. Agilt tror jag skulle säga så här: vi visade dem det riktiga systemet direkt, det är så här det ser ut idag. Vi håller på med ett forskningsnära projekt tillsammans med ett företag. Då började jag prata prototyp med dem, och då slår de ju bakut allihop. De vill inte ha någon prototyp. De har inte råd att hålla på med prototyper. De vill ha en färdig produkt på en gång. Allting vi gör måste gå rakt in i en färdig produkt, och det tror jag är väldigt vanligt. Det är alltså få förunnat att få hålla på med prototyper när man jobbar i företag som jobbar ganska agilt. Så det är därför man säger att den agila metodiken är som gjord för småföretag, till stor del. Företag som har en stor orga- nisation, som Ericsson, kan ju ha en hel avdelning med HCI-experter som gör prototyper. Men har företaget 20 personer totalt så har du inte råd att ha en person som håller på att göra prototyper på saker och ting.

LD: Man kan också tänka sig att frågan är om ska man ha en prototyp eller inte. Vad har man råd med, om man nu ser det som en kostnad. Allting kostar ju. Men du får alltid någonting tillbaks också. Om man säger att man lär sig genom att bygga saker, ja då skulle man kunna använda det som ett argument för att det är ett bra sätt att lära sig, att lära sig genom att experimentera.

LD: Man har en fas som är innan lösningen är tillräckligt bra. Innan man har en lösning, så har man en gråzon som är att man håller på att hitta lösningen. Det är den kreativa processen, och där skulle man möjligen kunna säga att man gör en viss nivå av prototyping. Men man skulle kunna kalla det något annat, man skulle också bara kunna säga att det är det här som är programme- ring. Det är ju problemlösning. Men prototyping skulle kunna vara ett bra ord när den är mer explorativ.

Agil metodik, prototypning och theory building

LD: Vad det handlar om, som jag ser det, är att skapa ett självlärande team, som hela tiden kompetensutvecklas under tiden som man jobbar. Och det är det som är det centrala. Det är nästan viktigare än det man gör, för att då kan man se det som en konsekvens. Blir du riktigt bra på nånting, då gör du bra saker. Så det viktigaste det är att hålla folk bra på det de gör.

LD: Om din metod inte är rolig så har du ett problem. Då kommer den inte funka i praktiken, i det moderna industriella klimatet. Det kanske funkade en gång i tiden då man gick på pliktkänsla, men idag är det få som kan jobba baserat på plikt. Därför är innovativitet så viktigt. Så där är det ett skifte i perspektiv på vad som är viktigt. Därför måste det vara roligt, för när det är roligt då gör vi kreativa saker. Är det inte roligt så är vi inte kreativa. LD: Och där tycker jag Peter Naur har den här insikten om att när man bygger ett system så händer det något inte bara i systemet, det händer något inte bara i doku- mentationen – alltså dokumentationen står inte för sig själv och kommer aldrig att göra det. Det som har hänt har hänt inne i huvudet på dem som har byggt systemet. Det är det fundamentala som har hänt. De här personer- na har byggt upp en teori om hur det här problemet och de här lösningen fungerar ihop. Och den teorin har vi i huvudet, och så finns den då avbildad nere i koden, men bara partiellt. Troligen så har vi en massa insikter som inte finns dokumenterade någonstans för att det hinner man inte så att säga, och det kanske inte skulle gå heller att dokumentera på den nivån. Det skulle också bli väl- digt oläsligt, det skulle bli väldigt tjocka böcker. Så där har man då människan istället. Så det blir ju ett perspek- tiv på, om man tar in prototyping i bilden då, om man har den synen på vad det är vi ska stödja. Är prototypen bra eller inte? Ja, det är ju bra om det stödjer att man lär sig, alltså att man får bra theory buildning. Och är det theory building-stödjande då får du antagligen bra cost-

benefit-balans där. Men om det inte är theory building på ett bra sätt så är det bortkastad tid.

Prototyper och kompetensutveckling

LD: Du måste jobba med de verktyg som du sen ska an- vända i projektet. Det ska vara relevanta saker, så vi ska till exempel använda Lucene, en sökmotor för Java, i det här projektet. Då skulle jag kunna ha som ett prototyp- projekt: gör något häpnadsväckande med Lucene! Det är jättekul och så gör jag min favorit, hemsida, website, nå- gonting som inte alls har med projektet att göra, men jag blir en hejare på Lucene. Sen tar jag den kompetensen och så flyttar jag över den till det här projektet, och helt plötsligt blir det superbra på en gång i det riktiga pro- jektet. Där finns det ju en spännande koppling mellan prototyping och kompetensutveckling tycker jag.

Detaljerade gränssnittsprototyper och kravspecar som hinder LD: De som får ett sådant material som utgångspunkt får en väldigt tråkig uppgift. Och i den här dubbla meningen som Naur säger, dels att dokumentation kommunicerar dåligt, den kommunicerar men det är oftast partiellt. Du får oftast frågetecken, vad menar de med det här ordet, vad menar de med den här meningen? Eller en bild – vad menar de med den här bilden? Hela tiden kommer du att stöta på detta, och även om man går till källan så kanske det visar sig att «Aha, det hade jag inte tänkt på!» Och då är det ju nån som har gett sig in och tyckt saker utan att ge hela svaret. Och sen ska du ta över som sagt. … Det är en väldigt bra fråga egentligen, alltså både som hinder och möjlighet. Också det om man gör prototyper som inte passar, och får man då en prototyp, någonting som någon annan tyckte att det var jättekul att göra och fick leva ut sin konstnärliga sida, någon som gillar att måla och så vidare. Och så ger du den till en Perlprogram- merare. Det är ju en förolämpning i två steg. Dels är det tråkigt, dels är det som att säga «Hej, jag förstår inte dig. Så jag förstår inte vad du behöver.» Det är det det signa- lerar. Det signalerar att den som har gjort prototypen har

ingen aning om vad den här programmeraren behöver för att kunna utvecklas. Man har gett helt fel saker, och det är ju väldigt vanligt i det här kriget, som man säger, mellan utvecklingsavdelningen och andra avdelningar. Agil och traditionell utveckling

LD: En skillnad mellan agilt och traditionellt är att i agila företag är ju oftast alla programmerare. Man har alltså bara en sorts människor, yrkesrollsmässigt. Så man har en ganska rund kompetensprofil. Sen kan man ha olika specialiteter, men man har ändå en kärna där alla delar samma värden. Sen kan de välja olika inriktning på den här programmerarkompetensen, men det är ett medvetet val. Många andra har mer traditionella approacher; då har man väldigt olika sorters människor, med olika kom- petens, sub-kompetenser, så man har lång utbildning och har specialiserat sig på något, och sedan ska de här män- niskorna försöka samarbeta med varandra. Och då blir det ett kommunikationsproblem. … Prototypa eller inte, det kanske inte spelar någon roll hur bra prototyp du gör för att de här människorna kommer alltid ha problem att kommunicera med varandra för att de har för olika er- farenheter. Den ena kommer hela tiden ge postit-lappar som lösningar, och den andra kommer att säga att jag vill inte ha postit-lappar. Och sen kommer man inte vidare. Prototyper och kostnader

LD: Kanske är det så att de som vill ha mycket prototyper oftast är problemorienterade individer. Medan lösnings- orienterade individer vill ha minimalt med prototyper. … Den ena gillar det och vill dra ut modellerna och göra komplicerade saker, för det kostar ingenting på papper. Medan den som bygger sakerna, för den kostar varje sak flera veckors arbete, så att varje sak som ska in i verksam- heten avväger man väldigt noga. Är det värt att ta steget? Ska vi verkligen göra en prototyp i det här projektet? Det skulle vara en stor fråga för en lösningsorienterad indi- vid då, medan för en problemorienterad individ så kan det vara «ja, jag kan gärna göra en prototyp». … Frågan

är då om det är så att det finns en tredje väg här så man kan få med på något sätt att man inte har en prototyp i traditionell mening. Men man gör en prototyping. Om vi tar Highsmith med det innovativa synsättet på utveck- ling: Där kan man se att man ständigt experimenterar när man utvecklar ett system. Och det skulle man ju kunna kalla för prototyping, eller i alla fall något besläktat. Experimentell utveckling

LD: Man kanske inte har något som heter prototyp egent- ligen, alltså det begreppet blir inte så centralt, utan ef- ter den här experimentella fasen så får man ett, kanske partiellt, men fungerande system. Och Highsmith säger då att det viktiga är att metodiken stödjer experimentellt arbete. Så i den meningen kan man ju säga att den agila metodiken stödjer prototyping. Men däremot så använ- der man inte begreppet prototype så mycket. Han har hoppat över det mellansteget.

Figur 14. Den ursprungliga versionen av begreppsmodellen inklusive anteckningar under intervjun med Lars Degerstedt.

prototyp problem lösning krav system användare designer teorier praktik

kompetens

prototype

dokument

stakeholder

intressent

handling

prototyping

?

?

?

kreativ process

LD: En annan intressant sak om man jobbar experimen- tellt är att man ju måste inse att man kan inte göra desig- ner «up front» längre. Man vet inte vart projektet kom- mer att ta vägen. Det är dessutom så att man kan inte lägga fasen i början ens, för att varje dag under projektets gång kommer man att vara experimentell. Man börjar experimentellt, man kommer att sluta experimentellt. Men det som blir viktigt då, och där kopplar det lite till lean production, det är att man måste ändå ha en förut- sägbarhet i att processen måste generera bra saker. Det får inte vara så att man misslyckas. Begreppet misslyckas får inte finnas så att säga, utan det måste vara förutsäg- bart att den här processen kommer att spotta ur sig bra saker i ett jämnt tempo. Men exakt vilka de här sakerna är, det är det vi inte vet. Vi vet att vi har en bra process, och det här det ska vara roligt, det ska vara kreativt och så vidare.