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.

One thought on “Dagboksdokumentation

  1. Martin R-L skriver:

    Tycker det låter som en utmärkt idé. Borde inte vara svårare än att dokumentera det som snappas upp under de dagliga stå-upparna + de diskussioner som uppstår under arbetsdagen.

    Hade varit riktigt skoj att läsa en sån ”bok” innan man går igång med nästa brown-field-projekt.

Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s