BSD-X-Windows

I wrote earlier about how to set up X forwarding between FreeBSD and Windows. Unfortunately, once all that was done, my Emacs came out looking like this:

Ugly Emacs

Now what? Again, things are kind-of backwards from what I assumed. My first instinct was to install nicer fonts into Xming somehow, but I never found anything.

So after some experimentation, it occurred to me that the fonts are for the X client (i.e. my BSD machine), and the X server is just responsible for rendering. Said and done, I searched for free good programming fonts and ended up at a page with an opinion (I don’t care so much, so if someone says it’s a good font, chances are I’ll be happy with it.) I settled for Droid Sans Mono. Does it exist for FreeBSD? Turns out yes. So given this package name, I now know to do:

$ sudo pkg install droid-fonts-ttf

Since this is an X-client-side concern, I should now be able to restyle Emacs as if I was running X on the local BSD machine (if you’ll excuse the Elisp):

;; X11-specific settings.
(when (display-graphic-p)
    (set-default-font "Droid Sans Mono 14")
    (load-theme 'zenburn t)
    (tool-bar-mode -1))

And voilá, here’s what Emacs looks like when I launch it from a PuTTY SSH session:

Pretty Emacs

Unfortunately, it’s all but useless, because it thinks my keyboard layout is US English. I’m a Swede, born and raised, and can’t live without the Swedish keyboard layout (which sucks for programming, by the way, but we’re hardy people so we take it in stride.)

OK, another client/server conundrum… Who owns the keyboard layout? Intuitively I’d say the X server, because it’s in charge of user input and graphics rendering. So I search the web for ”Xming Swedish keyboard” and find a nice article from the University of Uppsala, describing how to set this up in Xming. It turns out the recommended layout for Swedes is Finnish. I’m not going to argue — my grandmother was Finnish — so I update my launch shortcut for Xming to say:

"C:\Program Files (x86)\Xming\Xming.exe" :0 -clipboard -multiwindow -xkbmodel pc104 -xkblayout fi

Finally, this setup actually works!

Configuring X forwarding between BSD and Windows

On Unix systems, windowing systems are an optional component. There are numerous window systems but the most prevalent, as I understand it, is X. It’s a networked client/server model, where the machine with the display and input devices is called the server, and the machine running windowed apps against this server is the client. This is backwards from how you typically think about clients and servers, i.e. servers are usually headless and clients are usually responsible for rendering data from servers and translating input.

I usually interact with my BSD machine from my Windows laptop using PuTTY. But running Emacs in a terminal window is sometimes hard on the eyes, it’s hard to get good fonts, color schemes, etc. I wanted to see if I could launch Emacs from PuTTY but have it render its UI over the X protocol on my Windows laptop. This was harder than I thought, and I didn’t find any step-by-step tutorial to help me troubleshoot, so here’s an account of what worked for me. Note that I started from a relatively clean install of FreeBSD 10.1, with only sshd and some basic packages installed.

To prepare the BSD machine for acting as an X client, I had to install the xauth package:

$ sudo pkg install xauth

The only visible result of this is the addition of the DISPLAY environment variable in upcoming SSH sessions, set to its default localhost:10.0.

Now to set up the X server, i.e. my Windows laptop. First I installed Xming from SourceForge. I opted not to include any bundled PuTTY, as I already had it installed.

Then I configured the PuTTY connection to my BSD machine to do X11 forwarding, see screenshot below:

PuTTY X11 forwarding configuration

(don’t forget to save that setting on the connection in question.)

I installed the xterm package on my BSD machine to have a simple app to test this setup. Here’s what the workflow looks like to run an X application on the BSD box showing its UI on the Windows side:

• Connect with PuTTY, using a connection with X11 forwarding
• Start Xming on the Windows box (this is the X server responsible for rendering the UI of the remote app)
• Start the application from the shell, e.g.

$ xterm

After a short delay, the xterm application should show a window on the Windows desktop. Note that the app is executing on the BSD box, but showing its UI over the networked X11 protocol via Xming on Windows.

Now I just need to figure out how to set up nicer fonts and coloring in this environment.

A Unix diary

A few years ago I decided to abandon Windows after having seen how much more versatile the Unix development model is. People seem to struggle less with inadequate tools, and given the philosophy of openness and freedom, the best tools are widely available at no cost.

I knew this would be hard for me, I’m a creature of habit, so I’ve spent the past couple of years using Emacs and Unix command-line tools on Windows to ease the transition to a Visual Studio-free environment.

So about a month ago I bought a new desktop machine, now standing in my basement, and installed FreeBSD 10.1. I chose BSD because it seems to be a more strongly curated Unix than the various Linux distros, for example, and with a generally likeable user community.

I thought I’d write a couple of short posts detailing things I’ve learned about the setup and configuration for posterity. That’s also why I’ve fallen back to English, hopefully these posts can help other Windows-BSD converts get started, even outside of Sweden :-)

Händer lärande när du tänker på annat?

Jag har följt James Shores Let’s Play TDD-serie, för jag har aldrig fått särskilt bra snurr på mitt eget testdrivande och ville se lite mer av hur folk gör. Serien består nu av drygt hundra 15-minuters screencasts som är ganska ljuvliga (och frustrerande!) att se.

En sak som han återkommer till ganska ofta är att han på dessa hundra avsnitt endast har lagt in 25 timmars arbete. Avsnitt 100 är en resumé med en liten klocka i overlay som visar hur arbetsdagarna flyter, från måndag 08.00 till torsdag 09.00. Jag tror att det här fokuset på tid är ett sätt att säga att testdriven utveckling inte nödvändigtvis går mycket långsammare — se bara vad man kan åstadkomma på 3 dagar!

Om man var misstrogen skulle man ju kunna beskylla honom för att ha gjort det mesta tankearbetet mellan avsnitten, men jag tror faktiskt inte att han har klurat särskilt mycket aktivt i mellantiden. Ofta spelar han in flera avsnitt på rad och pausar ett par dagar mellan batcharna, och jag har en känsla av att han jobbar med annat i avbrotten.

Först var jag lite imponerad av produktionstakten, men efterhand har jag börjat misstänka att James fuskar ändå. Fast omedvetet.

Joakim Karlsson kvittrade häromdagen om en besläktad erfarenhet;

At #softhouse #codejam yesterday, we failed solving a problem while under time pressure. Today w/o pressure I TDD:d a solution in 20 min.

Om man tolkar de här två exemplen bredare, skulle man kunna tro att hjärnan tänker vidare när man gör något annat. Förmodligen är det här ganska väletablerat, men det skulle vara kul att läsa konkreta studier på temat.

Ponera att bra idéer förädlas när du inte jobbar aktivt med dem — skulle du jobba mindre och duscha mer?

Anteckningar från Øredev 2010

Jag tillbringade hela förra veckan på Øredev, för första gången sedan -06 och det var sannerligen roligt att uppleva igen. Jag tog en hel del anteckningar, och tänkte återge någon sorts referat av dem mest för att själv bearbeta materialet och få ner alla referenser och tips på pränt, men också för att ge en liten bild av konferensen som jag upplevde den.

Diana Larsen — Agile Retrospectives

Efter att ha läst boken var jag otroligt inspirerad att använda retrospektiv för att komma närmare kontinuerlig förbättring. Av olika anledningar rann det ut i sanden, och jag har gått och funderat på ämnet ett tag. Att få höra hela idén från hästens mun igen kändes otroligt värdefullt.

• Diana berättade om någon som hade frågat ”does the retrospective always happen at the end of the iteration?” och hennes syn på det var att planering-arbete-retrospektiv snarare löper i en cykel, där retrospektivet snarare kanske är någonstans i mitten. Det påminde mig om Sysavs motto: ”Mitt i kretsloppet”, som jag tycker är otroligt fyndigt.
• Retrospektiv skall gärna ha en struktur bestående av Set the stage, Gather data, Generate insights,  Decide what to do, Close. Vi pratade en del om Gather data, och hur den delen har som uppgift att få fram maximalt med information för att, om möjligt, ge alla en liknande bild av vad som har hänt. Man ska också ha klart för sig att Gather data inte bara ska ta fram kall data, utan också belysa känslomässiga intryck och förändringar under perioden som förflutit.
• När retrospektivet stängs (Close) har man ett bra tillfälle att samla in feedback om retrospektivet självt. Värt att notera här är att feedbacken inte är till den som faciliterat utan tillbaka till deltagarna som grupp — ”har vi kommit fram till något vettigt?” ”var det här värt min tid?”
• Diana visade en fin övning hon kallar ”Circles and Soup” som kan användas för att undersöka deltagarnas känsla av vad de kan påverka. Se hennes blogginlägg för detaljer.

På det hela taget fick jag en mycket bättre bild av hur ett retrospektiv går till och hur mekanismerna är tänkta att fungera. Och jag inser också att som aktiv team-medlem kan jag inte gärna facilitera retrospektiv för oss, så jag funderar på ett utbytesprogram på jobbet.

Jutta Eckstein — Agile Software Development for Distributed Teams

Vi är för närvarande ett samsittande team om två på jobbet, men vi väntar hjälp från fem personer i Bangalore. Den här workshoppen verkade vara ett utmärkt sätt att få lite mer kött på benen kring förväntade problem och tekniker för att lösa dem. Jutta var väldigt tillmötesgående och ödmjuk inför problemet och eventuella kontextuella begränsningar och hade mycket intressanta erfarenheter.

• Det första jag reagerade på, som var väldigt befriande, var att hon direkt sa (parafras): ”Det är väldigt svårt att spara pengar på outsourcing. Vill man använda distribuerade team ska man göra det av andra skäl, och ett distribuerat kommer med stor sannolikhet aldrig att bli lika effektivt som ett geografiskt samlat team. Men så här tänker jag att man kan använda agila principer för att underlätta.”
• Jutta talade om iterationer som ett ”heartbeat for a development effort” — så snart man arbetar med mer än ett team, distribuerade eller inte, i ett utvecklingsarbete, tror jag det ligger rätt mycket i det här. Det känns värdfullt att alla planerar mot samma horisont, jobbar i ungefär samma takt och synkar sinsemellan med samma frekvens.
• Vi pratade också en del om hela team, och hur man kan arbeta med t.ex. feature-team + specialist-föreningar där varje feature-team innehåller all kompetens som behövs för att leverera färdig mjukvara, men där man regelbundet träffar andra i sitt fack från andra team för att göra mer överordnad synkronisering.
• Hennes erfarenhet var att ca 10% av personalstyrkan borde vara tillägnad CM-arbete, dvs sköta byggsystem, versionshanteringssystem, etc, för att feature-team ska kunna arbeta mer eller mindre ostört. Vi råkar ha just den fördelningen, och jag kan bara instämma: det funkar väldigt bra.
• ”Video conferences never really worked for us”
• Ömsesidig respekt — det är ingen god idé att möten ständigt schemaläggs så att det är mest bekvämt för huvudkontoret. Hellre låta alla lida ibland än att alltid låta vissa lida.
• Det talades om en ambassadörsroll, alltså någon som kan hjälpa till att ”tolka” mellan olika företags-, team- eller nationella kulturer. Någon form av utbyte mellan de olika ställena.
• Jutta talade också om högsta gemensamma nämnare avseende kommunikation. Dagliga stå-upp-möten, t.ex. kan genomföras  helt över Skype, även om teamet är delat i två grupper om fyra, som vardera sitter tillsammans. Detta för att alla kommunicerar med samma ”fidelity”, vilket gör att alla är lika handikappade i kommunikationen och alla måste anstränga sig lite extra för att nå fram.
• Boktips: Juttas egen Agile Software Development with Distributed Teams
• Boktips: Geert Hofstedes Culture’s Consequences

Jag kom hem med en hel del idéer för hur vi kan underlätta samarbetet med våra nya kolleger.

Steven ”Doc” List — Facilitation Patterns

• Steven presenterade ett antal stereotyper, t.ex. ”Gladiator”, ”Curious George”, ”Sherlock Holmes”, som påverkar ett möte eller grupporienterat arbete på olika sätt.
• Vi använde stereotyperna för att spela ett mötesrollspel, och se om vi kunde känna igen de olika baserat på typiska beteenden.
• Han rekommenderade International Association of Facilitators databas över tekniker och övningar och Wilderdoms dito.
• Boktips: Roger Schwarz, The Skilled Facilitator
• Boktips: Kerry Patterson m fl, Crucial Conversations
• Boktips: Robert Chambers, Participatory Workshops
• Boktips: Jean Tabaka, Collaboration Explained

Jag tog inte med mig jättemycket ifrån den här, men fick massor av bra uppslag till vidare läsning.

Jeremy D. Miller — Patterns for Building Internal DSLs

• Glöm att försöka få ditt DSL att flyta som naturligt språk. Det är programmerare som ska använda det, så håll igen på prepositioner, etc, och koncentrera dig på att få ett begripligt API. Amen.
• Utnyttja auto-completion för att bygga ett självdokumenterande API
• Använd DSL:er för att bygga objektgrafer som sedan kan exekveras. DSL = konfiguration, resultatet = run-time.
• Boktips: Martin Fowler, Domain-Specific Languages

På det hela taget tycker jag Jeremy presenterar väldigt bra, men 50 minuter är ingen lång stund, och han lät sig luras in i långa resonemang av frågor, och kom inte riktigt igenom sitt material med något större genomslag. Jag hade gärna läst ett eller flera bloggpost om samma idéer.

Rachel Davies — Building Trust

• Trust definieras som ”confidence to collaborate”
• Lärande som ett sätt att bygga tillit — man lär sig genom att misslyckas, och genom att misslyckas tillsammans bygger man förtroende
• Synlighet (transparency) är ett sätt att stimulera förtroende
• Rachel sa klokt apropå svårigheter att engagera att någon som vägrar göra någonting oftast har en bra anledning. Det kan vara värt att försöka ta reda på exakt vad, och angripa det problemet för att komma vidare.
• Trust = (Credibility + Intimacy + Reliability) / Self-orientation. Någon som arbetar för att själv vinna fördelar (self-orientation) kommer att ha extra svårt att bygga tillit.
• Boktips: David Maister, The Trusted Advisor

Efter presentationen hade jag inte så mycket tankar kring det här, och kunde inte återge vad som sagts, men nu när jag gått igenom mina anteckningar känner jag att den gav massor av praktiska användbara tips för att förstå mekanismerna som styr tillit.

Jeremy D. Miller — Web Application Testing

• En experience report från Dove Tail, om hur de gör sin end-to-end-testning.
• De använder Selenium RC och StoryTeller för att driva sina webtester
• StoryTeller har specifika fixtures för att sätta upp testdata
• De har kapslat allt Selenium-jox i ”screen drivers” som ger ett tydligt C#-API att använda från StoryTeller-fixturerna
• Deras turnaround-tid för en testkörning är 30-40 minuter, så de kör testerna som ett separat CI-steg om build + unit tests har gått igenom (fast build/slow build).

Jag gillade deras ”screen drivers” som kapslar detaljerna i att driva applikationen, vilket gör att underhållsarbetet blir mycket mindre. Jag har haft liknande planer, som jag snart hoppas kunna sätta i verket.

Ulrich Freiberg — Building a Test Framework Imposes a lot of Challenges

• Han har styrt bygget av ett testramverk för ett antal system om totalt 10 miljarder rader kod (det här sista tror jag var en felsägning. Hoppas det!)
• Principerna har varit ”compiler quality” och pluggbarhet.
• Med ”compiler quality” menade han nog att ramverket måste vara robust så att ett test failure alltid beror på issues i produktionssystemet, inte i testramverket. Annars tappar folk förtroende ganska snabbt.
• Med pluggbarhet menar han en mekanism för att bygga domänspecifika libraries för att testa delar av produktionssystem. T.ex. visade han ett test som använde ett library för FX — Foreign Exchange. Genom att kapsla access till de externa systemen i likartade bibliotek kan man ganska enkelt skriva tester som arbetar över flera domäner, t.ex. FX och Savings. I teorin i alla fall.
• Över huvud taget pratade han mycket om inkapsling, och det är något som jag själv tror stenhårt på för att göra tester någorlunda underhållsbara. Ju färre delar av testerna som direkt accessar målsystemet, desto enklare blir det att refaktorera det senare.

Jag fick intrycket att han var väldigt nöjd med det som byggts, men det var svårt att få grepp om hur det rent faktiskt hängde ihop, och hur bra det faktiskt fungerade.

Gojko Adzic — Agile Acceptance Testing Success Stories

• Gojko hade intervjuat deltagare från totalt 50 projekt om deras erfarenheter av agil acceptanstestning och försökt destillera ut det som skilde lyckade initiativ från mindre lyckade
• ”Tests are hard to maintain when a small change in the business model requires a massive change in tests and software” — vi återkommer ständigt till inkapsling…
• Gojkos grundläggande tes verkade vara att acceptanstester helst ska vara en dokumentation av företagets affärsprocesser som kan drivas av ett testramverk och utvärderas mot målsystemet. Han är ju ett stort FitNesse-fan, så det är inte svårt att se vad det betyder i praktiken, men han gjorde tydligt att verktygen spelar mindre roll, så länge testerna är på en sådan nivå att de fungerar som dokumentation snarare än kod.

Jag var nog lite trött och okoncentrerad, för jag tog inte med mig så vansinnigt mycket från det här.

James Shore — Alternatives to Acceptance Testing

• James menar att Fit lämpar sig för ”customer unit tests”, dvs ett samarbetsverktyg för XP Customers att specificera och utvärdera affärsregler emot målsystemet…
• … men tyvärr har tiden utvisat att Customers väldigt sällan känner sig bekväma med verktyget, vilket har lett till att programmerare sitter och trixar med Fit för att skapa läsbara testfall som ingen läser
• Idén att Fit skulle vara extra väl lämpat för end-to-end-testning menar han är rent nys
• Han refererade till Nancy van Schooenderwoerts redogörelse från Agile 2006-konferensen och särskilt jämförelsen med Capers Jones statistik. En sak jag reagerade på var Jones mät-triplett: Totalt antal defekter funna/procentandel hittade och korrigerade under utveckling/antal hittade hos kund. Det kändes som att det här vore användbart för att mäta hur en processförändring påverkar kvalitet. Om man kommer ihåg att mäta…
• James snavade lite på orden, och råkade mynta ordet ”Testemers” — testers/customers, testare som arbetar främst med att utvärdera systemet i domänkontext.
• Rekommendationen var att ersätta automatiserade acceptanstester med stark kundnärvaro, extrema mängder enhetstester och fokuserade integrationstester samt manuell testning för att hitta luckor i processen följt av processförändringar för att eliminera rot-orsaken.

James Shore känns som en av branschens mest hängivna utövare, och mot bakgrund av att han var en av männen bakom Fit, såg jag mycket fram emot att höra hur han såg på tekniken idag.

Roy Osherove — How to do Test Reviews

Inga anteckningar härifrån. Osherove är tongivande i TDD-sammanhang, och saluför TypeMock.NET, ett av de enda ramverken som tillåter mockning av annat än abstraktioner, t.ex. konkreta klasser och statiska klasser.  Sessionen verkade handla om TDD best-practices.

En sak jag tog med mig var ett starkare argument för one-assertion-per-test: Om ett test fallerar på sin första assertion, man försöker rätta till problemet och nästa assertion fallerar, så vet man inte om man introducerat ytterligare ett problem eller om #2 hade gått fel hela tiden. En assertion per test ger alltså mer finkornig information, vilket i vissa fall kan vara värdefullt.

Han avslutade med en sång. Fin röst har han, gossen.

Neal Ford — Testing the Entire Stack

Här har jag bara ett litet citat

Test a weaker language with a stronger one

Principen var att språk som lämpar sig för DSL-byggande (Groovy i hans exempel) är bättre att skriva tester i, för att de blir mycket mer läsliga. Groovy har dessutom featuren (?) att den ignorerar private-deklarationer, så man kan testa privata metoder, vilket Ford tyckte var jättebra. I övrigt tyckte jag inte att den här sessionen hade så mycket att ge.

Gojko Adzic — Challenging Requirements

Gojko levererade en underhållande presentation av konstiga krav han fått genom åren, och hur han arbetat med dem för att hitta kärnan och kunna välja en hållbar lösning.

• Han presenterade fyra ”regler” för att nå bra krav — vägra lösningsförslag, vägra teknikförslag, vägra lösa problem som inte är ursprungsproblem och känn dina stakeholders/användare.
• För att komma till ursprungsproblemet rekommenderar han att: ”Ask why until you get to the money”.
• Börja inte med user stories. Börja med specifika exempel av en vision.
• Sammanfattningsvis: Förstå problemet och den som har det
• Boktips: Ingrid Ottersten, Effektstyrning av IT — Gojko hade läst den på engelska, men nämnde att den var svensk i originalutgåva.

Väl förberett och väl levererat, tycker jag. Mycket fokus på att vägra, men mina erfarenheter av kravarbete säger att det nog inte är någon dum strategi att försöka gå till botten med varje enskilt krav, och förstå bakgrunden.

Jeremy D. Miller — Compositional Design with Responsibility-Driven Design

• Första gången jag hör talas om GRASP patterns. Känner att jag missat något, och måste läsa på.
• Vi får en blixtpresentation av Rebecca Wirfs-Brocks stereotyper (som jag läst en hel bok om, men inte har någon klar bild av): Information holder (t.ex. Customer), Structurer (t.ex. Cache), Coordinator (t.ex. event handler — kan separera scheduling från logik), Service Provider (t.ex. HashCalculator) och Interfacer (en adapter eller fasad, t.ex. EmailSender).
• Få objekt är renodlade stereotyper, och de flesta samverkar med andra stereotyper för att uppfylla sina ansvarsområden
• En tanke som slog mig under presentationen som inte direkt hade något med saken att göra: ”Lämpar sig behavioral patterns bättre för mock-baserad testning än state-baserad testning?”. Kan vara värt att undersöka.

Återigen kändes det lite rumphugget, men väldigt givande.

James Shore & Kim Gräsman — Let’s Play TDD

På fredagmorgonen stötte jag på James Shore och vi kom överens om att parprogrammera ett par avsnitt av hans screencast-serie Let’s Play TDD. Sagt och gjort, vi låste in oss i ett rum på andra våningen och spelade in, och roade oss kungligt. Tror jag är med i avsnitten 53-55, som väl postas med början nästa vecka.

Neal Ford — Emergent Design

• Efferent och Afferent coupling, dvs hur många andra klasser en klass refererar respektive hur många andra klasser som refererar en klass. Jag har läst om det här tidigare, men inte insett hur lätt det är att mäta och vilken förment trevlig kvalitetsindikator det kan bli.
• Artikeltips: Collaborative Diffusion

Greg Young — 19½ things to make you a better OO programmer

• SOLID-principerna är inte lagtext. SRP t.ex. kan trade-offas med cohesion. Högre cohesion kan göra att en klass samlar på sig fler ansvarsområden.
• Afferent/Efferent coupling och cohesion är metrics som kan konkretisera SO(L)ID — LSP är undantaget
• DRY/Eliminate duplication kan trade-offas med coupling
• Han rekommenderade alla att läsa på om Design by Contract som nu har library- och kompilatorstöd i .NET.

Daniel Brolund & Ola Ellnestam — Large-scale refactorings using the Mikado Method

• Använd scratch refactorings för att bygga en refactoringstrategi
• Bygg en graf av beroenden mellan refactoringsteg
• Attackera lövnoder i grafen, som är relativt enkla refactorings
• Detta möjliggör inkrementella storskaliga förändringar
• Utkast till boken finns här och en mailinglista för diskussion här

Sammanfattning

En iakttagelse jag gjorde var att Dave Hoover och Patrick Kua höll de i särklass skönaste presentationerna, för att de var relativt dämpade och avslappnade (tyvärr såg jag bara halva av varje och har inga anteckningar därifrån). Teknikpresentationerna var överlag mer testosteronstinna, högljudda och predikande.

Jag vill också höja ett glas för maten, som jag tycker var enastående under förutsättningarna.

Det enda negativa är det som nämnts ett par gånger redan i Øredevosfären: ljudläckor mellan de olika föreläsningssalarna var ganska irriterande. Jag vet att arrangörerna gjorde sitt bästa för att eliminera det, men lokalerna var nog inte optimalt lämpade för den här typen av prat-täta konferenser.

Med det sagt tycker jag Slagthuset var ett utmärkt ställe på alla andra sätt; interiören är trevlig (jag gillar tegel) och stället sväljer folk!

Sammanfattningsvis kan man säga att jag hade en väldigt inspirerande vecka.

”Källkod är utvecklarnas UI”

Laurent Bossavit på XP-listan;

A really, really bright idea from one of my friends, Regis Medina, was
to apply the techniques of usability testing to source code, and more
broadly to consider source code ”the programmer’s UI onto the
project”. Unfortunately he’s been too busy recently to develop it much
further but I think it has legs. (As has the related transpositon of
”process as the manager’s UI onto the project”.)

Jag bloggar det här för att inte glömma bort det.

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.

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?