Jeff Sutherland at Öredev 2008

Here’s a video of a talk by Jeff Sutherland at Öredev 2008. Although I still find all his numbers suspect, because I don’t understand what he does to actually measure productivity of the teams he works with – I still like to listen to him speak. His ambition to push the envelope and find new ways to look at the things we work with is what manages to inspire me, not all his numbers.

Systems thinker Russell Ackoff now on YouTube

Three short clips featuring systems thinker Russell Ackoff have been made available on YouTube, and embedded below. Ackoff speaks plainly about profound things, so listen closely, and don’t mistake his plain words for a lack of depth. I’m not an expert, just an interested student, but it seems to be that Ackoff’s great contribution is a clear and understandable explanation of how systems concepts can be applied in organizational thinking. Here are a few key points about the nature of systems, presented by Ackoff in these clips:

  • Every system is defined by its function in the larger system which contains it
  • An essential property of a system is that it cannot be divided into independent parts
  • A system’s properties derive out of the interaction of its parts, and not the actions of its parts taken separately

As an example, here are a few quick thoughts on how our thinking about software development teams needs might change if we look at them through the systems thinker’s eyes.

  • To understand why a given software development team performs the way it does, we need to examine the organization in which the team exists. We can’t find the answers by analyzing the team in isolation.
  • The true team most likely differs from the team as defined on the org chart. The team on the org chart probably contains non-essential parts: that is, parts that cannot be said to be a part of the system, because they can be removed without impacting the output of the system. Also, the true team most likely contains people that are found in a totally different place in the formal organization.
  • We can’t split an effective team in two halves and expect each part to have fifty percent of the efficiency of the whole team. A team’s effectiveness derive out the interaction of its members, not the actions of the team members taken separately.

Svensk mjukvaruutveckling i SvD

Härligt! Lite uppmärksamhet på mjukvaruutveckling i Svenska Dagbladet. Tomas Augustsson har skrivit en artikel som bland annat tar upp den utmaning det innebär att vara chef i en mjukvaruutvecklande organisation.

Flera av de som arbetar med mjukvara pratar om att de högsta cheferna på företagen kom fram när det var hård­varan, själva apparaten, som var det avgörande. Nu har en del av cheferna svårt att förstå de annorlunda villkoren för mjukvaruutveckling.

Det blir viktigare och viktigare att vi lär oss vad som styr framgång och motgång i utvecklingsprojekt, eftersom en större och större del av de produkter vi tar fram består av mjukvara.

Vi ser hur mjukvaruinnehållet fördubblas var artonde månad, säger Sten Minör som är ansvarig för Sony Ericssons strategi när det gäller mjukvara.

Changes, Then Rules, Then Changes, Then …

David Schmaltz writes:

“Within SEI, there were (probably still are) two factions. I heard (just hearsay) that two principals at SEI approached two of the Agile Manifesto signatories to wish them luck shortly after the manifesto was made public. Apparently they had carried the same intentions in founding the SEI, but were compromised when the suits showed up.”

I have no idea whether this specific story is true or not, but I wouldn’t be the least surprised, because this is something that seems to be happening all the time. It’s probably a part of How Things Are. Something new starts growing, and as attempts are made to describe and spread that new thing, it gradually changes from being new to being something stale and overly simplified. In fact, the very things needed to spread that new thing are the same things that prevent it from staying fresh. So the new things dies – or rather transmutes into a new form. Gradually, the pressure builds for some other new thing to emerge, and eventually it does. When the changes are great, the transitions are painful.

So what can you do? I’ll tell you what I will do. I will keep checking my value compass, and if it shows me running off into the wild as I blindly follow my practice map, I’ll trust my compass over my map.

David concludes, in the comments to the post:

“I’ll serve spaghetti with sourkraut if I’m hungry and that’s what’s in the pantry. This because whenever a method gets embraced ideologically, whatever the method, the result is exactly the same. Mindfulness replaced by certainty. Thoughtfulness replaced by enforcement. Degrees of freedom transformed into degrees of imprisonment.”

– – –

Why not read a little tonight?

Computer Sweden missförstår om återblickar

Peter Larsson på Computer Sweden ringde upp mig efter att ha läst om återblickar och Scrum på min Scrumtips-blogg. Han frågade om brister i Scrum, och jag svarade som jag brukar, att det är svårt att peka ut brister i Scrum som modell, för den är ganska liten och tajt. Däremot finns det vissa problem som många springer på när man börjar med Scrum. En sådan är att man glömmer att göra återblickar, som är väldigt viktiga för att få arbetssättet att fungera. Återblicken är ju vårt sätt att gradvis bygga upp vår kapacitet som organisation, genom att hela tiden reflektera och lära oss.

Peter frågade mig rakt på sak om återblickar är en del av Scrum. Jag svarade ja, men uppenbarligen var jag inte tillräckligt tydlig, för i hans publicerade artikel skriver han istället raka motsatsen mot detta:

Ytterligare en brist i Scrum är avsaknaden av bra stöd för återblickar, det som på engelska kallas för sprint review. Det är tydligt vad projektet åstadkommit i varje sprint, men när det gäller att diskutera hur detta gjorts så uppstår problem.

De orden har, med rätta, lett till en del förvirring bland oss som intresserar oss för Scrum.

Lärdomen från detta är väl att det är klokt att insistera på att få läsa artiklar innan de går i tryck. Det borde väl ligga i båda parters intresse att det slutliga verket inte innehåller rena sakfel?

MVKJG 6: Lär dig om refactoring

Efter ett alldeles för långt uppehåll tar jag åter upp skrivandet av serien Men vad kan jag göra? – tips om saker som du kan göra idag, helt utan att be om tillstånd, för att förbättra tillståndet i ditt aktuella projekt.

Varje gång jag hör någon berätta om ett stycke särskilt hemsk kod de sprungit på kommer jag att tänka på när jag hittade en klass som var 17000 rader lång. Någonstans mitt i denna kompakta massa text fanns två metoder. Den ena hette “up”, den andra “down”. Båda var ganska långa och, visade det sig, helt identiska. Eller inte helt – ett tecken skilde faktiskt. Där det stod ett plus i den ena stod det ett minus i den andra. Det tog en stunds betraktande och ett diff-program för att ställa diagnosen. Sådan är klipp-och-klistra-programmeringens logik. Den enes snabba fix blir den andres huvudbry. Denna monsterklass var representativ för hela kodbasen.

Mitt uppdrag i projektet var väldigt tydligt definierat. Jag skulle vidareutveckla en viss modul i koden. Minnet av hur det kändes när jag först såg den kod jag förväntades bygga vidare på lever kvar. Självklart var den, som man brukar säga, nästan klar och bara några små tillägg skulle göras.

Den del av koden jag fick tilldelad var inte 17000 rader lång. Tvärtom var det en ganska kort klass. En kort och kompakt klass. En tät massa av kryptiska variabler och villkorssatser. Det jag kände när jag tittade på den var fruktan. Fruktan att jag inte skulle klara den uppgift jag fått tilldelad.

Jag minns inte om jag köpte Martin Fowlers lysande bok om refactoring efter min sammanstötning med detta monster till källkod, eller om jag just hade råkat köpa den. Hur det än var så räddade den boken mig.

Fowler beskrev i sin bok hur man kunde jobba i små kontrollerade steg för att omvandla oläsbar kod till läsbar kod. Han visade hur man försiktigt men målmedvetet kunde omforma spaghettikod till små kontrollerbara bitar.

Jag skred till verket metodiskt och omsorgsfullt. Eftersom jag jobbade i Visual Basic 6 hade jag inte tillgång till några automatiska verktyg för refactoring, men Fowlers instruktioner kunde följas steg för steg. Långsamt gjorde jag koden mer hanterbar. Jag bytte obegripliga variabelnamn mot begripliga. Jag bröt ned långa metoder i kortare, och gav dem mer passande namn. Jag tog bort överflödig kod. Jag strukturerade och städade, hela tiden efter Fowlers recept som visade hur jag kunde göra ändringarna på ett tryggt sätt. För första gången kände jag mig som en riktig programmerare (språket till trots skulle vissa säga). Till slut kunde jag göra de tillägg jag blivit ombedd att göra.

Fowlers definition på refactoring var “små designförändringar som inte ändrar kodens beteende”. Idag verkar en vanligare tolkning av termen vara “blandade tekniska förändringar av större och mindre sort”. Den sortens ändringar har vi redan tillräckligt av, men den sort Fowler avsåg är det fortfarande brist på. Därför, om du vill göra en skillnad redan idag, lär dig först vad refactoring betyder. Lär dig sedan att använda tekniken i praktiken. Förmodligen har du redan upptäckt att det finns inbyggt stöd för refactoring i ditt utvecklingsverktyg, så idag är det lättare än någonsin att börja skriva kod som andra inte behöver frukta att ta över, och det – det är att göra världen till en lite bättre plats.

– – –

Övningar

  1. Vilken bok skulle kunna rädda dig ur situationen du befinner dig i just nu? Beskriv din situation för en vän eller kollega du litar på och fråga om de har ett tips på en bok som skulle kunna hjälpa dig.
  2. Är begreppet refactoring känt bland de du jobbar med? Fråga några kollegor om hur de definierar refactoring.