Överdesign
En vedertagen uppfattning är att en majoritet av ett systems användare utnyttjar mindre än tio procent av systemets funktioner. Vi utvecklare har dessutom har en förkärlek att bygga ”snygga”, generella lösningar med motiveringen att det kanske kan underlätta när systemet ska byggas ut någon gång i framtiden. Tillsammans ger det en minst sagt diger kodbas som i princip aldrig används men som ändå initialt utvecklas till en onödig kostnad och som därefter dagligen måste ändras, underhållas och buggrättas.
Jag utvecklade en gång ett system som kördes hos drygt ett 100-tal olika kunder i fem länder. En lugn sommar fick en systemansvarig hos en kund för sig att, via systemets administrationsgränssnitt, testa samtliga funktioner och felrapportera allt som inte fungerade. Många felrapporter på ”bra att ha”-funktionalitet som ingen någonsin använt, många rättningar som skulle patchas ut till samtliga kunder och väldigt många timmar som kunde använts till en vettigare arbetsuppgift.

Dåliga arbetsförhållanden
Utvecklare i allmänhet och konsulter i synnerhet får ofta finna sig i att arbeta i stora, högljudda lokaler alternativt sitta på ”platsen som är över”. Jag har själv blivit placerad i såväl kylskåp som i serverhallar, fikarum och på ”fabriksgolvet” med automatiserade robotar som pep och tjöt runt öronen på mig. Traditionella placeringar som stora, öppna kontorslandskap är självklart bättre än ett åttagradigt brummande kylskåp men det är fortfarande resursslöseri.
Rätt yttre förutsättningar, som ett tyst, eget rum åt utvecklingsteamet, stora bildskärmar och bra skrivbord ska absolut inte undervärderas och kommer garanterat höja produktiviteten med så mycket att den extra omkostnaden sparas in mer eller mindre omgående.

Tummande på kvaliteten
Ett dåligt kvalitetsmedvetande kan sänka de flesta projekt och det är dessvärre ofta kvaliteten som är det första det tummas på när tiden börjar tryta. Plötsligt skrivs det inga automatiska tester, kod checkas in utan kodgranskning, demon ställs in och de vackra kvalitetsmålen blir till en hägring vid horisonten. Istället ägnas allt mer tid åt snabba ”quick and dirty”-fixar. Förr eller senare kommer detta beteende innebära att teamet får ägna mer tid åt att släcka bränder och rätta buggar än åt att bygga ny funktionalitet som skapar mervärde.

Många bollar i luften
Så länge som det rör sig om saker som kan göras med rent muskelminne så kan säkert vissa göra flera saker samtidigt, i övriga fall är den mänskliga förmågan till multi-tasking en myt. Allt handlar om att byta kontext, vissa gör det snabbare än andra men rent generellt tar det tid, mycket tid. Att tvinga en utvecklare hoppa mellan projekt eller sitta på dubbla eller till och med trippla stolar blir i det långa loppet en enorm tidstjuv. Det är inte en slump att exempelvis Scrum förordar en ScrumMaster vars kanske viktigaste uppgift är att skydda teamet från utomstående så att utvecklarna kan fokusera till 100 procent på en enda uppgift.

Svaga utvecklare
Jag är ledsen att säga det men jag har sett alltför många exempel på individer som kostar projekt mer än de tillför. Oavsett om den bakomliggande orsaken är brist på kompetens, låg motivation eller att personen helt enkelt inte är menad till att vara utvecklare så är det många gånger bättre att ha en tom plats i projektet än att fylla på med folk som inte passar in. De kommer ändå bara att skapa frustration och merarbete för övriga utvecklare, agera bromskloss för hela projektet och sannolikt skapa lika många buggar som övriga teamet tillsammans.

Sluta planera under tidspress
När deadline närmar sig och arbetsbördan känns övermäktig så är det minst rationella som kan göras att sluta planera. Nu, om någonsin, är det viktigt att planera och prioritera så att om inte alla uppgifter blir klara i tid så blir åtminstone några det. Dessutom då de uppgifter som ger mest affärsnytta för verksamheten. Istället tenderar vissa team att sluta planera, ”det är viktigare att jobba så vi blir klara”, vilket ofta slutar med sex utvecklare som har sex ”nästan klara funktioner”. Projektet lyckas därmed inte leverera någon affärsnytta alls.

Produktivitetsökande åtgärder
Många projektledare verkar vara av den åsikten att produktivitet hänger samman med antalet utvecklare och antalet nedlagda arbetstimmar. Lösningen när deadline är på väg att missas är därför många gånger:

A – Fylla på med fler utvecklare.
B – Be befintliga utvecklare att jobba övertid.
C – En kombination av de båda.

Att fylla på med folk i slutet av projekt låter kanske vettigt i teorin men i praktiken är det som att be nio kvinnor föda ett barn på en månad, det kommer helt enkelt inte att fungera. Tiden det tar att introducera nya personer i projektet och kostnaden för den ökande kommunikation som krävs vid en större utvecklarstyrka kommer att äta upp de tillförda mantimmarna med råge.
Vad det gäller övertid så finns det en rad undersökningar som visar att maximal prestation nås vid 37-40 timmars arbetsvecka, jobbar folk mer så presterar de mindre. Att beordra övertid är därför det kanske mest kontraproduktiva som kan göras. Produktionstakten kommer att vara lägre och kvaliteten sämre än vid normal arbetsbörda.

Eric Evans om 2015

Torsdagen har varit mycket inspirerande. Den startade med en keynote av Ralph Johnson (en av Gang of Four) som satte mönster i objektorienterad design på kartan. Ralph diskuterade hur utveckling skiljer sig åt när en programvara skall leva länge kontra dö snabbt. Skillnaderna är stora. En levande programvara behöver underhållas med varsam hand för att kommande generationer av utvecklare skall kunna arbeta vidare.

Kevlin Henney (delförfattare till Pattern Oriented Software Architecture-serien av böcker) diskuterade mönster, och hur viktigt det är att känna till konsekvenserna av att applicera ett mönster. Särskilt de negativa konsekvenserna. Singleton är förutom ett designmönster även en whiskysort, och enligt Kevlin är spriten att föredra framför designmönstret när man designar system…

Eric Evans (Domain Driven Design) höll två mycket intressanta föredrag, dels om framtiden (What will not change by 2015) så som han såg den, dels om hur man kan arbeta strukturerat med DDD i en Agil uvecklingsmiljö (Folding design into an Aglie Process). Den sistnämnda presentationen var av mycket hög kaliber, med bra tips om vilka signaler man kan lyssna efter när det är dags att ta ett steg tillbaka för att arbeta fram en bättre design. Presentationen filmades, så jag hoppas den kommer upp på nätet så alla intresserade kan ta del av den.

Mer från QCon kommer!

/Emil

Dan Ingalls håller keynote 40 years of fun with computing

Onsdagen har varit full av aktivitet här på QCon.

Vi startade med en mycket underhållande keynote med Robert ”Uncle Bob” Martin som pratade om dålig kod, software craftmanship på ett mycket fängslande sätt. Något att ta med sig är ”The boy scout rule” — lämna alltid campingplatsen lite lite bättre än som den var när du kom — direkt applicerbart på systemutveckling (och många andra områden för den delen).

Dagen avslutades med ännu en keynote, av Dan Ingalls (skaparen av Smalltalk, pionjär inom Objektorientering mm) med titeln 40 years of fun with computers. Mycket underhållande och tänkvärt. Samtidigt som vi gör stora framsteg så har vi fortfarande samma problem som förr.

Mellan dagens keynotes har det varit ett stort antal intressanta föreläsningar om vitt skilda ämnen. De jag har besökt har handlat om ESB (Enterprise Service Bus), när det är lämpligt att använda en, och när det är mindre lämpligt. Jag har nosat på Performance Management (det går bara att jobba proaktivt med prestanda om man mäter!), NOSQL-rörelsen med grafdatabasen neo4j (grafdatabaser är väldigt kraftfulla för viss typ av information) , och RIA (Rich Internet Applications) med opensocial och vaadin.

Mer från QCon kommer!

/Emil

Simon Brown och Kevin Seal (grundarna till www.codingthearchitecture.com) har underhållit oss under dagen med ett manifest kring systemarkitektur för utvecklare — eller ”lite lagom mycket” systemarkitektur, med visst förakt för Ivory Tower-arkitekter (se Wikipedia för lite intressant bakgrund kring begreppet) och ett stort mått av pragmatism.

En stor del av arkitektur enligt Simon och Kevin handlar om en mjukvarulösnings kvalitetsaspekter, något som man sällan har tydliga krav på, så de har försett oss med inspiration och metodik kring hur man kan angripa detta. Mätbarhet och realism finns med som viktiga parametrar kring detta.

Vi diskuterade även hur viktig arkitekturen är i en agilt driven utvecklingsprocess — viktig men även lite svår att få till. Hur jobbar man egentligen strategiskt i en utpräglat taktisk miljö? Inga patentlösningar presenterades, men man tar med sig en hel del nya tankar king hur man kan jobba vidare. Den här artikeln i ämnet — Agile Architecture — är klart läsvärd.

Mer info från QCon kommer!

/Emil

Det är Typemock som intervjuar Andy under SPC09.

Min första reflektion är att Computer Swedens rapportering kring Scrum har vissa likheter med kvällspressens dito kring Svininfluensan. Överdriven skrämselpropaganda är vad det är!

Man skriver redan i ingressen att Scrum ofta är kontraproduktiv enligt flera experter på agil utveckling. Man låter vidare några (andra) experter inom området yttra sig, men efter att ha i dagarna tre lyssnat just till dessa experter, så har jag svårt att tänka mig att kontraproduktivitetskritiken kommer från dem. Jag kommer inom kort återkomma med referat från dessa experters, för övrigt lysande, sessioner på Øredev.

Att komma underfund hur enkelt och självklart Scrum egentligen är tar förvisso sin tid, men vad finns det för bättre alternativ? De agila arbetsätten är ju fullständigt överlägsna tidigare metoder på så gott som alla plan. Alla organisationsförändringar kräver förändringsledare, så också införandet av Scrum. Undersökningar visar att 75% av alla projekt som saknar en agil förändringscoach fallerar.

Vidare kommer det ju inte som en direkt överraskning att någon ur Scrum Alliance, i detta fall en av grundarna Ken Schwaber, hoppar av. Min uppfattning är inte att dessa personer är de frommaste skolgossarna i världen direkt. De här är ju personer med mycket starka och ibland extrema åsikter. Vore nästan konstigt om de var rörande överens om alla detaljer.

Det som jag däremot kan hålla med om är att Scrum blivit en riktig hype, vilket känns lovande, där ”alliansen” drar in grova pengar på så kallade Scrum Master-utbildningar. Jag förstår ändå inte kritiken. Är det inte längre okey att tjäna pengar på efterfrågade utbildningar och certiferingar? Är det inte det PMI och IPMA gjort länge nu?

Jag följer den ihåliga kritiken i CS med spänning framöver. Men glöm inte att:

Scrum är svinlätt – om man kan det!

http://computersweden.idg.se/2.2683/1.267157/nu-vaxer-kritiken-mot-scrum

De olika teamen i de olika projekten ska alltid arbeta i samma cykler, så att projekten och dess team inte jobbar i otakt. I de fall ett projekt skulle kunna starta på nästa cykel, men samtidigt ev. kan vara beroende av resultatet av ett annat team eller projekt bör projektets team fokusera på att refaktorera eller utbilda sig istället. Använda tiden till att reducera den tekniska skulden och göra sig redo för framtiden i form av utbildning och dyl. med andra ord.

När man nått framgång med de agila arbetsätten i ett team bör man skala upp steg för steg, anser Mike. Man sprider framgångsfaktorerna från ett team till flera andra, från ett projekt till ett annat osv. Vartefter organisationen blir allt mer agil behöver man från ledningsnivå börja arbeta på samma sätt. Man tar på översta nivån fram vilka krav/affärsmöjligheter organisationen ska arbeta med framöver och prioriterar dessa. Inom respektive ”affärsområde” bryter man ner ledningens krav/möjligheter i ett antal projekt. I de respektive projekten fördelar man de nu detaljerade kraven över flera team, som sedan bryter ner kraven på en detaljnivå och implementerar dessa.

För att koordinera och kommunicera kraven/möjligheterna mellan de olika nivåerna skapas team med arkitekter och produktägare, som arbetar med riktlinjer och prioriteringar som kommuniceras till den ”underliggande” nivån. Viktigt att dessa endast jobbar med frågor som rör den nivå man arbetar på och inte detaljstyr underliggande nivåer.

Slutligen är det av yttersta vikt att teamen på de underliggande nivåerna ger återkoppling och förbättringsförslag ”uppåt” i organisationen för att överliggande nivåer ska kunna förbättra inputen till de underliggande teamen i framtiden. 

Läs mer av Cottmeyer i hans utmärkta blogg på:
http://www.leadingagile.com/

Aberdovey, (uppkallat efter den walesiska orten där Woodwards 21stapps har sitt HQ), är något så intressant som ett scrum-verktyg för SharePoint. Andrew annonserade sina intentioner i maj, men det har inte hänt så mycket över sommaren. Nu har det tydligen kommit igång enligt Andrews senaste kommentar.

Medan ni håller ögonen öppna för uppdateringar om Aberdovey så rekommenderar jag att läsa och följa 21stapps-bloggen. Den kryllar av inlägg om agil SharePoint-utveckling, det finns whitepapers om hur man testdrivet utvecklar webparts, redogörelser för hur Andrew kör scrum i ett team bestående av honom själv (i en tvådagars-sprint där det är 3 veckor mellan de två dagarna),  omröstning om populäraste byggservern i SharePointutvecklingsprojekt, TDD kata (dock inte SharePoint-kod) m.m.