Kærlighed ved første blik

Jeg tror, at jeg er blevet en lille smule forelsket. Det var sådan set nok det, som man kalder "kærlighed ved blik", for det var tydeligt allerede fra starten af, at vi tænkte på samme måde. Jeg har nemlig fundet et nyt program!

Det er faktisk et ret grimt program - der er ingen runde hjørner eller skinnende knapper med metallook. Og så alligevel, for det er helt klart lavet til at blive brugt, og får derfor sin egen funktionelle æstestik ... lidt ligesom en entreprenørmaskine, som kun fås i en farve (gul!), og hvor der ikke er levnet megen plads til gejl og pjat, men som alligevel er smuk på sin egen fascinerede måde.

Og hvad er det så for et program. Jo, det er den grafiske brugerflade, som kommer med git - aka. git-gui. Se selv:



Kan vi ikke blive enige om, at det ikke ligefrem er et program, som gør sig forhåbninger om at vinde nogen form for design-priser?

Men lad os kigge lidt på det: Når jeg arbejder, så starter jeg selvfølgelig med at lave et antal ændringer, og derefter laver jeg en liste over ændrede filer, som jeg så kører en diff på en ad gangen. Her bestemmer jeg med for, hvilke ændringer, som jeg vil have med i committet - og egentlig ret ofte opdager jeg, at jeg ikke var helt færdig: der er ofte noget, som kan gøre lidt bedre eller pænere. Og så tager jeg lige en iteration eller to mere.

Kast nu et blik på screendumpet. I panelet med den røde top er en liste over alle de filer, som er ændrede - eller nye - i mit arbejdsområde. Det var lige første trin, som jeg fik forærende. I panelet med den gule top, kan jeg se diff for den valgte fil - og det var andet trin. Efterhånden som jeg arbejder mig igennem filerne, så kan jeg klikke på ikonet ud for filnavnet, og så smutter de lige ned i panelet med den grønne top, som er en liste af de ændringer, der er planlagt til næste commit; og det er noget, som jeg normalt selv skal holde styr på. Nederst til højre er en god editor til at skrive commitkommentaren i - og selvfølgelig er den fremme hele tiden, så man kan udfylde kommentaren imens man reviewer sine ændringer, og ikke som det er for mig pt., nemlig at jeg må tage noter for mig selv undervejs, inden jeg til sidst får lov at skrive en kommentar.

Eller med andre ord: her er et værktøj lige efter mit hovede - alle de nødvendige dele er placeret nemt og overskueligt, lige inden for rækkevidde, lige hvor man har brug for det. Der er tænkt på det hele. Skønt!

Allerede her var jeg sådan set solgt, men bemærk så lige en ekstra lille detajle (det kan godt være, at du skal klikke på billedet for at se det i stor størrelse): filen Method.scala er nævnt både under unstaged og staged! Det er fordi, at jeg har rettet videre i den efter at jeg stagede den til commit først gang - og det diff, som jeg kan se under unstaged, er det, som er sket siden seneste staging - og det, som jeg kan se under staged er det, som er sket imellem seneste commit og seneste staging (eller det, som kommer med i dette commit, hvis ikke jeg gør yderligere). Det er en rigtig god lille bonus.

...og husk så på, at git er et distibueret versionsstyringssystem - når jeg engang committer, så er det kun imod mit lokale repository - for at det kommer videre, så skal det enten pushes videre af mig, eller pulles af andre.

Kloner og gists

Jeg må tilstå: jeg har en temmelig underlig interesse, nemlig versionsstyring og versionsstyringssystemer. Jeg har tidligere skrevet lidt forskelligt om emnet, men på det seneste er jeg så småt begyndt at interessere mig for Git.

Git i sig selv er mange ord værd, men det er faktisk ikke det, som jeg vil skrive om her; mest fordi at mine erfaringer indtil videre er noget begrænsede (for en knap så kort oversigtsartikel om git, vil jeg henvise til Wikipedia).

Næh, det som jeg har på hjerte er, at jeg har fundet git-hub, som er et site, hvor man kan få hostet sine git-repositories. Og hvis man er villig til at dele sin kildetekst med alle (det hedder vist nok "Open Source"), så koster det gratis.

Det, som man giver andre ret til, er at se hele versionshistorikken, og at starte deres egen variant - det hedder meget passende "kloning" - men ikke til at committe direkte til ens eget repository. Klassisk set er det, at få "gaflet" (forked) et projekt noget af det, som har givet anledning til de fleste søvnløse nætter og de største ord-krige, men her er det faktisk noget, som ikke alene er indbygget i både git og git-hub - det er faktisk noget, som man aktivt opfordrer til. For den bagvedliggende tanke er ikke, at vejene skal skilles for evigt, men i stedet at man for en kort bemærkning lige afsøger området omkring den slagne sti, for så at vende tilbage igen med det gode, som man måske fandt. For rettelser fra kloner kan snildt indarbejdes i det oprindelige repository, og herved har man nærmest vendt begrebet på hovedet: hvis kloning er noget man gør hyppigt nok, så er det en ting, som man kan udnytte positivt.

Og der er ingen der siger, at den oprindelige vej, er den bedste, så måske vil de fleste i stedet vælge det, som oprindeligt var en afstikker, hvorved det så bliver hovedvejen. Det vil i sandhed være realisering af begrebet "shared source": ingen ejer kildeteksten; og alle har lige ret til at komme med deres bud på fremtiden.

Nå, men inden dette bliver alt for lomme-filosofisk, så vil jeg lige pege på en sjov lille ting på git-hub, som de kalder for "gists" - det er en slags mini-repository, eller en slags offentligt klippebord for filer med fuld versionshistorik. Om det kan bruges til noget i praksis, ved jeg ikke helt, men jeg måtte simpelthen prøve det af, så jeg har oprettet mit eget lille gist - ikke noget specielt, bare et lille fragment fra mine første eksperimenter med Scala og Xml. Men kom og leg med, hvis du har lyst - det er det, som git-hub går ud på!

Fordi vi kan...

Kender I det der fænomen med, at en instans, en afdeling eller en styrelse opnår de facto monopol, og pludselig begynder at opføre sig uden hensyntagen til dem, som de egentligt oprindeligt er skabt for at betjene? Når man opdager, at kunderne ikke har nogen andre steder at gå hen, så kan man pludselig begynde at opføre sig mere eller mindre, som det passer en. Jeg kalder det for "...fordi vi kan!"-effekten.

Man ser det i firmaer, hvor lønkontoret - undskyld, "Human ressource" (...og hvornår er medarbejderne blevet til en råvarer på lige fod med A4-papir og elpærer?), år ud og år ind kan tillade sig at skrive mere eller mindre ulæselige lønsedler.

Eller i medarbejder-kantiner, betalt med faste månedlige løntræk, hvor man finder det helt rimeligt, at der ikke er andet et rugbrød og halvvisne salatblade tilbage til de stakler, som ikke stillede sig i kø inden åbningstidens begyndelse?

Vi så det også i sin tid, hvor vi fik TV-perler, som f.eks. HOPLA midt i den bedste sendetid. Eller Poul og Nulles julekalender, som indrømmet vel af stort set alle efterhånden, var helt ude i skoven.

Og hvorfor er det lige, at man kun kan komme til at ringe til en privatpraktiserende læge, hvis man er rask nok til at kunne have telefonen stående på genkald i en halv times tid imellem 8.00 og 9.00 om morgenen på en hverdag.

J0, såmænd "fordi vi kan!"

Jeg har lige opdaget en mere, og denne gang er det PostDanmark, som står for den:

Historien er, at jeg i min naivitet bestilte en spritny bog udenfor EU. Det er første oplag af første udgave, og på mit eksemplar er tryksværten knapt nok tør endnu (det er en bog som Scala, hvis I absolut må vide det). Jeg vidste godt, at der ville løbe noget moms og en del forsendelse oveni, og det er sådan set også rimeligt nok.

...men jeg havde ved gud ikke regnet med, at PostDanmark ville tage sig betalt med 120 gode danske hårdt marginalbeskattede kroner i "importgebyr" (plus 30 kroner i moms af gebyret oveni!) for at opkræve momsen (i mit tilfælde er det 73 kr.).

150 kr.!!! For hvad? Ja, for at vende pakken, skrive "50USD" på en computer, trykke på "print" og vente på at etiketten kommer ud, hvorefter den klæbes på pakken. Hvad kan det tage? Vel omkring et minut. Maks. Og det en handling, som bliver foretaget hvert dag i diverse supermarkeder, uden at de finder det nødvendigt at tage gebyr for det. Hvis vi tog de priser i vores branche, så ville vi alle være arbejdsløse stort set øjeblikkeligt.

"Jamen, der er jo meget mere i det - du skal jo også på posthuset og betale, med alt hvad deraf følger", hører jeg nogen indvende. Tjo, det er da rigtigt nok - og det kan vist bedst sammenlignes med en postopkrævning, som PostDanmark selv prissætter til et sted imellem 10 og 25 kr. alt afhængigt af, hvor fin den skal være.

150 kr. i importgebyr "... fordi vi kan!" Tak, PostDanmark. :-(

Scala i praksis

Jeg har brugt en del tid på det seneste på at kigge på sproget Scala, som er et spændende forsøg på at lave et multiparadigme sprog baseret på JVM'en. Jeg valgte Scala af en række grunde:

Vigtigst af alt, så oversætter Scala kode til JVM class-filer, og andre JVM klasser kan nemt integreres. Som Java kyndig brænder man altså ingen broer - man kan stadig bruge alt det, som allerede findes på platformen, og man kan flette ny Scala kode sammen med sin eksisterende Java.

Der er en ganske hæderlig typeinferens. Typeinferens ligner på overfladen "duck typing", men nedenunder findes et stærkt statisk typecheck. Det er en meget stor behagelighed, når man koder, for hvis typen kan regnes ud af sammenhængen, så klarer compileren det som hovedregel fint. Man undgår med andre ord at skulle gentage sig selv igen og igen overfor noget som virker som en meget tungnem compiler.

På den anden side, så kommer compileren en gang imellem og brokker sig over inkompatible typer. Hver gang har jeg tænkt, at her var den godt nok noget fatsvag, men hvergang har jeg modstræbende måtte erkende, at her havde den altså ret: Jeg havde ikke styr på, hvad jeg lavede og jeg var ved at blande fisk og cykler. Mine to mest almindelige fejl var, at jeg ikke var helt fortrolig med syntaksen for delvist anvendte funktioner (partial applied function), og når der havde sneget sig en anden resultattype ind (så funktionens resultat blev den fælles supertype i stedet for den første resultattype) .

Den tredje grund til at vælge Scala var, at det understøtter et funktionelt paradigme - det er nyt for mig, for jeg har stort set kun programmeret i imparative (procedurale og objekt-orienterede) sprog - med SQL som en mærkbar deklarativ undtagelse. Jeg har stadig meget svært ved at tænke funktionelt (Scala-kode kan også laves imparativt), men det er en stor lettelse for mig, at funktionen nu igen har fået en fornem placering i sproget - i Pascal var den nogenlunde med, men i Java har man holdt den objekt-orienterede fane så højt, at funktionen blev sat godt og grundigt i skammekrogen; det har gjort det nødvendigt for os at lave store og grimme krumspring undervejs for at omgå begrænsningerne. Da Scala er et funktionelt programmeringssprog, så har jeg pludselig fået nogle nye og spændende muligheder, som jeg ikke har set før, og som jeg virkelig kan se et stor potential i (mumle, mumle, golden hammer, mumle, mumle...)

Jeg tror nok, at det var Kung-fu-tze, der engang sagde noget i retning af:

"Læsning skaber en oplyst mand, overvejelse en vis mand - men kun handling den fuldkomne mand".

Jeg har læst, og jeg har overvejet ... og nu har jeg også prøvet at skrive mit første ikke-trivielle program i Scala. Det var egentlig en skrivebordsøvelse og baserer sig på ideen om, at skal man lave et godt hold, så skal man ikke finde folk, som er gode til de samme ting, men derimod folk som kan supplere hinanden.

Jeg havde den første prototype kørende på kun 14 liniers kode! Den havde godt nok hardkodet input, og kun en variant af klassifikationen, men ellers var der ikke snydt; den var fuldt funktionsdygtigt, og viste at princippet fungerede. Den baserede sig på lister, tupler, int og string - og derfor havde jeg tit svært ved at holde tungen lige i munden.

Efterfølgende er ansvaret blevet fordelt ud over diverse klasser, og alle klassifikationsregler blev implementeret. Herved steg antallet af kodelinier til det 10-dobbelte; det er en solid stigning, men stadig imponerede lidt problemstillingen taget i betragtning.

Lige nu er programmet oppe på ca. 230 linier, men så er der også parsning af input i løst formatteret tekstformat og pæn sortering, klassificering og formattering af output. Jeg tror, at et Java program til at det samme nemt kunne være løbet op i det 3-dobbelte antal kodelinier.

Et sprog, som kan spænde over at lave en kompakt teknologi-mockup og direkte op til et fuldt program - og gøre det godt hele vejen - det er da vist ikke helt skørt?

En ting, som jeg har bemærket undervejs, er funktionel programmering hele tiden får en til at overveje muligheden for generaliseringer - det er ikke mindst forklaringen på, hvorfor at koden bliver så kompakt - det ender med at blive noget som næsten ligner one-liners uden at det udarter sig til at blive Perl; man ender med kode præcis som man tænker.

En generalisering, som jeg stadig har til gode, er at eksternalisere kategorierne og klassifikationsreglerne. Jeg har sådan set allerede lavet det grundlæggende arbejde, for selvom de er hardkodet, så er det lister af instanser af nogle få kategoriklasser og nogle få meta-klassifikations-funktioner. Derfor kan programmet godt ende med at blive mindre igen, samtidig med at det bliver mere generelt.

Er alle timer ens?

Billedet til højre stammer fra Jeff Sutherlands blog-post "The Maxwell Curve: Getting more production by working less!", hvor han henviser til venture capitalist ved navn Scott Maxwell, som er kommet frem til den banebrydende konklusion, at man kan nå lige så meget ved at lade folk arbejde 40 timer om ugen, som hvis man presser dem til at arbejde 60 timer om ugen - ja, faktisk kan man få dem til lave endnu mere på de 40 timer, hvis man giver dem gode betingelser for deres arbejde!

Hvis man fornemmer en vis ironisk distance fra min side, så er det korrekt. Det er ikke fordi, at jeg er uenig - på ingen måde - det er mere, at jeg føler at det er nogenlunde lige så banebrydende, som hvis man havde konkluderet at jorden er rund, eller at der i gennemsnit er varmere om sommeren end om vinteren.

Jeg er heller ikke vanvittigt imponeret af grafen. Bevares, der er da nogle gode pointer i den, som man måske nok ville kunne komme til at overse, hvis man glemte at tænke sig om:

1. Der er en faldende grænsenytte på den ugentlige arbejdstid (vi økonomer ynder at tale om "grænse-et-eller-andet, og så tænker vi på det, som matematisk orienterede ville kalde den 1. ordens afledte...). Man når med andre ord ikke så meget på den 10. arbejdstime, som på den første.
   
2. Bliver arbejdstiden lang nok, så bliver grænsenytten negativ. Der er altså et punkt, hvor det at arbejde en time mere vil gøre at man når mindre - ikke fordi at man i den sidste time ødelægger noget, at det, som man har lavet i den første time, men simpelthen fordi at effektiviteten af alle timerne i en lang uge samlet set er mindre end effektiviteten af alle timerne i en kort uge.
3. Ved en fornuftig planlægning af arbejde, så kan man nå mere end ellers (et væsentlig bidrag til at "scrum"-kurven ligger højere er antagelsen om, at man undgår en pæn portion arbejde uden nytteværdi).
4. Nytten af arbejde kan blive negativ - vi kender det selv; der kommer et punkt, hvor det er bedre at gå hjem for at sove, for ellers vil man lave begynde er lave ulykker, som det vil tage længere tid at rydde op i bagefter.
   

Men derudover, så er kurverne i grafen alt for pæne og runde til, at det giver mening, at have så præcise tal på akserne - der der tale en principskitse, og der er ingen form for videnskabelig evidens bag (vi har kun Scott Maxwell og Jeff Sutherlands ord for det, og der er ingen indikation af, hvordan de er kommet frem til deres tal!).

Alle der har prøvet at arbejde i firmaer, som har en vis historie bag sig, ved at firmaerne over tid kommer til at akkumulere en vis mængde overflødige rutiner, formelle som uformelle, som ikke længere bidrager til noget. Ved at indføre scrum udfordrer man relevansen af alle rutinerne, og beskærer eller optimerer dem, hvor nødvendigt. Det er en god ting, og det vil give en større effektivitet - men at sige at scrum er godt af den grund alene, er nok et stort spring, for man kunne have realiseret samme gevinster med konventionelle metoder, ved at arbejde lige så målrettet med procesforbedring, som man gør, når man indfører scrum (i det ligger også, at arbejder man allerede målrettet med procesforbedringer, så er der ikke så stor gevinst ved at indføre scrum som ellers).

Nå, nu har jeg vist uddelt nok verbale øretæver til Scott og Jeff, for jeg tror faktisk at de har fat i noget væsentligt, nemlig: Sustainable velocity. Begrebet ser man flere og flere steder efterhånden, og det må nok ses som en modreaktion til den eufori, som greb alle i starten, hvor det nærmest gik ud på at smide så meget som muligt overbord, for at kunne sprinte hurtigst muligt afsted.

Det morer mig også ganske meget, at se at de to herrer regner sig frem til, at der ikke rigtig er noget merværdi i at arbejde ud over 35-40 timer per uge - det rammer lige ind i den gamle diskussion om vores "korte" arbejdstid i Skandinavien, hvor vi som modsvar altid har hævdet, at det er effektiv tid i modsætning til hvad de andre præsterede, og at det totalt set gav god mening.

I mit første job var jeg anset i et stort, internationalt firma, og der blev vores 37 timers arbejdsuge betragtet med stor skepsis - resultatet var, at vi fik løn for 37 timer, men der allerede ved ansættelsen blev udtrykt en forventning om, at man selvfølgelig arbejdede ca. 10% mere uden kompensation.

Nu var vi ikke dummere, end at vi godt kunne gange og dividere, så vi regnede det selvfølgelig bare ind i vores lønforventning, og så endte det mere eller mindre at med at gå lige op for os.

Det havde derimod den - for firmaet - kedelige effekt, at det var svært at opsuge de fluktuationer, som der kunne være i arbejdsmængden; når vi nåede et projekts afslutning, så var der tit brug for at "give den en ekstra skalle" for at nå i mål, og der var ikke rigtigt noget at hente hos os - vi arbejdede jo alle allerede over, og selvom vi godt kunne arbejde en smule mere over, så var det ikke noget, som endte med at kunne gøre en forskel.

Den anden effekt, som jeg kunne se, var at arbejdet ikke var så intensivt i den tid, hvor vi var der, som ellers. Vi skulle jo alligevel være der til langt ud på aftenen, så vi tog tit roligt i løbet af dagen - der var ingen grund til at koncentrere sig om at blive færdig, for der var jo masser af tid. Det var mærkeligt for mig, for jeg var i min studietid vant til at arbejde målrettet og koncentreret, når jeg arbejdede - men jeg vænnede mig til det. Det var til gengæld hårdt, da jeg skiftede arbejde til et firma, som satte en ære i at arbejdstiden i gennemsnit passede, for da skulle jeg op i gear igen, for at kunne følge med!

Så den gamle sandhed om, at den part, som allerede har sat reserverne ind inden slaget begynder, ofte er den part, som ender med at tabe, gælder også her. Man mister både effektivitet og tilpasningsevne - det bliver sværere at udnytte pludselige chancer og at imødegå uventede trusler. Og deri skal man nok også finde årsagen til at scrum iflg. Jeff og Scott trækker imod kortere arbejdstid - agile metoder er i bund og grund et spørgsmål om effektivitet igennem fleksibilitet.

Navngivne parametre

Jeg faldt over Alex Buckleys blogpost Named Parameters, hvor han diskuterer muligheden for explicit navngivne parametre i Java/JVM'en, og det er jo ganske interessant - ikke mindst i betragtning af, at det netop af Alex, som skriver.

For dem, som ikke kender Alex Buckley, så kan jeg fortælle, at han har overtaget Gilad Brachas plads som JVM'en kustode. Hans fornemmeste opgave er derfor at sige "Nej!" til alle de skøre forslag, som alle vi andre kommer med - og kun at lade en lille, vel gennemtænkt smule slippe igennem, så JVM'en og Java aldrig løber af sporet.

Om Gilad Bracha er der en lille anekdote: Jeg oplevede ham til JAOO for nogen tid siden (2005), og hans foredrag var om nye muligheder i JVM'en med henblik på at forbedre understøttelsen af dynamiske sprog (specifikt om invokedynamic). På et tidspunkt under foredraget kommer en slide op, hvor et punkt er markeret med "OMDB" (nederst s. 33 her). Jeg kan huske, at jeg sad og overvejede, hvad det stod for - "Object Method Data Base" eller måske "Overloadet Method Definition Basis". Vi kommer lidt længere hen inden at Gilad afslører, at OMDB står for "Over My Dead Body" - og det var det at jeg tænkte to ting:

1. Hvor var jeg glad for, at vi havde en så konservativ person til at hænge i bremsen på noget som vigtigt som JVM'en.
2. Hvis man siger sådan noget, hvad gør man så, hvis folk er villige til at tage en på ordet?
   

Nå, men jeg løber ud af en tangent - jeg ville jo snakke om Alex' blogpost om navngivne parametre...:

For dem, som ikke lige har tid til at læse Alex' blogpost, så kan jeg sige, at han identificerer to store fordele:

1. Øgede muligheder for at skrive kode, hvor det er umiddelbart til at forstå hjensigten - og ...
2. Muligheden for at angive parametre i vilkårlig rækkefølge, hvis de navngives (herunder nogle overvejelser om varargs).

og Alex konkluderer i Gilads ånd, at nr. 2 nok er en ide med store fordele, men at den vil have store problemer rent implementationsmæssigt - hvis man skulle bevare bagudkompatibilitet, vil det ikke er praktisk muligt, og der er andre udfordringer; hans holdning er dog, at nr. 1 allerede give så store fordele, at det er værd at overveje.

Jeg er enig.

...men nu er jeg også typen, som bliver irriteret hver gang jeg ser en metode, som tager en eller flere booleans som parametre, fordi at jeg ved, at jeg ikke om 3 måneder kan huske, om:

udskriv("en tekst", true, false)

betyder, at der skal udskrives med bold og ikke italic, eller omvendt - og derfor ender med at skrive:

final boolean isItalic=true;
final boolean isBold=false;
udskriv("en tekst", isItalic, isBold);

hvilket selvfølgelig øger antallet af kodelinjer med 200% (hvilket er skidt!), men som til gengæld klart giver udtryk for, hvad der var min hensigt, da jeg skrev koden (og det opvejer det efter min mening fuldtud).

Til gengæld er der tale om en noget af et deja-vu: Allerede i forrige årtusinde kunne man angive navngivne parametre i VAX-Pascal (VAX-Pascal fandtes til VAX/VMS mainframes fra DEC, og som sprog var det på mange måder forud for sin tid). Jeg husker ikke klart, om VAX-Pascal havde operator-overloading, men navngivne parametre var helt klart en del af sproget, som jeg brugte (ikke meget - bevares - som Alex er inde på, så er det nok mest en "smell" i grænsefladen, når man finder det nødvendigt) - og som jeg kom til at savne.

På samme måde har jeg stort set altid brugt parameterbinding i mine SQL-udtryk (fordelene er så mange og så indlysende, at jeg ikke vil nævne dem her) - og hver gang er jeg blevet irriteret over, at parameter-markøren i standard-SQL er et anonymt lille spørgsmålstegn. Som oftest har irritationen affødt, at jeg er endt med at skrive min egen lille wrapper, som tager en streng og et map (eller en lignende datastruktur), hvor der i stregen laves substitution på navngivne parametre, og at der formatteres en passende liste af parameterværdier. Det betyder, at man aldrig mere skal sidde og tælle spørgsmålstegn - og det betyder også dels, at man dels kan stoppe nye parametre ind i midten af et udtræk, uden at det hele kommer ud af sync - og dels, at man pludselig kan bruge den samme værdi flere gange uden at skulle gentage den.

Så, Alex, jeg er 100% bag dig - lad os få muligheden for navngivne parametre i Java - det er på høje tid!

Usikkerhed og uenighed

Engang for efterhånden nogle år siden, sad jeg og legede med et Hypercard stack - en fascinerende samling af noget, som blev kaldt "hypertext", og som blev kædet sammen af såkaldte "hyperlinks". Konceptet er i dag blevet så almindeligt, at vi ikke længere tænker over det, men dengang kan jeg huske, hvordan jeg blev fascineret over at starte en rejse et sted, og så via få hop, havne et helt andet sted.

Og det er lige sket igen - jeg startede egentlig med at trævle de mange blogs, som jeg følger med i, igennem for at se, om der skulle være noget interessant. Og så pludselig via et par mere eller mindre tilfældige hop, så mødte jeg pludselig noget, som kaldes "Stacey matricen" - og den vil jeg godt fortælle lidt mere om her (jeg har lige mødt den, som en god omgang snusfornuft og sund kildekritik, vil nok være på sin plads, min kære læser!).

Stacey-matricen har to dimensioner: Usikker/sikker hhv. uenig/enig.

Sikkerhedsdimensionen går på, om det er noget, som man har prøvet før mange gange før, eller om man er på vej ud i ukendt farvand - enighedsdimensionen går på, i hvor høj grad alle involverede parter har samme opfattelse af, hvad der skal til.

Hvis man accepterer dette landkort, så er der en række regioner:

Sikker/enig: Man er enige om, hvad der skal laves, og der er er ingen tvivl om, hvordan det skal gøres. Man kan bygge på tidligere erfaringer, og det er sådan set bare om at komme i gang.

Usikker/enig: Hvad der skal laves er klart, men hvordan er mere usikkert. Hold fast i visionen, og lav så plads til eksperimenter med hvordan det skal laves. Gør plads til prototyper, og "vildmænd".

Sikker/uenig: Der er styr på teknikken, men der er ikke enighed om, hvad der skal laves. Tilgangen skal her være politisk.

Ovenstående tre kendetegnes ved at være relativt uproblematiske rent metodemæssigt. Hvis man udviser situationsfornemmelse og snusfornuft, så er ikke specielt kompliceret. Det er også her, at mange lærebøger og metodikker boltrer sig.

Men helt ude i den anden yderligehed befinder sig:
Usikker/uenig: Her er kaos. Der er ingen enighed om, hvad som skal gøres - og slet hvis den var der, så er der ingen, som har prøvet det før. Man er kort sagt på Herrens mark.

Imellem den sikre grund med de første tre situationer, og randen af det kaos, som skitseres af den fjerde situation, befinder der sig i Stacey's tankegang en stor gråzone af komplekse situationer. Hvor kaoszonen kan være nedbrydende, og derfor noget, som man sandsynligvis vil forsøge at arbejde sig ud af (man kan også vælge at forsøge at ignorere den, og håbe på det bedste - vel en meget menneskelig, men nok ikke særlig hensigtsmæssig strategi), så er kompleksitetszonen et område, hvor der i gode tilfælde sker udvikling og innovation. Ulempen er, at man er dårligt hjulpet rent metodemæssigt.

Læs f.eks. mere om Stacey-matricen her (god beskrivelse, flot grafik), her eller her (lidt længere - har til gengæld til sidst et forsøg på at give gode råd til, hvordan kan navigerer det ukendte farvand).

Hvad kan vi så bruge denne tankegang til? Tjo, jeg vil jo mene, at vi i IT-branchen har en tendens til at koncentrere os så meget om "hvordan"-delen, at vi i høj grad - bevidst eller ubevidst, har en tendens til at ignorere "hvad"-delen. Eller i Stacey's termer, så kan vi håndtere usikkerhed, men forudsætter os ud af uenighed.

Vi ser det dels i BDUF's (jeg vil ikke sige "vandfald", for vandfald var oprindeligt en iterativ metode, som bare med tiden er blevet perverteret) insisteren på, at alt kan regnes ud og aftales på forhånd - men vi ser det også i Scrum's antagelse om at der findes een Product Owner, som er i stand til at agere lokalt orakel på, hvad der pt. er vigtigt (han er vist lige så almindelig som Julemanden og Påskeharen...!).

Men Stacey siger jo netop, at enighed ikke er noget, som man kan forudsætte - er den der, så giver det en lang række fordele for den opmærksomme, men ellers så skal vi være klar til at håndtere dens fravær. Og vi skal ikke grave os ned i tanken om, at hvis vi bare bruger tid på at få styr på teknikken, så vil der nok i mellemtiden udkrystallisere sig en eller anden form for magisk koncensus, så vi kan komme i gang med at levere. Vi bliver ikke (nødvendigvis) en succes, bare fordi, at vi har styr på f.eks. konstruktion, teknik, dokumentation, konfigurationsstyring eller kvalitetskontrol. Hvis man ikke ved hvor man skal hen, så er det ligegyldigt hvor hurtigt at man er i stand til at bevæge sig.

Den anden ting, som jeg mener at vi skal lære af Stacey-matricen, er den simple at forsøge at reducere to-fronts-krigene. Hvis der er enighed, så er der plads til eksperimenteren med, hvordan man bedst løser opgaven. Og hvis der er styr på, hvordan opgaven skal løses, så er der bedre plads til diskussion af, hvad der skal laves. I det sidste ligger måske også en opfordring til at have tålmodighed med kunderne, når de begynder at diskutere det trivielle - i virkeligheden, så kan det være udtryk for en glimrende situationsfornemmelse, at de ikke politiserer det vanskelige...!