Dagboksdokumentation

Jag kvittrade om en idé för ett tag sedan och jag tänker fortfarande på den, så jag ska försöka formulera mig lite mer långrandigt.

Jag har arbetat ganska mycket med förvaltning och bekänner mig dessutom till skolan som säger att förvaltning börjar dag två i ett utvecklingsprojekt. Robert Glass skriver vackert om förvaltning i sin Facts and Fallacies of Software Engineering bl.a. att det svåraste med förvaltning är att begripa den befintliga produkten. Det kan jag skriva under på.

Efter att ha läst ett hundratal designdokument och själv skrivit ett rätt ansenligt antal, börjar jag på allvar inse hur bristfälliga de är, oavsett kvalitet. Visst, man kan säga som Jack Reeves, att källkoden är designen — och det håller jag helt med om — men som förvaltare behöver man mer än ritningen för den mjukvara som redan finns.

Man behöver också veta hur ens företrädare kom fram till den aktuella lösningen, vilka alternativa lösningar de förkastade under vägen, hur marknadskraven löd och tolkades, vad teamet var bra på och inte. Gärna också vilka begränsningar som fanns när avgörande beslut togs, och om de fortfarande gäller. Kanske till och med vad teamet tänkte om lösningen och vad de hade för nya, listiga idéer när projektet väl avslutades.

Jag känner alltmer att formell designdokumentation är ganska meningslös om källkoden kommunicerar tillräckligt bra, eftersom den i bästa fall bara kan återge motsvarande koncept med mindre detaljrikedom. I normala fall stämmer den sällan ens med verkligheten.

Därför funderar jag nu på om mer informell dokumentation vore värdefullare.

Tänk om utvecklingsteamet från dag ett hade fört en enkel dagbok, antingen individuellt eller gemensamt, och redigerat ihop en text som beskriver det dagliga arbetet i utvecklingsprojektet, där man får ta del av teamets frustrationer, genombrott, begränsningar och tvivel. Efter att ha läst boken ”1.0” hade man haft en ganska god bild av varför mjukvaran ser ut som den gör, och vilka antaganden som är i linje med det ursprungliga teamets förståelse av sin skapelse.

Vidare projekt i ett sådant här system skulle då fortsätta berättartraditionen kring mjukvaran, för att bygga grunden för en uppföljare per release.

Jag inser att mängden dokumentation antagligen skulle bli större, men förhoppningen är att den också skulle bli mer tillgänglig och läsvärd, eftersom man kan konsumera den som en prosatext. Det ger t.ex. nya teammedlemmar chansen att läsa in sig på idéer och tankemönster hos kolleger och f.d. kolleger som lämnat teamet/företaget/jordelivet och se vilka vändningar utvecklingsarbetet har tagit under hela produktens livstid.

Förhoppningsvis kan jag experimentera lite med det här framöver.

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.

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.