Gamla hundar och ett nytt C++

Jag har det lite svårt med C++ just nu.

Mycket av det pågående arbetet på språkets library-scen (främst Boost, då) är baserat på vad man kallar template meta-programming. Jag har kämpat lite med att förstå det, eftersom många betraktar det som den starkast lysande stjärnan på framtidens himmel av C++-tekniker.

Jag har meckat med Boost, läst Josuttis/Vandevoordes C++ Templates, Alexandrescus Modern C++ Design och en hel del annat. Mycket av det är otroligt imponerande, åtminstone för mig som har en brokig bakgrund i relativt naiv traditionell objektorientering med arv och virtual dispatch.

Det som tilltalar mig med mer traditionell OO-design är att den fostrar någon sorts människotillvändhet i koden. Riktigt väldesignad kod kan nästan läsas av en lekman som känner till systemets terminologi.

Moderna C++-tekniker, i jämförelse, kan närmast beskrivas som omänskliga.

De tekniker som används för att uttrycka likheter och variationer tar inte stöd bara mot befintliga features i språket, utan uppfinner egna konstruktioner på nyskapande sätt. Detta ger naturligtvis en rad fördelar rent tekniskt: komplexa uttryck kan utvärderas compile-time och man får stenhård typsäkerhet och ofta oöverträffad runtime-prestanda.

Men för läsaren lämnas i mitt tycke en del övrigt att önska.

Jag väljer att tillskriva detta min egen okunskap, åtminstone ett tag till, så jag ska försöka se om jag kan hitta en genomgående taxonomi över likhets- och variations-tekniker med modern C++.

Det vill säga, om jag till exempel intuitivt skulle vilja använda arv för att modellera ett basfall och ett antal variationer, hur gör jag då detta med moderna tekniker? Template-specialisering? Tag dispatching?

Man hisnar vid tanken.

Velocity är inget produktivitetsmått

Extreme Programming och dess lättrörliga syskon uppmanar oss att titta på vad vi åstadkom föregående iteration för att kunna förutsäga vad vi kommer att klara i nästa.

Detta kallas för Yesterday’s Weather eller Velocity.

Man summerar kort sagt estimaten för vad som faktiskt hanns med, och planerar in arbete som är estimerat till samma insats.

Det här är kraftfullt, för det är väldigt enkelt.

Men velocity är inget produktivitetsmått. Snarare är det ett planeringsverktyg som teamet ska använda för att kunna styra sin framfart.

Om man uppmuntrar hög eller växande velocity, stimuleras en rad beteenden:

  1. Estimaten kan drabbas av inflation
  2. Man kan sänka ambitionsnivån för när något är färdigt
  3. Man kan förbättra sitt arbetssätt för att få mer gjort på kortare tid
  4. Teamet kan minska väntetider på externa parter, byggprocesser, etc.

Trean och fyran verkar godartade.

Alternativ 1 är uppenbart problematiskt, eftersom något som estimerades till 1 igår betraktas som 2 idag, utan någon annan förändring i situationen. Det ser alltså ut som att man får dubbelt så mycket gjort, men man har bara justerat sin skala. Mossigt.

Alternativ 2 gör att man levererar mer, men med lägre kvalitet. Initialt går det snabbare, men på sikt tar det längre tid att göra enskilda förändringar, eftersom man tampas med teknisk skuld från tidigare kompromisser.

Ett team som ser velocity som ett planeringsstöd snarare än en måttstock borde inse att det inte lönar sig att ensidigt höja velocity — det måste underbyggas av en faktisk förbättring för att ge något bestående värde.

Inspiration: Tom Poppendieck på XP-listan
Inspiration: Jason Yip säger det mer kärnfullt

The Revolution will not be Anglicized

Efter viss självrannsakan har jag upptäckt något intressant: jag har inte engelska som modersmål.

Det slog mig också att det inte finns någon anledning för engelskspråkiga att läsa mitt babbel.

Slutsatsen blev att jag ska prova att skriva på svenska istället, i hopp om att ha mindre prestationsångest för att det ska bli fint och rätt, och mer kraft att formulera intressant läsning.

Bubye, English readers!

Inspiration: Gil Scott-Heron — The Revolution will not be Televised