Fashionable web site

I’m waiting patiently for my winwonk.com domain to become available again, after a misunderstanding/dispute with my registrar.

There’s been some demand for my old tools (Urlograph and OpenTarget notably) since they disappeared, and I’ve put off trying to host them somewhere else. But yesterday I realized I have a domain that I’m not using and that the web site should work fine under any name, so I set it up.

The web site I built 10 years ago turned out to be less than beautiful, and so I put a couple of hours into a new, bland design.

You’re welcome to it all at http://www.kontrollbehov.com.

Annonser

Att knyta ihop säcken

Förra hösten kom mina svärföräldrar ner för att hälsa på. Vi åt en snabb lunch, sedan tog vi chansen och lämnade barnen med dem och gav oss ut för att räfsa löv. Vi har ett valnötsträd på framsidan som inte ger några fina nötter, men som fäller ganska rejält med löv över gatan. Det var mulet och rått med lite vind, men någorlunda torrt, så vi tyckte det var läge att hålla undan.

Alla som har fyllt en plastsäck med löv vet att det finns roligare saker. Säcken flaxar ihop i vinden, man tappar hälften utanför, och det är på det hela taget rätt meckigt. Vi räfsade därför  ihop löv i ett tiotal rejäla högar om kanske ½ kubik vardera, för att sedan dra fram sopsäckar och börja paketera efter bästa förmåga.

När ungefär hälften av högarna var packade började vi snegla drömskt mot huset och kaffebryggaren. Kallt och blåsigt var det, och kallt. Och blåsigt. Just när jag lassat en handfull löv i en skrynklig säck kände jag plötsligt en regndroppe i nacken, och strax låg det ett jämnt höstregn i luften.

Och när vi lyfte blicken mot vardagsrumsfönstret tittade svärfar ut med viss panik i blicken och en gallskrikande tremånaders dotterson i famnen. Plötsligt kändes kylan, blåsten och regnet ganska trösterika.

Men, ansvarsfulla föräldrar som vi är, samlade vi ihop oss och gick in. Sonen hämtade sig efter lite mat, vi fick kaffe och allt var frid och fröjd.

Förutom att fyra stora lövhögar låg kvar. Helgen efter hann vi packa undan två av dem och helgen efter det, när vi skulle ta undan de sista, upptäckte vi att de hade skingrats för höstvinden.

Då förstod jag plötsligt värdet av att minimera work-in-progress (WIP).

Teorin är alltså att cykeltiden, dvs tiden för en säckfull löv att komma från marken till en förseglad säck i garaget, är en funktion av hur mycket WIP (lövhögar) vi har. Att minska WIP borde därför betyda att vi blir färdiga snabbare, eftersom cykeltiden minskar. När cykeltiden minskar, minskar också risken att vi blir avbrutna med halvfulla säckar, vilket i sin tur gör det mindre sannolikt att halvarbetade lövhögar blåser bort innan vi hinner ta hand om dem.

I år har jag lovat mig själv att räfsa Lean.

Mycket vill ha mer

Jag plockade lite med disken idag och tänkte på C++, som vanligt. Och så tänkte jag på platsannonser som söker ”C/C++-utvecklare”.

Om språket C är en delmängd av C++ behöver man mer sisu för att åstadkomma en bra design med C. Och eftersom abstraktionsmekanismerna i C är helt andra än dem i C++ behöver man en annan sorts sisu också. Att man är bra på C++ är ingen garanti för att man ens kan uttrycka sig på ett vettigt sätt i C.

Men det är förrädiskt… Om man använder C++ som C med extra syntax är det förmodligen enklare att byta till ren C, men å andra sidan är ens C++ inte så het. Använder man C++ som Bjarne avsåg har det väldigt lite gemensamt med C.

Kan det vara så att duktiga C++-utvecklare har svårare att lära sig C än medelmåttiga?

Sitta tillsammans på olika sätt

Sedan jag först började läsa om agila metoder har jag uppskattat tanken att sitta tillsammans som något självklart och ovedersägligt.

Efter ett par försök på olika håll tycker jag mig se ett par återkommande mönster för vad som får tekniken att fungera bättre.

Gemensamma intressen

För att det ska löna sig för en grupp människor att sitta tillsammans krävs att de har något gemensamt. De bör arbeta i samma projekt, mot samma deadline och samma kodbas.

Därför

Forma team som arbetar i grupp mot gemensamma mål, och placera dem tillsammans.

Men

Tänk på att inte forma för ensidiga team — Gemensamma intressen betyder inte att alla gillar att knacka Ruby, utan att alla strävar mot samma mål och hjälps åt att komma dit. Tvärfunktionella team innehåller alla kompetenser som behövs för att leverera en färdig produkt.


Lagarbete

Ola Ellnestam beskriver ett anti-mönster som han kallar för The Graveyard:

Föreställ dig ett rum, ganska stort. Ungefär 100 kvadrat. Du kan knappt höra surrandet från ett halvdussin datorer. Det är varmt, inte hett, bara lite över normal rumstemperatur. Någon hostar. Sedan blir det tyst igen, förutom det svaga surrande datorljudet. Du lyssnar lite noggrannare och märker ett svagt, oregelbundet klickande. Du får en känsla av att den som är källa till ljudet inte vill störa för mycket. Ljuset i taket flimrar till.

Du sveper snabbt med blicken över rummet, räknar till 1, 2, 3 … 7 sittande personer. De verkar stirra ut i tomma rymden, och det hade de också gjort om det inte vore för datorskärmarna framför dem. Det är som om det stod glasväggar mellan personerna i rummet. En dator står längst ner i rummet. Skärmsläckaren snurrar förbi lite text.

Förutom Gemensamma intressen blir det mycket mer värdefullt att sitta tillsammans om man faktiskt jobbar som ett lag istället för som en grupp individer. Man blir mindre beroende av nyckelpersoner, eftersom alla har hygglig inblick i vad som händer.

Därför

Som Ola säger, uppmuntra Lagarbete och kommunikation genom att hitta rutiner som får flera personer att jobba på olika aspekter av samma uppgift.

Men

Ett väl fungerande Lagarbete är svårt att skapa på syntetisk väg. Var försiktig så att eventuella knuffar för att stimulera lagarbete inte hindrar teamets naturliga sätt att arbeta.


Storleken har betydelse

Kommunikationen sägs bli bättre av att sätta gruppmedlemmar fysiskt nära varandra, så att de kan använda högeffektiva kommunikationsmedier — tal och ansiktsuttryck — och uppnå osmotisk kommunikation.

Det är dock svårt att skala det här — större grupper kommunicerar mindre effektivt och det blir svårare för medlemmarna att socialt knyta an till hela gruppen.

Därför

Ge dina team Gemensamma intressen, så att de har något att kommunicera kring, men inte så stora mål att de behöver vara fler än 5-9 personer.

Men

Om ditt team av någon anledning måste vara stort, försök introducera tekniker och regler för att minimera störningar (både inifrån och utifrån), maximera kommunikationsmöjligheterna och stimulera social interaktion.


Privat sfär

Jag har vid ett par tillfällen suttit i jättebra grupper, med Gemensamma intressen och lagom storlek, men två meter ifrån vår arbetsyta har ett annat, mycket mer högljutt team (med tråkig humor) suttit och förpestat lugnet. Som jag minns det var vi väldigt tysta och skötsamma, men något säger mig att de tänkte samma sak om oss.

Därför

Isolera team från varandra genom att ge varje team ett eget rum där de inte störs av buller från utomstående. Alternativt, möblera med skärmar och whiteboards så att teamet får vara någorlunda ifred från störmoment.

Men

Att team är fysiskt avskilda från varandra till vardags betyder inte att de ska sluta kommunicera, bara att de ska undvika att störa varandra med slumpmässigt oljud.


Telefonrum

Om jag delar rum med fem personer och min fru ringer för att fråga om deklarationen vill jag helst inte prata inför mina kolleger. Eller om jag behöver ringa för att boka en läkartid eller bara snacka med en kompis. Dessutom finns det få saker som är så störande för omgivningen som någon annans mobiltelefonsamtal.

Därför

Se till att varje team har ett dedikerat rum med dörr som är avsett för privata telefonsamtal. Om lokalerna tryter, låt flera team dela på ett telefonrum. Vi har ett litet konferensrum som man inte kan boka, men som ockuperas för mindre möten. När det är ledigt används det flitigt som telefonrum, annars hänger folk ganska oblygt i korridoren.

Det viktigaste är att folk inte känner sig utsatta när de sköter sina personliga förehavanden, och att deras kolleger inte störs om de saknar normala telefonspärrar.


Samfälliga avbrott

När någon utomstående kommer in i gruppens rum för att prata med en enskild medlem avbryts och störs alla medlemmars arbete. Ofta tror den som frågar att den har korn på vem som vet mest, men lika ofta visar det sig att gruppen tillsammans vet mer än någon enskild medlem, särskilt om gruppen ägnar sig åt Lagarbete

Därför

Arbeta för att utomstående inte ska tilltala enskilda medlemmar om arbetsrelaterade saker, utan hela gruppen — alla är ändå inblandade konversationen, från det att någon säger ”Hörru, Kim, jag undrar…”.

Men

Om det rör privata angelägenheter, lämna gruppens arbetsyta, för att störa så lite som möjligt.


Slutsats

Som alla tekniker fungerar samsittning olika bra i olika sammanhang. Efter ett gäng bra och några dåliga erfarenheter vill jag driva tesen att fokuserat lagarbete i en mindre grupp i alla fall är en bra start.

Ständigt återkommande teman ovan är Gemensamma intressen, Lagarbete och kommunikation.

Kommunikationen ses ofta som den stora fördelen med att placera grupper tillsammans, men jag tror inte förbättrad kommunikation kommer gratis, den är avhängig flera andra aspekter av teamets samarbete.

Korrekthet och noggrannhet för småbarnsföräldrar

Jag har haft stora problem i mitt liv med att skilja på de engelska termerna accuracy och precision — jag väljer att översätta det med korrekthet och noggrannhet.

Min tvååriga dotter visade idag exakt hur de skiljer sig.

 

Etch-a-Sketch with scribbles

Accuracy or precision?

Hon berättade att den stora klumpen till höger, som ser ut som en potatis, var en lång dator. Liksom de små spetsiga grejerna mitt på ritbrädan, förutom en, som var en bil.

Då slog det mig. Hennes ritande är inte särskilt korrekt — accurate, men hon är en fena på att rita små, minutiösa detaljer med stor noggrannhet — precision.

Wikipedias definition talar om sanningsenlig vs. reproducerbar, men det är ju inte alls lika bedårande.

Språk, makt och inflytande

När jag funderar på vad som är viktigt för att lyckas med mjukvarudesign återkommer jag ganska ofta till god språkkänsla. Jag har tidigare hävdat att en av de viktigaste kvalitéerna i god design är bra namngivning, men också att vara konsekvent i sitt uttryck (problemlösande) och inte vackla mellan olika stilnivåer (abstraktionsnivåer).

Och samma gäller egentligen för att kunna förstå programkod — vad termer betyder, hur element passar i sitt sammanhang.

Jag berömmer mig själv med att vara ganska bra på engelska, men jag märker att jag under åren tappat ganska mycket fart för att jag missförstått eller inte alls förstått grundstenar i tredjeparts-API:er och datavetenskapslitteratur. Så mycket av vår vetenskap genomsyras av metaforer att det är rätt tufft att hänga med om man inte är intresserad av att förstå och även av att kunna uttrycka sig.

Men det här gäller nog inte bara den tekniska sidan. Hänvisningar till och vikten av språk återkommer hela tiden i XPs system av tekniker och värderingar (t.ex. Metafor, User Stories, Kommunikation som en del av värdegrunden).

Jag snubblade idag över någon som beskrev en enkel retrospektivövning där varje deltagare ombeds att med ett ord beskriva sina känslor inför en nyss avslutad iteration. Det finns ju professionella författare som hade haft stora besvär med att åstadkomma det.

Vi har en engelskspråkig gruppchef, och jag märker att våra gruppmöten ofta blir lite tysta. Folk är inte rädda för att prata, men tröskeln är högre för att dra ett skämt eller försvara en ståndpunkt på något annat än sitt modersmål, även om alla är väldigt duktiga på engelska.

Knepigt.

Det verkar på det hela taget som att man som systemutvecklare borde vilja slipa sin språkkänsla, så att man lättare kan ta in den massiva ström av metaforer som möter oss dagligen. Förmodligen på engelska.

Men vi borde också vilja träna oss på att uttrycka känslor och önskningar med hjälp av metaforer och andra tekniker, för att effektivt kunna kommunicera med vårt team. Kanske på svenska, kanske på firmans koncernspråk, men åtminstone på teamets Lingua franca.

Språk ger inte bara makt utan är också en väg till inflytande. Jag försöker bättra mitt språk genom att läsa mycket skönlitteratur och skriva lite rappakalja i bloggformat. Vad gör du?

Projektberoenden måste kanske inte göra ont

Beroenden mellan projektgrupper verkar svårt att hantera (det kan vara ett lokalt problem, men jag väljer att låtsas att det är mer allmängiltigt).

Även om små, sammanhållna och seriella projekt verkar vara en ganska populär strategi kan jag ganska sällan i min roll som tjurig utvecklare styra hur projektportföljen ska förvaltas. Däremot har jag en del chanser att påverka hur arbetet fortlider när projekten väl är igång.

Fowler presenterar en intressant modell där SOA-tjänster utvecklas i open source-stil, så att team i beroendeställning kan agera patch-bidragsgivare till en tjänst de är beroende av.

Jag tror inte det här behöver vara specifikt för SOA-sfären, utan snarare att  projekt som använder tjänsteorienterade arkitekturer kanske karakteriseras av en viss storlek och flera parallellt aktiva team. Det vill säga; alla projekt över en viss storlek (mer än ett team) skulle kunna koka ihop något i den här stilen oavsett vilken arkitekturstil de råkar använda.

Fowlers vårdnadshavarmodell har mekanismer för att provocera fram kommunikation mellan två team i ett beroendeförhållande och det skulle man kunna spinna vidare på.

Exempelvis, genom att så länge det finns ett beroende i någon riktning kräva en aktiv representant på varandras dagliga stå-möten. Det borde stimulera teamen att hålla varandra uppdaterade på sina respektive behov och planer.

Eller genom att arrangera utbyte mellan teamen så att teamet i beroendeställning får en representant som kan arbeta med deras behov i deras kontext. På så sätt ökar man chanserna dramatiskt att rätt problem löses på rätt sätt.

Ett fokus på kommunikation och samarbete torde kunna mildra problembilden väsentligt.