Intervju med Mårten Herberthson

Intervjun genomfördes 17 april hos Lawson i Linköping. Mårten Herberthson arbetar som domänarkitekt och projektarkitekt hos Lawson. Nedan följer utdrag ur intervjun.

Prototypning och design

MH: Min erfarenhet av prototyper är den att jag upp- lever att den faktiska användningen av prototyper och hur man kanske förväntas använda prototyper i utveck- lingsarbetet inte riktigt stämmer överens. Ofta kan man ju till exempel tänka att man först ska göra en design, man kanske gör en prototyp som hjälper en att göra en design eller validera designen och så vidare. Och sedan kanske man till och med förväntas kasta en prototyp. … Men min erfarenhet är mer att man gör inte en design, i den bemärkelsen att man gör det på ett papper först. Det kanske man gör väldigt schematiskt, så att man får en mer konceptuell design, på ett väldigt övergripande plan. Men så fort man kommer ner till detaljfrågor sätter man sig helt enkelt ner och kodar en prototyp. Och det vävs samman med designarbetet, så att designen och prototy- pen går parallellt.

MH: Angående det här med att kasta prototypen och bör- ja om: Jag har varit med om det några enstaka gånger, men då är det mer beroende på att man helt enkelt under prototypfasen insett att man är helt fel ute. … Däremot om man upplever att det här har funkat ganska bra, då utvecklas prototypen helt enkelt till att bli den slutgiltiga produkten.

Happy days

MH: Ofta är det så att om jag ansvarar för att ta fram en ny produkt försöker jag göra det vi kallar ett happy days-scenario. Det är en konstig term egentligen. Det är

Kruchten som för länge sedan var på besök här och lärde oss hur man gör UML-diagram. Nu använder vi inte UML- diagram så mycket, men en idé som han hade när det gällde prototyping var väldig användbar tycker vi. Låt oss säga att du ska ta fram en produkt där till exempel per- formance är det centrala. Då gör man en prototyp där det första målet med prototypen är att få ett komplett flöde, även om flödet har massor av brister. Den kanske inte har felhantering, den har inte specialhantering för något udda fall, utan bara det enklaste flödet som ändå är det som applikationen oftast gör. Och det är det som kallas happy days-scenario: Allt går bra, och det finns inget be- hov av felloggning. Det finns inget behov av sådana sa- ker. Och tanken är då att man så snabbt som möjligt får upp det här happy days-scenariot, att man så snabbt som möjligt kan börja mäta på saker som ger den här desig- nen tillräckligt bra performance. För det var det som var det viktiga för mig i det fallet. Och man kan helt plötsligt börja göra lite mer problematiserade tester, och vartefter man då får mätvärden på det här kan man använda dessa i arbetet. Om jag måste gör en omdesign någonstans, så kan jag direkt få feedback, om den här omdesignen inne- bär att performance ändrades antingen negativt eller för- bättrades.

MH: Ganska tidigt försöker vi göra en prototyp som, även om det är väldigt tunt, går hela vägen igenom. Applika- tionen gör vad den ska. Målet med det är ju att så tidigt som möjligt upptäcka allvarliga brister i sin design. Här ser man ju också igen hur prototypandet och designan- det vävs samman i någon mening. … Jag utvecklar pro- gram på serversidan. … Om man däremot arbetar mer på klientsidan, då kan det ju finnas behov av att göra pro- totyper av lite andra skäl. Man kanske vill göra en pro- totyp för att visa för kunden hur det kommer att se ut. Man kanske vill mäta användarinteraktioner och sådana saker. … För mig handlar det mer om performance, skal- barhet, att koden löser funktionaliteten som den ska.

Designprocessen

MH: Jag har lärt mig av ren erfarenhet att om man sitter för länge och designar på papper, så är det bortkastad tid, för det visar sig alltid att när man väl börjar koda att det kommer saker som man inte har tänkt på. Så det gäller att designa på papper, när syftet med pappret är till ex- empel att skaffa sig en samsyn i projektet om vad det är vi ska göra. Så att man måste ha en whiteboard eller ett papper där man bollar idéer och får en gemensam bild av det är det här vi vill göra. Men när alla är överens om vad som ska göras, då är det bättre att börja koda och hitta problem. Det kanske dyker upp specifika problem som man går tillbaks till och börjar designa på papper. … MH: Jag har ibland jobbat i projekt där man försöker följa till exempel RUP-processen. Det sägs ju alltid när man klagar på RUP, att RUP är helt konfigurerbart, att det är fel på din konfiguration om du tycker att processen är dålig. Men jag håller inte riktigt med, för att i alla fall i den normala tolkningen av RUP har man olika roller som gör olika saker. Jag har varit med i situationer där jag har rollen som arkitekt eller designer i ett projekt, se- dan så kanske vi har en nyanställd person där jag också har ansvar för att vara hans mentor. Rent projektmässigt är jag arkitekt kanske, och jag förväntas göra designer. Sedan på ett helt annat plan så är jag dessutom mentor för en person som jag ska försöka lära upp. Och då enligt RUP så är det så att jag kanske ska göra en design, och sen ska jag sätta den i näven på den här personen, och han ska kanske implementera den. Men det strider mot min fundamentala målsättning när jag är mentor. Om jag gör allt tankearbete och sen sätter en färdig lösning i näven på honom och han bara ska stansa ner det så att säga, då kommer han inte att lära sig någonting. Så jag anser att det är mycket så att varje individ så att säga får hantera hela cykeln: här har vi ett problem, både designa lösningen och implementera den. Hela den här cykeln med att göra testkod och ta fram en design, det får han då lösa för då kan jag få honom att utvecklas. Så att här pågår det ju saker i olika skalor så att säga. Det finns en

liten sak, en större sak, och hela systemet kanske. Så att arkitekten kanske mer ansvarar för designen av att hela systemet hänger ihop, men inte designen ner på detalj- nivå i varje läge.

AN: Det är ju en allmän fråga inom utveckling att det sit- ter en person och gör en väldigt detaljerad specifikation, och sen lämnar över till någon annan som «stansar ko- den» så att säga. Det är ju ett upplägg som förespråkas. MH: Ja, och jag är totalt emot det, därför att jag anser att för personerna som sitter och bara kodar ser man ju inte till att de utvecklas maximalt så att de är så nyttiga som möjligt för företaget. Den enda situation där jag kan tänka mig att det där är relevant, det är om man har en outsourcingsituation med Indien till exempel. Man mås- te göra en väldigt exakt design och sen skicka till någon som kodar. Men inte ens då tycker jag att det är bra för att min erfarenhet, rätt eller fel, är trots allt att enda sättet att få designen att bli korrekt, det är att göra en prototyp. Så om jag har gjort en prototyp, då är frågan varför ska jag skicka den till Indien, jag kan lika gärna göra klart det sista själv. Enda skälet till att … man ska lägga ner väldigt mycket tid på att designen ska bli korrekt innan man ska börja koda, det är … frågan om hur dyrt det är att kor- rigera fel senare i processen. Jag förstår mycket väl att om NASA skickar iväg en satellit som är svår att reparera i efterhand så måste man tänka efter mycket i förväg. Men när man tar fram mjukvara så kan man göra tester innan man skeppar den till kund, och man kan till och med rätta buggar efter leverans. Det påverkar lite grand vad som är mest kostnadseffektivt så att säga.

MH: När jag leder ett projekt som arkitekt är jag väldigt fokuserad på risker. Jag försöker alltid attackera det som är störst risk först. Och då kommer man in på det här med kostnaden för att göra en rättning. Låt säga att rätt- ningen är att i user-interfacet så har vi felstavat ett ord, det är relativt enkelt och relativt billigt att fixa. Men låt säga att designen på servern är fel, vi valde en stateful

vi inte skala ut till många samtidiga användare. Det är ju en jättestor kostnad. Det krävs antagligen en total rede- sign. Så att det är ju en stor risk då. Om jag upplever att det är en stor risk att skalbarheten inte blir tillräckligt bra, då kommer jag genast börja mäta på det så tidigt som möjligt. Så prototypen syftar då till att ta bort de här stora sakerna, som blir väldigt, väldigt dyrt att korrigera sedan.

MH: Vi har ju ständigt behovet av att alla våra applika- tioner måste gå att internationalisera. Det är ett ganska komplext område. Det är komplext att förstå problem- bilden som vi har, och att se till att det fungerar. Men å andra sidan, när man väl har tagit sig över den tröskeln, då kan man gå ganska mycket på rutin. Man har en lös- ning som fungerar sedan tidigare och den kan man ta med sig.

Utvärdering

AN: Brukar det vara så att det är nån annan som utvärde- rar ens prototyper, eller utvärderar man dem själv? MH: Man kan väl säga att det är både och i den bemär- kelsen att man utvärderar själv först … Och sedan går det vidare till ens projektmedlemmar. Men det är nog inte någon formell granskning. Ibland förekommer det att vi gör en formell granskning, men då kan det vara ett specifikt syfte med det. Vi har det inte som ett obligato- riskt steg, men det händer att vi gör det, men då beror det ofta på att vi har ett specifikt behov, att det funnits ett problem. … Vi har formella granskningssteg, fast det har inte så mycket med prototyperna att göra, utan mer med när produkten närmar sig leverans. Då är det ju formella tester och det är acceptanstester av kunder och så vidare. Men vi har inte formella sådana steg under själva proto- typandet.

Dokumentation av prototypning och designval

MH: Vi dokumenterar vissa val, men skälet är kanske ib- land så att säga lite mer tråkiga skäl än goda skäl. Om

vi står inför ett val, och till slut så har vi en lång tanke- verksamhet kring det. Det kanske finns en grupp inom organisationen som förespråkar det ena valet, en annan grupp som förespråkar det andra valet. … Och sedan så har man någon form av brainstorming omkring det här, och någonstans så leder det fram till någon form av be- slut: Vi går på det spåret. Då kan det rent av vara att man gör så för att slippa trassel. För den här gruppen som inte tyckte att beslutet var bra, de kommer hela tiden att ifrå- gasätta: «Varför gjorde ni det här valet?» Då är det av ren erfarenhet bra att dokumentera hur man gjorde det där valet. … Men annars har vi ganska lite dokumentation … i och för sig, implementerade testfall är ju i någon mening en form av dokumentation. Och sedan har vi ju också ofta dokumentation på övergripande design för att man kanske hamnar i olika möten, man måste ändå visa en PowerPoint-presentation som förklarar vad som kom- mer att ske. Så på den nivån finns det ju alltid lite materi- al. Sedan, ju närmare man kommer färdig produkt, desto mer formell dokumentation uppstår. Det blir ju då doku- mentation för hur man installerar det, hur konfigurerar man, hur använder man det och sådana saker. Så att visst dokumenterar vi, men man kan säga att ju tidigare man är i cykeln, desto mindre formellt är det, och ju närmare man kommer slutet desto mer formellt är det.

AN: Jag tänker på att det här är ju någon slags kunskaps- utveckling, man utvecklar kunskap kring det man ska bygga. Och risken blir ju då att man upptäcker någon- ting med en prototyp, och därför väljer man ett nytt spår. Men om inte det är dokumenterat, då kan det ju hända att man ännu längre fram börjar böka med det här och tycker att så här borde man ha gjort. Och så gör man om det från ett spår som du kanske varit inne på, men som inte fungerade. – Man utvecklar kunskap i samband med prototypandet, men tar man tillvara på den?

MH: Det där är ett problem. Jag vet ju i vår grupp till ex- empel, vi har ju individer som till exempel har varit med om att driftsätta sådana här applikationsservrar hos kun- den. Och nu när vi implementerar en ny, vi håller precis

på med en ny version av den här, så bland de möjliga lös- ningarna så plockar de rent automatiskt vissa lösningar som de av erfarenhet vet fungerar ute hos kund. För att de vet att den där lösningen kan se jättebra ut på ytan, men vi vet att vissa kunder i Sverige kör på det sättet och det blir inte bra. Och det är ju en jätteviktig kunskap som den personen besitter, men den är inte dokumenterad. Och inte ens efter att han har gjort valet så dokumenterar han ner varför, utan för honom är det bara en självklar- het.