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...!

Agil fotografering

Jeg hørte engang en sige, at hvis man skrev af et sted fra, så var det plagiat - men hvis man skrev af tre steder fra, så var det forskning! Og der er gran af sandhed, for ved at udvælge og sammenstille, så beriger man alle de oprindelige bidrag (og kommer herved med sig eget bidrag).

Jeg har prøvet at gøre mig den tanke til et mål for denne blog, og prøver derfor at få flere vinkler på en sag - og hvis jeg virkelig kun har en kilde, så i det mindste at supplere den godt med egne tanker. Men jeg vil gøre en undtagelse her, for jeg vil bare bringe et link til en blog-post om:

agil fotografering

Jeg har jo både prøvet at tale om agile metoder og om fotografering på denne blog, for begge dele optager mig meget. Men at kombinere dem, som i ovenstående - det havde jeg ikke lige tænkt på - og derfor er den chance for god til at lade få fra sig.

Agilister in spe kan læse artiklen som en kort, og rimelig OK, beskrivelse af store dele af området; og måske inspiration til at lade være med at være for snævertsynet og ortodoks i udlægning af teksten - og fotonørder kan finde inspiration til at gøre tingene anderledes og grænsende til det dogme-lignende, uden dog at blive direkte dogmatiske.

Stop op, og tænk dig om!

Det sidste stykke tid er vi nogle stykker, som har brugt en god del af vores tid på, at sidde og skrive testcases til vores nuværende projekt. Altså ikke småhygget med at programmere automatiske tests, men siddet og skrevet hardcore manuelle tests med "blyant og papir (dvs. vi har heldigvis en god wiki, og det gør arbejdet mange gange nemmere - hvis du er så uheldig, at du ikke ved, hvad en wiki er, så tænk "tekstbehandling", og du er ikke helt galt på den).

Man kan sige, at det er noget sent i forløbet, at vi får taget os sammen til at skrive testen - vores system har, for størstedelen af det, været i produktionslignende pilotdrift i noget, som efterhånden begynder at ligne et års tid. Når vi aldrig fik skrevet en formel test i første omgang, så er det nok fordi, at applikationen er groet langsomt frem, og pilotdriften er noget, som næsten er kommet snigende. Men nu, hvor applikationen bliver godt og grundigt hovedrenoveret, så er det en glimrende lejlighed til at få skrevet sådan en test.

Vi, der skriver testen, kender applikationen så godt, at vi sidder og skriver den "kold". Vi sidder altså ikke med applikationen kørende i baggrunden, imens vi skriver - vi skriver bare testen direkte fra hovedet og ned på papiret. Derfor kom det også som noget af et chok for mig, at min kollega pludselig kigger op og siger: "Bjarne, jeg har fundet en større fejl!" Jeg mener, fejl det er da noget, som man finder, når man prøver at bruge applikationen, ikk'? Og den har været i drift igennem længere tid uden problemer - så hvordan kan han sidde der, og så lige ud af den blå luft sige, at der er en fejl?!?

Men der var en fejl. En måde at bruge applikationen på, som ville give vildledende resultater. Det er nærmest tilfældigheder, som har gjort, at vi ikke er rendt ind i den - og vi introducerer lige om lidt ny funktionalitet, som ville have gjort det ganske sandsynligt, at rigtigt mange ville have oplevet det i praksis. Den eneste grund, til at vi fandt den nu, var, at vi, i og med at vi skulle skrive testen, havde tvunget os selv til at sætte os ned, og tænke applikationens brug systematisk igennem.

Micheal Feathers beskriver det samme fænomen i sin blog-post "The flawed theory behind unit testing". Det spørgsmål, som han stiller sig selv, er egentlig meget simpelt: Hvordan kan det være, at programkode, som er blevet unittestet, indeholder færre integrationsfejl? Og her tænker han ikke på fejl, som kunne være fundet af en unittest, men som på grund af utilstrækkelig unittest, først bliver fundet i integrationstesten - næh, det som undrer ham er, at det at lave unittesten tilsyneladende forhindrer flere fejl i at opstå, end hvad selve testen rent faktisk verificerer. Læs selv hans blog, den er kort og letlæst, og den kommer også forbi andre emner, som f.eks. TDD.

Michaal Feathers konklusion er, at unittestens umiddelbare værdi ikke så meget af selve testen (selvom han ikke er blind for, at automatiseret test øger muligheden for at lave efterfølgende ændringer på en sikker måde), men derimod at det tvinger os til at sætte os ned og tænke systematisk over det, som vi vil lave (eller måske lige har lavet). Han siger selv afslutningsvist:

The truth is more subtle than that. Quality is a function of thought and reflection - precise thought and reflection. That’s the magic. Techniques which reinforce that discipline invariably increase quality.

Det var det, som min kollega oplevede - og jeg har selv oplevet det, når jeg har siddet og skrevet unittest: Pludselig finder man grundlæggende logiske fejl i det, som man har implementeret - altså ikke fejl i implementationen, men i præmisserne for den. Jeg har bare ikke rigtigt tænkt over det, førend Michael Feathers satte sin finger på det.

Kelly Waters er inde på noget af det samme i sin blog-post "Agile project initiation": Her beskriver han de lange dokumenter, som mange projektmodeller foreskriver, at man udarbejder inden et projekt starter op - dokumenter på over 50 sider, som det er vanskeligt at få nogen til at læse. De fleste folk, som skriver noget med "agil" i deres CV, vil her sige, at hvis der ingen er, som læser det, så skal man helt lade være med at skrive det. Men Kelly Waters bemærker, at det giver ham værdi - det tvinger ham nemlig til at tænke projektet igennem på en systematisk måde. Hans bud på, hvad man så gør, er at lave det som en powerpoint-præsentation, for dels kommer han igennem de samme overvejelser, og dels så kan han bruge det, som en diskussionsoplæg, og derved ydermere få en feedback, som han ikke oplevede ved de lange dokumenter. Powerpoint virker for ham, men pointen er vel, at alt hvad der ville tvinge ham til at arbejde sig systematisk igennem overvejelserne, ville være lige så godt.

Så, stop op, og giv dig tid til at tænke dig godt om - det er bedre, at komme stille og roligt afsted i moderat fart i den rigtige retning, end det er straks at sprinte afsted i den forkerte. Men det er ingen opfordring til at tage en "morfar" i hængekøjen - det virker kun, hvis du tvinger dig selv til at arbejde dig systematisk igennem det.

PS: Måske er det derfor, at COBOL programmer stadig er så udbredte - der er man pinedød nødt til at tænke sig godt om, inden man gør noget! :-)

Sommerens fugle

Græsrandøje

Sommeren i år bød på et par nye sommerfugle:

En par græsrandøjer var så venlige at lægge vejen forbi, og der er jo tale om en fredelig og godmodig sommerfugl. Efter sigende skulle det være en af Danmarks talrigeste sommerfugle - det kan godt være, at jeg ikke har vidst, hvad jeg skulle kigge efter, for den var ny for mig.

Og så kom der en blåfugl på fransk visit. Det var godt nok en sky lille sag. Jeg fik kun et billede af den - på alle de andre billede nåede den lige at flyve. Jeg tror, at det dels var modlysblænden, som kom for tæt på, og dels så har jeg den mistænkt for at reagere på lukkerlyden -

Blåfugl

når spejlet på min D70 smækker op, så kan det høres, og hvordan pokker skulle den eller kunne nå at lette, lige inden billedet blev taget, flere gange i træk? Efter 10 minutter forsvandt op over hækken til naboen, og jeg har ikke set den siden.

Kålsommerfugle er derimod gamle kendinge. De var meget talrige i år, og de fulgte endda med os på ferie på Sjælland! :-) Et eksemplar var så venligt at forvilde sig ind i vores stue, og valgte at sætte sig midt på et af de store stuevinduer. Det gav et ganske heldigt billede, hvis jeg selv skal sige det - havde jeg vidst det, så havde jeg nu nok lige pudset ruden først. Jeg håber ikke, at alt for mange bliver fornærmede over, at jeg lukkede den forsigtigt ud bagefter - det er vist mest et skadedyr.

Takvinger i diverse afskygninger var der myriader af - dog så jeg ingen admiraler i år, hvilket egentlig overraskede mig lidt. Men alt i alt har det været et udemærket sommerfugleår for mig - ikke mindst pga. den ligustersværmer, som jeg tidligere har skrevet om.

Kålsommerfugl

Støttehjul

Jeg har lige fået flg. lille anekdote fra min bror, som er postbud:

Vi har fået nye fronttasker (på størrelse med en kuffert), og der er derfor monteret støttehjul på cyklen, som kan sættes ned ved parkering.

Reaktionerne udeblev ikke ;-)

Jeg kommer cyklende forbi to drenge i en alder, hvor man ikke mere kører med støttehjul. Den ene råber til mig: "SKAL du køre med støttehjul?"....jeg svarer hurtigt. "jeps, det skal man, når man er post", og cykler videre.

Jeg hører svagt han siger til sin ven, at det godt nok er synd for mig, at jeg stadigt skal køre med støttehjul på cyklen ;-)

Lidt senere på dagen ser jeg de samme 2 drenge lidt bagved mig. Jeg er lige kommet ud af en indkørsel, og springer på cyklen og tager støttehjulene op.

Så er det at den ene dreng siger: "Hold kæft det er sejt; han kan slå sine støttehjul op, når han ikke gider bruge dem mere."

Helt ærligt. Så kan man altså ikke lade være at trække lidt på smilebåndet.

Næh, jeg kunne i hvert fald ikke... :-)

Pas på falske profeter!

Jeg skrev tidligere under titlen God SOA, at SOA ikke er at spørgsmål om teknik, men om forretning. Det mener jeg stadig, og derfor kan jeg ikke lade være med at henvise til en, som er af samme overbevisning: Ten ways to tell it's not SOA.

Det er en letlæst lille sag, og jeg kunne ikke lade være at grine over udtryk som "JBOWS" (just a bunch of webservices) og "services in silos".

Indre klasser

I, mine faste læsere, kender mig godt nok til at vide, at det ikke er samfundskritik, som overskriften lægger op til. I stedet vil jeg filosofere lidt over den syntaktiske finurlig med dette navn, som jeg har stiftet bekendskab med i programmeringssproget Java.

Det, som har inspireret mig, er et indlæg på Michael Feathers' blog: Are Nested Classes Really a Good Idea? Jeg kan godt afsløre her, at det synes han ikke, men han er fornuftig nok til at mene, at det mest er et spørgsmål om stil. Indlægget er ikke længere end, at jeg vil opfordre til, at man selv læser det.

Langt hen ad vejen er jeg enig med Michael Feathers - når de indre klasser har tyngde nok til at være "rigtige" klasser, så er det ofte sådan, at det er bedre at gøre dem til det - altså rigtige klasser for sig selv. Indre klasser er ... ja, ikke sådan direkte forkerte, bare akavede - de ødelægger ofte rytmen i programmet.

Når jeg koder, så skriver jeg ofte og gerne indre klasser. Det sker, når jeg under kodningen ser et skift i abstraktionsniveauet, eller måske identificerer jeg et afvigende ansvarsområde; det er de her små urenheder, som måske - måske ikke - er starten til udkrystalisering ... og det er her, at jeg ofte bruger indre klasser. Man kan mene, at jeg her lige så godt kunne have lavet en rigtig klasse fra starten af, men det meget hurtigere - og på sin vis også langt mere uforpligtende - lige at lave en indre klasse.

På det tidspunkt, hvor jeg kan mærke, at nu har koden fundet et naturlig leje, så er der en tendens til, at jeg løber de indre klasser igennem. De indre klasser, som har tyngde og substans, vil jeg som tommelfingerregel forfremme til "rigtige" klasser - og for de øvrige vil jeg ofte overveje, om ikke der findes alternativer, som lige så vel kan kommunikere den "lille" indre klasses struktur og hensigt. Det er sjældent, at jeg committer kode med indre klasser, som bare er klasser (i modsætning til closure-agtige indre klasser, men det kommer jeg til).

Måske er min fremgangsmåde opstået fordi, at jeg kommet til Java via Pascal - jeg husker stadig smerten ved ikke at kunne lave lokale funktioner og procedurer: Jeg følte, at jeg blev tvunget til at gøre klassen ujævn i sin natur, og jeg havde svært ved at leve med, at jeg ikke kunne begrænse scope for en metode til en sub-kontekst. I virkeligheden, så har det vist sig, at jeg kan komme langt med at dele klassen op i interface og implementation (og understrege dette med bevidst brug af synlighed) - og hvor det ikke er nok, så er det ofte fordi, at jeg prøver at gøre for meget på en gang.

Det, som normalt får mig til at tøve en kende, er, når den indre klasser er meget tæt koblet til den ydre klasse, og måske endda nært forbundet til implementationen af den. Tit er det bare dovenskab eller manglende klarhed i ansvarfordelingen - men tit er det også ubehaget ved at forurene pakkens interface med noget alt for detajleret og måske internt af natur; for den oprindelige ydre klasse var ment til at skulle bruges for andre udefra, mens den indre klasse mere var en service for den oprindelige yde klasse. Løsningen er den samme, som for metoder i klasser: man erklærer kun det, som er del af interfacet for public (en lille sidebemærkning: lige så vel som klasser har et interface, så har pakker det også - og ofte drevet af de samme overvejelser; og når Java får et eksplicit modulbegrebet, så får vi endnu et niveau, at definere interfaces på ... men det er en anden historie).

Javas "far", James Gosling, skrev for nyligt under titlen Closures bl.a. flg.:

In the early days of Java the lack of closures was pretty painful, and so inner classes were born: an uncomfortable compromise that attempted to avoid a number of hard issues.

Indre klasser er mao. noget, som ikke engang dets ophav vil kendes ved!

Closures er (eller måske rettere: har indtil for nyligt været) meget omdiskuteret i Java kredse, og det er vel netop det sted, hvor jeg selv anvender indre klasser mest eksplicit, nemlig når jeg gerne vil skille det generelle fra det specifikke. Man kan selvfølgelig prøve med template method og nedarvning, men personligt, så fortrækker jeg ofte noget, som i stedet bruger komposition (og derfor mere ligner strategy): I den generiske del erklæres et indre interface, og når det generiske skal anvendes, så bliver interface som oftest implemeteret ved en indre klasse hos anvenderen.

Closures vil da gøre dette nemmere, og den typiske indvending imod closures, nemlig at de ofte er anonyme, er, på samme måde som ved anonyme indre klasser, selvvalgt - og vel også i bund og grund et spørgsmål om stil. Men netop her er smerten ikke så stor, for indre klasser løser faktisk den del rimeligt OK - der findes værre dele af Java. Synes jeg.

Så, for lige at vende tilbage, og svare på spørgsmålet i Michael Feathers' overskrift: Nej, indre klasser er ikke ligefrem nogen genial ide - men på den anden side heller ikke nogen udpræget dårlig ide ... hvis bare man bruger den med omtanke og omhu. Og det kan man jo sige om så meget!

Multiple specialer

Rasmus bloggede for en uges tid siden under titlen "Hvad gør et team crossfunctional?" om nogle af de udfordringer, som er forbundet med at skulle skulle nedmande, set ud fra de erfaringer som han har gjort sig med et konkret scrumteam (et team, som jeg indtil i år også var med i, så jeg bærer noget af skylden...). Det udartede sig til en godmodig meningsudveksling imellem Rasmus og mig om begreberne "cross functional" og "generalizing specialist" - begreber, som jeg gerne vil tale mere om her:

Lad os tage "cross functional" først, for det er på mange måder den nemmeste. Wikipedia skriver i artiklen "Cross functional teams" bl.a. flg.:

In business, a cross-functional team is a group of people with different functional expertise working toward a common goal.[...]

Cross-functional teams often function as self-directed teams responding to broad, but not specific directives. Decision-making within a team may depend on consensus, but often is led by a manager/coach/team leader.

A non-business, yet good example of cross-functional teams are music bands, where each element plays a different instrument (or has a different role).

Cross-functional er altså en egenskab ved en gruppe af mennesker - et team - og siger derfor ikke andet om medlemmerne i teamet, end at de kommer fra en forskellig baggrund.

Som det ses, så kommer Wikipedia også kort ind på den typiske beslutningsstruktur i et cross functional team, dog uden at uddybe det nærmere. Umiddelbart kan jeg dog ikke se nogen direkte sammenhæng - et team kan godt være cross functional uden at være konsensusbaseret; og omvendt, så kan et team godt være konsensusbaseret uden at være cross functional - når man måske nok ser en sammenhæng, så skyldes det efter min mening snarere, at de omstændigheder, som gør at man vil foretrække et cross functional team, også vil gøre, at man vil foretrække at gøre teamet selvbestemmende.

Umiddelbart ser det ud til, at den bedste kilde til det andet begreb - generalizing specilist - er Scott W. Ambler (han er i hvertfald ikke selv ked af at tage æren som ophavsmand); se f.eks. her: Generalizing Specialists: Improving Your IT Career Skills. Han skriver flg. om emnet:

A generalizing specialist is more than just a generalist. A generalist is a jack-of-all-trades but a master of none, whereas a generalizing specialist is a jack-of-all-trades and master of a few.

...og fortsætter:

Similarly, a generalizing specialist is more than just a specialist. A specialist is narrowly focused on a single topic, making them very effective at that topic but not at others. Specialists will often be blind to the issues which other specialists focus on [...]

En generalizing specialist er med Scott ord altså mere en "både og" end en "enten eller"; en person, som formår at kombinere det bedste fra generalisten og specialisten - og han understreger senere, at man helst ikke er specialist på bare et enkelt område, men gerne på adskillige - hvis bare man har dybden; dybden er vigtigere end bredden, for hvis man mangler dybde, så er man i bedste fald kun en generalist. Han anerkender dog, at dette ikke sker ad sig selv, og et ekspertise er noget, som kommer med erfaringen.

Det nærmeste Wikipedia har om emnet, er artiklen om versatilister - det er efter min mening ikke helt det samme, men trods alt så ens, at Scott anderkender begrebet som et synomym til generalizing specialist - og at Wikipedia linker til Scotts artikel.

Generalizing specialist er mao. en egenskab ved personen, og ikke ved teamet.

Generalizing specialist og cross functional teams er altså to forskellige begreber. Men begreberne er alligevel forbundne, for som Scott selv fremhæver, så det lige så god en ide at kunne spænde over flere specialer for et team, som for en person; på mange måder er det den samme ide, bare på to forskellige niveauer.

Begreberne er også fælles om at fokusere på kombinationen af specialer som det bærende element; hvis ikke, så er det bare den store middelmådighed, og det er ikke målet med nogen af dem. Og Rasmus' bekymring ved nedmanden er vel præcis den, at når opgaverne skal fordeles over stadig færre , så risikerer det at blive udvandet så meget, at muligheden for at specialisere sig går fløjten.

Det er svært at tale om scrum uden også at have en mening om generalizing specialist og cross functional teams som begreber. En oplagt grund er, at scrum fokuserer på opnå excellens, og det opnår man ikke uden at involvere specialister, men personligt mener jeg, at der en anden, og vigtigere grund: Grundtanken i scrum er, at et team som får lov at samarbejde om at løse sine opgaver på en regelmæssig måde, over tid vil lære at blive bedre og bedre til det.

Det vigtige er at altså teamet og regelmæssigheden - men hvor blev så det med cross functional og generalizing specialist egentlig af? De er der stadig, men årsager som er mere indirekte. Jeg kan umiddelbart se to:

For det første, så er det en forudsætning for at kunne lære som team, at man kan samarbejde. Det er ikke nok at trække opgaverne fra en fælles liste - eller for sags skyld, klistre dem op på en tale, og stå og snakke om dem en gang om dagen - hvis en person altid løser "de grønne opgaver" og en anden person altid løser "de røde opgaver". Det er ikke samarbejde, det er samtidigt arbejde! Cross functional er altså ikke nok for et team (det er vel end ikke et team, idet det "fælles" mål bare er kombinationen af en række individuelle mål). En generalizing specialist en umiddelbar fordel i forhold til at samarbejde, i det han allerede er vant til at spænde over flere specialer, og dermed allerede i sig selv er brobygger, og han vil derfor virke fremmende på samarbejdet i teamet.

For det andet, så er det en forudsætning for at kunne opnå en regelmæssighed, at teamet skal kunne tilpasse sig en vis variation i opgaverne - og det opnår man dels ved at have en vis bredde ved at være cross functional - men også ved at have en vis intern fleksibilitet, hvorved generalizing specialists igen bliver vigtige. Et team, som kun består at specialister, vil kæmpe for at tilpasse opgaverne til teamets profil - et team af generalizing specialists vil i højere grad tilpasse sig opgaverne karakter og lære at løse dem godt.

Fleksibiliteten er derfor vigtig. Man kan med en vis ret sige, at det bedste værktøj ikke altid er det mest specialicerede værktøj, men måske snarere det værktøj, som man har ved hånden. Jeg har prøvet at lodde med et stearinlys, og jeg har da også (gys!) lavet "mesterskruer" med batteriet på min skruemaskine.

Men på den anden side, så skal man passe på - fleksibiliteten har en pris. Man skal overveje, hvad der er ved at ske, hvis man igen og igen står med værktøj, som ikke passer til opgaven - loddekolber er bedre end stearinlys; og hvis man endelig falder for at lave "mesterskruer", så er en hammer bedre (endnu bedre er det selvfølgelig at have materialer, som passer til opgaven!). De forhåndenværende søms princip er altid en nødløsning; en næstbedst i bedste fald - og vil derfor aldrig give så godt et resultat, som at gøre det rigtigt. Det er på samme måde med et team - selvom opgaverne skal kunne ramme skævt i forhold til teamet uden at det er en ulykke i sig selv, og selvom et godt team kan klare næsten hvad som helst, så er det vigtigere at have det rette sammensætning af teamet end at klare sig med hvad man nu engang har.

Cross functional teams bestående af generalizing specialists kan være overraskende robuste og brede, men må ikke forveksles med forveksles med et hold af generalister, også selvom det ved første øjekast kan være nemt at overse forskellene. Resultaterne (og teamet) vil lide under det!

Afslutningsvist - og i nogen grad "off-topic"- så er der endnu en fordel i kunne spænde over flere specialer, som person eller som team, som egentlig ikke har noget med ovenstående at gøre (og som vel også er noget overset i sammenhængen): De innovative og kreative løsninger kommer sjældent indenfor et enkelt speciale; specialer kan være meget konserverende, og specialister kan være meget konservative - ofte kommer det fra brydningsfeltet imellem flere specialer - og et aktuelt eksempel kunne være neuroøkonomi. Men det er en helt anden snak.

Ligustersværmer

Fra Makro

I går aftes var jeg lige en tur ude i vores have, og der falder mit blik på en af de opbindingspæle, som vi har stående bl.a. ved vores nyplantede frugttræer - og så fik jeg mig noget af en overraskelse, for der sad et stort insekt. Altså ikke "stor" på den måde, hvor en skovmyre er "stor" set i forhold til en havemyre, men bare stor!

Jeg måtte derfor ind og hente mit kamera og har da også fået et par billeder (i slutningen af albummet "Makro" er der en fem billeder - se linket under billedet).

Ud fra billederne og en gennemsøgning af nettet, så har jeg besluttet mig for, at det nok er en af vores almindelige aftensværmere, nemlig en ligustersværmer (sphinx ligustri). Det var godt, at jeg havde billederne at støtte mig til, for jeg har aldrig set sådan en før, og uden billederne havde jeg nok gættet på en anden og mere sjælden art.

Ligustersværmeren er en af de største danske sommerfugle. Jeg nænnede ikke at forstyrre den, selvom jeg meget gerne ville have set den sværme, så vi må nøjes med billeder af den med vingerne foldet pænt sammen som her - men selv sådan synes jeg, at den er imponerende; pælen, som den sidder på, er ca. 45 mm i diameter.

Turen på nettet var også en tur tilbage til "barndommens gade", for ligustersværmerens store, flotte og meget karakteristiske larve husker jeg tydeligt, at vi som børn gik og fandt i genboens ligusterhæk. Der står i et katalog over skadedyr på nettet, at skaderne fra ligusterlarverne meget begrænset, så hvis man skulle finde en, så var anbefalingen at kalde på børnene og i øvrigt at passe godt på den! Hvis I overrasker mig ud på sensommeren med hovedet i busken, så ved I nu hvorfor.

Er syntaktisk sukker tomme kalorier?

Jeg havde i denne uge fornøjelsen af, sammen med Rasmus, at deltage i et gå-hjem-møde om "C# 3.0 og LINQ" arrangeret af Niels Ladegaard Beck fra Trifork. I forbindelse med gennemgangen af nye features i C# 3.0 lød det på et tidspunkt som om, at Niels nærmest undskyldte, at der nok mest var tale om "syntaktisk sukker". Det fik mig til at sidde og tænke over, om hvorfor syntaktisk sukker nærmest er blevet et skældsord, og på om det er rimeligt?

Lad os starte med at prøve på at definere begrebet "syntaktisk sukker". Her er et godt bud:

Syntactic sugar gives the programmer an alternative way of coding that is often more practical, more conducive to a better programming style, or more natural to read. However, it does not typically affect the expressiveness of the formalism or permit the language to do something new.

(kilde: Wikipedia: Syntatic sugar).

Syntaktisk sukker er altså en anden, og måske mere bekvem, måde at sige det samme på. Hvis man kan sige noget nyt, så er det per definition ikke syntaktisk sukker. Og så er det, at asketer og purister siger fra - en måde at gøre tingene på, det må da være mere end rigeligt, vil de mene!

Men hvad er det så lige, at formålet med et programmeringssprog egentlig er? Ja, vel indlysende nok, at være medie for en instruktion til en computer, men vel mindst lige så indlysende, at gøre det på en human og forståelig måde.

Hvis man har prøvet at være i en situation, hvor man er normsættende, så har man sikkert også på et tidspunkt hørt sig selv sige: "Du skal ikke gøre, som jeg gør - du skal gøre, som jeg siger!" Med computere er problemet lidt omvendt, og havde man kunnet tale til dem, så ville man sikkert kunne høre sig selv sige: "Du skal ikke gøre, som jeg siger - du skal gøre, som jeg mener!" På samme måde, så har man, når man har prøvet at forklare noget til andre, sikkert også hørt sig selv sige: "...lad mig prøve at forklare det på en anden måde".

Et godt sprog skal derfor dels kunne give utvetydige instruktioner, men samtidig formidle en præcis forklaring af hensigten. En præcis forklaring uden unødige omsvøb er en god forklaring - også selvom den måske ikke lige overholder den gængse opfattelse af formalia og regler for, hvad der er den rette tone. Syntaktisk sukker er derfor et spørgsmål om forklaringsevne, og ikke et spørgsmål om udsagnskraft. Syntaktisk sukker giver os muligheden for at formulere os på mere end en måde, og derfor muligheden for at vælge den mest hensigtsmæssige.

Syntaktisk sukker behøver derfor ikke at være et spørgsmål om bekvemmelighed eller dovenskab (i en sidebemærkning vil jeg så mene, at de to vigtigste menneskelige egenskaber er nysgerrighed og dovenskab, så ikke et ondt ord om dovenskab - vi havde aldrig opdaget hjulet, hvis ikke vi var nysgerrige, og vi havde aldrig fået det udnyttet, hvis ikke vi var dovne!) - syntaktisk sukker er i mindst lige så høj grad et spørgsmål om, at kunne udtrykke det, som man mener. Når man skriver programmer, så formidler man forståelse af en fremgangsmåde - dels til computeren, men også til mennesker, både ens fremtidige jeg, men også alle andre, som bliver konfronteret med ens kreation. Jo mere præcist at man er i stand til at udtrykke sig, jo bedre bliver meningen formidlet.

Eller for at sætte det på spidsen: Computeren skal nok forstå, hvad du siger - men kan du selv og andre forstå, hvad du mener?

Niels fra gå-hjem-mødet i indledning vil sikkert være enig med mig i ovenstående, for hans foredrag var i høj grad et eksempel på, hvordan man med de nye ting i C# 3.0 og LINQ kunne skære ned på formalia, og dermed øge læseligheden.

Et oplagt eksempel, hvad mange vil kalde syntaktisk sukker, er Type inference (hvordan oversætter man i øvrigt"type inference" til dansk?). Ortodokse tilhængere af statisk type check vil sikkert bruge begrebet nedsættende, i det de argumenterer for, at den reducerede formalisme forringer sprogets evne til i kraft af sin opbygning at medvirke til at undgå fejl. Det er da også muligt at komme på eksempler, hvor det er tilfældet. Men den anden fløj i debatten vil mene, at det som oftest i stedet tvinger os til at gentage det indlysende grænsende til det absurde. Ved at fylde teksten op med unødvendige trivialiteter, så fjerner man opmærksomheden fra det væsentlige - eller men andre ord, ved at gøre det nemt at finde fejl i formalia, så gør man det sværere at se fejl i logikken. Jeg hælder nok mest til det sidste synspunkt - og er det sandt, så er det da at smide barnet ud med badevandet!

Hvis du er med så langt, så vil du sikkert have fornemmet, at mit holdning til spørgsmålet i overskriften er, at syntaktisk sukker ikke nødvendigvis er tomme kalorier - og måske endda som oftest det modsatte. Det er så her, at jeg bliver nødt til at padle baglæns, for mit argument står og falder med at syntaktisk sukker kan gøre det nemmere at formidle overblik og hensigt. Men engang imellem, så er der udelukkende tale om bekvemmelighed og dovenskab - og desværre på måde, som gør det sværere at få overblik eller forstå hensigten. Oftest er der tale om et tveægget sværd - det, som kan give fornuft, kan også misbruges. Ikke alt sukker er godt sukker - og nogen steder er selv lidt sukker for meget sukker!

Et eksempel på det tveæggede sværd kunne være operator overloading. Det er oplagt, at man her har muligheden for på en kompakt måde hurtigt at formidle overblik og indsigt. Men det kommer med en betydelig risiko for at blive misforstået (eller, hvis det kommer i de forkerte hænder, at blive direkte vildledt!).

Et andet eksempel stod gå-hjem-mødet for, nemlig C# 3.0 extension methods. Her var der tale om adskillige løftede øjenbryn, og en af deltagerne slog hovedet på sømmet med en bemærkning om, at det ville gøre det meget vanskeligt at finde ud af, hvor funktionaliteten stammede fra uden understøttelse fra ens IDE (og her vil jeg så tilføje, at det altid er en Beck'sk "stank", når ting bliver så komplicerede, at man bliver afhængig af værktøjer til at hjælpe en med at håndtere kompleksiteten - her skal man altid spørge sig selv, om kompleksiteten er iboende eller tilfældig!). Jeg tror, at alle kunne se meget af det gode, som extension methods ville gøre muligt, men jeg er også overbevist om, at vi var adskillige, som havde et dårligt deja vu - sikkert forårsaget af konkrete oplevelser med f.eks. operator overloading.

Til slut vil jeg lige svare på mit spørgsmål til mig selv i indledningen: Jeg tror, at syntaktisk sukker som begreb har et dårligt rygte på grund af alt for mange eksempler på dårlig implementering. Men et princip kan sagtens være godt, selvom der findes eksempler på dårlig anvendelse - og derfor vil jeg også mene, at det dårlige rygte er uretfærdigt. Eksemplerne på dårlig anvendelse skal dog mane til forsigtighed, og vi skal vælge vores leverandør af sukker med omhu, og tilsvarende selv være bevidst om faren ved overdreven eller forkert brug af sukker.

(en lille og helt urelateret regi-bemærkning: Jeg startede med at skrive dette på en smuk sommerdag, og jeg lå derfor ude i skyggen under det store æbletræ i vores have - jeg kunne derfor have skrevet en lovsang om den frihed, som de såkaldt trådløse teknologier giver os ... men jeg nåede kun halvvejs, førend det væltede op med advarsler i stærkt stigende streghed om, at nu var der altså snart ikke mere strøm på batteriet! Jeg endte derfor med at sidde indenfor i lummerheden bundet til en stikkontakt - jeg glæder mig til den dag, hvor energiforsyningen også reelt bliver trådløs!)

Reddet på målstregen

Medens vi stadig havde en vinter, som så ud til at være blevet væk, da skrev jeg et indlæg om, hvordan haven allerede så småt havde fået forårsfornemmelser under titlen Pæreskud. Dengang udtrykte jeg min bekymring for, om det nu gik godt, eller om vi ville få en ordentlig omgang nattefrost.

I bagklogskabens alt for klare lys så ved vi nu alle, at det til overmål var en bekymring, som gik i opfyldelse. Ovennævnte pæretræ blev godt og grundigt svitset, og min nye sommerfuglebusk så helt død ud. Jeg overvejede at blogge lidt om det, men fik ikke taget mig sammen - sikkert fordi at jeg godt kunne regne ud, at det bare ville blive en værre omgang klynk - og hvem gider høre på klager over ærligt og redeligt uheld?

Men nu har lyset og foråret alligevel sejret. Se bare her - mit pæretræ står og blomstrer, som det var en ren lyst - og det var jeg den sidste, som ville have troet...

Fra albummet Forår

Hvis man kigger godt efter, så kan man godt se, at nogle af kronbladene er lidt visne i kanten. Men det er virkeligt godt kommet igen - og det samme gælder min sommerfuglebusk.

Apropos vintervejr, så står det store kirsebærtræ lige nu og drysser hvide blade ud over alt og alle som kommer for nær - hvis ikke det var fordi, at temperaturen er ved at blive næsten sommerlig, så kunne det godt ligne sne.

Og da jeg var ude med kameraet, så tog jeg også lige et par billeder af blommetræet og æbletræet. Æbletræet var dengang, hvor jeg tog billederne, og det er trods alt kun et par dage siden, endnu ikke sprunget ud endnu - men det er det nu.

Hvis I vil se billeder i en bedre størrelse, så må I lige klikke på dem ... OK?

Læsning

Jeg læste engang et interview med en person, som mente, at skrev man af efter en bog, så var det plagiat - men skrev man af efter tre bøger, så var det forskning. Jeg er ikke i gang med at skrive, men derimod med at læse, og jeg læser for tiden i tre bøger på en gang - og det er vist af alt besværligt!

Grunden til, at jeg er havnet i denne noget håbløse situation, ikke mindste det aktuelle vejr taget i betragtning, er, at jeg har fundet en virkelig spændende bog på nettet. Dels så er det faglitteratur og dels, så er det meget lidt transportabelt, så jeg har også gang i noget skønlitteratur og en "død skov" version af noget andet faglitteratur.

Den bog på nettet, som jeg er ved at tygge mig igennem, er Scala by Example, og den indeholder en eksempelorienteret introduktion til programmeringssproget Scala. "Hvorfor lige Scala?", er der sikkert en del af jer, som nu sidder og spørger jer selv. Ikke for noget specielt, er mit svar - jeg havde bare brug for at prøve noget nyt. Jeg synes lidt, at Java/C# og venner er ved at have nået så langt, som de kan komme, og at udviklingen på den front er blevet lidt ukoordineret "sådan en må vi også have" - og så lød Scala, som et spændende bud. Men jeg regner nu ikke med at komme til at skrive særligt megen kode i Scala, om nogen overhovedet.

Det er måske heller ikke så vanvittigt interessant, at netop jeg lige i denne tid kigger i retning af netop dette sprog. Det mest interessante for mig er såmænd heller ikke selve sproget - jeg er nemlig pludselig blevet meget klogere på ting som f.eks.:

• funktionel programmering
• currying
• generiske typer
  
• covarians og contravarians
• lister

...bare for lige at nævne det, som jeg kunne komme i tanke om på stående fod (ok, currying skal jeg nok lige vende en gang eller tre mere inden jeg helt har styr på det - enten er det ufatteligt simpelt, eller også har jeg overset noget - og min fornemmelse siger mig, at det godt kunne være det sidste).

Jeg kan også godt lide den eksempelorienterede tilgang. Det er jo ret mange interessante ideer, som sproget prøver at give et fornuftigt bud på en implementation af, og selv hvis man ikke lige har lyst til at hænge sig i den præcise syntaks, så vil man få ganske meget ud af eksemplerne - de prøver nemlig også at forklare den bagvedliggende ide. Og det bedste af det hele for mig er, at sproget ikke ligger længere fra mit nuværende hovedsprog (Java) end at jeg faktisk allerede har kunnet bruge elementer og ideer fra bogen.

For jer hardcore dataloger derude, så er der sikkert ikke så meget at hente, men hvis du er en halvstuderet røver som jeg, og har mod på at få udvidet horisonten, så kommer ovenstående "bog" med mine anbefalinger.

Teampræstation

Hele familien var i Legoland i denne måned. Godt nok er det meste noget med at sætte sig ned og blive transporteret på et utal af forskellige måder (3 slags tog, biler, både, kanoer og rutsjebaner...), og vi elsker det. Eller måske rettere: børnene elsker det, og vi elsker at børnene elsker det. Vi bruger nemt en dag dernede. Meget traditionelt, og såmænd også yderst trivielt.

Men der er nogle enkelte forlystelser, som skiller sig ud, og en af dem er "Falck Fire Brigade". For dem af jer, som ikke har haft fornøjelsen af at prøve den endnu, så er her en kort beskrivelse: Man deles op i hold af ca. 4 personer (det passer godt med en kernefamilie, eller diverse fædre og sønner fra en skovtur), som hver får en af otte forskellige "brandbiler". Når klokken ringer og der er udrykning, så skynder man sig ud i bilen, og "pumper" den afsted - jo bedre man "pumper" jo hurtigere bevæger den sig. Når man er fremme, så er der to pumper og to sprøjter, og så gælder det ellers om at få mest muligt vand til at ramme "branden" i et vindue. Når vinduet har fået vand nok, så gælder det om at komme ind i brandbilen og "pumpe" den hjem igen, og det hold som kommer først har vundet (man vinder "kun" æren, og det er nok bedst sådan...).

Det første, som jeg synes er værd at hæfte sig ved, er, at der er faktisk er tale om en konkurrence - der er jo vindere og tabere. Der er da helt klart nogen, som tager det mere alvorligt end andre, og det er såmænd også i legens ånd, men faktum er, at uanset om man prøver at overbevise sig selv om, at man "kun er med for sjov" og at man "kun konkurrerer med sig selv", så kigger man alligevel til, hvordan de andre klarer sig. Og herved adskiller den sig markant fra så meget andet, som man kan lave i Legoland.

Det andet, og nok det også det, som gør det interessant i denne sammenhæng, er at det er en holdpræstation, som er afgørende. Det er i yderste konsekvens "sidste mand over stregen", som gør sig gældende.

Men hvad er det så, at der gør, at et hold vinder? Ja, det hjælper helt klart at have nogle stjerner. Fire toptrænede konstabler fra den danske hær vil nok til enhver tid kunne slå en familieudflugt, så en naiv holdning kunne være, at det er et spørgsmål om maksimal individuelle præstationer. Men legen er så snedigt konstrueret, at det ikke kun er det - et hold skal kunne samarbejde for at kunne opnå sit fulde potentiale.

Min store søn (stor her ment relativt) er meget konkurrenceminded og han hælder helt klart til det med de individuelle præstationer. Det startede med, at han ræsede foran alle os andre ind i brandbilen, og som en gal begyndte at pumpe løs - resultatet var, at vi andre måtte rende efter den og springe på i farten - og at jeg måtte bruge ekstra tid på at redde det "lille" (igen relativt) med ombord, inden at jeg kunne give en hånd med og dermed få sat ekstra fart i bilen.

Det næste punkt var så, da vi fordelte os på pumper og sprøjter. Jeg pumpede for den lille, og min kone for den store. Selvom det ikke fornægter sig, at min kone er tidligere konkurrencesvømmer, så kunne jeg nu stadig få pumpet mere vand end hun kunne. Problemet var bare, at den lilles "boldøje" ikke var det bedste, så halvt inde i forløbet bytter vi rundt, og derefter gik det bedre.

Hvad kan vi så lære af det? Jo, i hvertfald tre ting:

1. Når man er et team, så er det ikke altid en fordel at have en stjerne, som kan løbe hurtigt - måske løber han fra de andre.
   
2. Selv når alle gør deres bedste, så skal man stadig overveje, om man ikke kunne blande kortene på en anden måde, med et bedre resultat.
   
3. Det er ikke altid at man skal gøre det, som man er bedst til - vi voksne kunne nok ramme en del bedre end børnene (trods alt, for de er faktisk ret gode til at spøjte med vand), men vi har en komparativ fordel på pumperne, så er det det, som vi skal gøre (den opmærksomme læser vil her sikkert sidde og overveje, om ikke en bedre kombination ville have været to voksne på den ene sprøjte og to børn på den anden - måske, men der var tale om optimering af flere kriteriefunktioner på en gang...).

Så når det er det fælles resultat, som tæller, så er helheden ikke lig summen af delene - det er ikke nok at optimere den individuelle præstation.

Jeg mener at kunne huske en tv-udsendelse om udvælgelse af kosmonauter. Det er selvfølgelig et stærkt konkurrencepræget foretagende, og man skal virkelig være dygtig både fagligt og fysisk for at komme til tops (pun intended!). Men en af prøverne havde et uventet sigte: Tre aspiranter fik til opgave at få et system i balance. De måtte ikke tale sammen og de havde hver en måler og en drejeknap. Men de tre var koblet sammen, så når en aspirant forsøgte at bringe sin måler i balance, så ville han tilsvarende bringe de to andre voldsomt ud af balance. Prøver alle tre at gøre det samtidigt, så vil det i praksis være umuligt at få det til at lykkedes. Derfor var vinderen den, som først erkendte dette og tog hånden af sin knap, og lod til to andre om at skaffe balance i deres del, hvorefter han så kunne give sin knap et lille nøk ad gangen i den rigtige retning, imens han gav de andre tid til at reetablere deres balance undervejs.

At have et team bestående af folk, som hver i sær er dygtige er derfor ikke nok, og en væsentlig evne er derfor tit evnen til at kunne træde i baggrunden og se det store billede. Tit er det optimale ikke at yde sit optimale, men derimod på klog vis at give plads til andre.

Og nu kære læser, under antagelse af, at vi er enige om ovenstående, kan du så svare mig på, hvorfor så mange firmaer stadig indretter deres motivations- og belønningssystemer efter den individuelle præstation?

PS: Vores brandbil kom forresten først...

Udvidbarhed

Jeg har lige siddet og læst Jeff Atwoods blog The dark side of extensions, hvor han argumenterer for, at ulempen ved at basere sig på udvidelser (extensions) er, at mange ikke benytter sig at tilbuddet om personalisere produktet - de bruger den basale version.

Hans eksempel er Firefox i forhold til Safari, og hans budskab er, at Firefox er en platform, hvor Safari er et færdigt produkt. Nu kan man altid diskutere, hvem som "slår" hvem, men jeg er enig i Jeffs præmis om, at Firefox først virkelig skinner igennem, når man har fået personaliseret den med en god håndfuld udvidelser. Og sådan skal det i følge firefox-bagmændene være, også selvom det betyder at Safari er milevidt foran Firebox, hvis man tager begge "out-of-the-box".

Så langt er jeg enig med Jeff - og havde jeg været helt enig med ham, så var der ikke kommet en blog ud af det. Men jeg er kun enig med ham i præmisserne. Hans konklusion er, at man med jævne mellemrum skulle folde de mest populære plugins ind i platformen. Hans holdning er mao. at man skal lave programmerne udvidbare og tilpasningsvenlige i håbet om at få et "community" op og stå, og så jævnligt og systematisk høste de ideer, som har den største overlevelsesevne (hvordan oversætter man i øvrigt "community"? - "software-økosystem" er mit bedste gæt, og det lyder alt for højstemt) .

Ja... - og så alligevel nej. Selvfølgelig skal man høste det bedste af det bedste, og selvfølgelig skal man hele tiden holde et vågent øje med, hvordan verden udvikler sig. Men ideen om rutinemæssigt at udvide platformen med det mest populære er, efter min mening, helt forkert. Det er tanken om at "one-size-fits-all", og det er i direkte modstrid med tanken om en fleksible platform. Hvis det får lov at løbe over nogen gange, så vil det slide systemet ned, og det vil miste sin dynamik. Man vil godt nok stå med et fint produkt, men det vil være et produkt, som kun er fint lige nu (og kun for "flertallet" - som jo som oftest ikke er så stort, som det lyder til - og et "flertal" som vil svinde ind over tid). Jeg vil personligt ikke bryde mig om det - for mig er retten til at kunne vælge fra mindst lige så vigtigt, som muligheden for at kunne vælge til.

Det man i stedet - efter min mening - bør gøre, er at kigge i retning af færdigpakkede løsninger. Der kan være en basismodel for den omkostningsbevidste, en mellemmodel til os almindelige, og en luksusmodel til dem, som vil have det bedste af det bedste - eller modeller, som retter sig imod forskellige brugsmønstre. Men stadig med frie muligheder for at vælge en anden radio (hvis det er biler) eller en bedre adblocker (hvis der er en browser).

Hvis man vil se, hvordan det kan gøres, så kan man kigge på Eclipse (Eclipse er - i sin traditionelle form - et java-udviklingsmiljø). Eclipse er både en platform og et community, og der er også til Eclipse et hav af udvidelser. Og alligevel har man, trods det faktum, at man henvender sig til mere professionelt orienterede brugere, lavet pakkeløsninger. Det startede Callisto, som var et forsøg på en samlet release af platformen og toneangivende plugins, og det havde i sig selv stor værdi (Callisto er senere blevet fulgt op af Europa, og snart den kommende Ganymede). Men det helt store værdi ligger efter min mening i, at det muliggjorde at man kunne lave gennemprøvede og sammenhængende standardkonfigurationer af Eclipse.

Eller man kan kigge i retning af Linux. Her har man også en platform og et community - og en række forskellige tilpasningsvenlige pakkeløsninger (man kalder det så godt nok for "distributioner"). Personligt startede jeg i sin tid med Slackware, har siden arbejdet meget med Redhat og Mandrake, og har senest kastet min kærlighed på Ubuntu. Alle har kørt fint "out-of-the-box", men det har alligevel haft stor værdi, at jeg over tid kunne file dem til og justere på dem.

Og det samme bør man efter min mening overveje med Firefox. Det vil give det bedste af begge verdener - en "færdig" løsning, som man alligevel kan tilpasse og forbedre.

Det perfekte billede

Hvorfor har man ikke ens kamera med, når det perfekte motiv viser sig? Når månen står så lavt over horisonten i skumringen, at dens lette rødmen danner en perfekt kontrast til den sarte blånen af aftendisen. Eller når solopgangen maler et flammehav på morgenhimlen?

Sådan en oplevelse havde jeg den anden morgen. Og helt uventet, for selvom det havde været en smuk morgen, så gik jeg fortabt i mine egne tanker. Der var faldet sne om natten, og jeg nød bare roen og sneens stille knirken under mine fødder - og så pludselig kommer der en pige i den rødeste regnfrakke lige ud foran mig på den flotteste lyseblå cykel. Farverne passede perfekt til den omgivende sne - og mens hun cyklede væk, kunne jeg se adskillige gode motiver der aldrig nåede at blive til andet end flygtige minder...

Sikkerheds-bjørne-tjeneste

Jeg har - de facto - opgivet den digitale signatur.

"Hvad...", vil nogen måske sige, "...nu er den jo lige ved at blive sikker?" - ja, netop, vil jeg så svare. "Og hvad så...?" vil andre sikkert bemærke - og ja, det har jo aldrig rigtigt været en folkesag, den der digitale signatur, så det er vel ikke noget særligt at vende den ryggen. Men det som dog (forhåbentlig) gør det en lille smule interessant er, at jeg faktisk har været rigtig glad for den.

Men først tror jeg lige, at jeg vil tale lidt om sikkerhedsseler. Kan I huske dengang at sikkerhedsselerne begyndte at komme frem? Kan I huske de der faste seler, som altid var for lange - eller for korte - og som altid snoede og krøllede, så det var et større puslespil at få dem på? Når man så havde fået dem på, så var de enten for løse eller også sad man snøret ind, så man blev helt gasblå i ansigtet. Og skulle de endelig sidde tåleligt, så opdagede man, at man ikke kunne læne sig frem og nå det, som man havde lagt i handskerummet, uden først at skulle tage dem af igen.

Dengang var der mange gode kræfter, som prøvede at få os til at bruge selen, og der var rigtigt mange gode undskyldninger for ikke at gøre det. Hvorfor? Tjo, min påstand er, at det simpelthen var for besværligt. Glem alt om den store risiko og alle de andre gode argumenter - det var en sten i skoen i hverdagen. Nu, hvor rulleseler stort set er standardudstyr, så tænker man ikke længere over det - man spænder bare selen. Ja, og tiden var en anden dengang - dengang kunne man også gå og prale af at have kørt en ordentlig brandert hjem - og det skulle man bare lige prøve på i dag.

Hvad har det så med den digitale signatur at gøre? Jo, hvis sikkerhed skal fungere, så skal det være nemt at bruge - ja, helst så nemt, at man ikke tænker over det, når man bruger det. Bliver det for besværlig - eller såmænd bare for tydeligt - ja, så er der en stor chance for, at man begynder at omgå eller undgå det i stedet.

Den digitale signatur var (i det mindste for mig) løftet om en digital identitet - om muligheden for et signon - om et sted, som kunne sige god for, at jeg var mig. Den ting, som betød, at jeg ikke længere behøvede at oprette brugernavne med tilhørende passwords alle mulige steder. Og, ikke mindst, en sikkerhed, som jeg kunne administrere hos mig, fremfor at skulle stole på at alle mulige rundt omkring forvaltede fornuftigt.

Men, som med alle gode sager, så havde den mange ejere, og deres dagsordner var desværre ikke altid den samme som min:

Bankerne mente ikke at den var sikker nok - og selvom den holdning oprindeligt nok mest at alt var politisk, så er det nok sandt, at vi skal over i noget med en to-faktor autentifikation, for at de kan opnå tilstrækkelig sikkerhed imod misbrug - ikke mindst hvis den ene faktor er fysisk, og derfor ikke så nem at kopiere.

Det offentlige blev udfordret på, at deres professionelle brugere er langt mere mobile end gennemsnittet - og på at computere hos dem sjældent er personlige, men snarere noget i retning af "public terminals". Tid blev derfor en faktor - det var ikke nok, at man havde logget ind, næh, man skal med jævne mellemrum bekræfte, at man stadig er den samme, for jo længere tid der går, jo større er sandsynligheden for, at nogle andre har snuppet skærmen og tastaturet (for en mere teknisk diskussion af udfordringerne, se f.eks. SOSI-projektet).

Begge aspekter har trukket den digitale signatur i en retning, hvor den er blevet mere og mere besværlig at kopiere (desværre også for den retmæssige bruger) - og mere og mere besværlig at bruge.

Jeg bruger normalt Ubuntu, når jeg skal en tur på nettet - opstartstiden slår Windows med en størrelsesorden, og trods det, at den er mere tidssvarende, så kører den væsenligt bedre på utidssvarende hardware som min. Og skulle jeg endelig lige have en Windows kørende, så bruger jeg altid Firefox - den passer simpelt bedre til mine vaner, og hvor den før simpelthen var bedre, så er den udslagsgivende faktor i dag, at jeg har kunnet tilpasse den præcist til mine ønsker. Desværre har jeg efter sidste fornyelse af min digitale signatur, ikke længere kunnet få den til at fungere i andet end Internet Explorer. Og det er simpelthen for besværligt at skulle skifte browser - eller måske endda reboote - bare for at skulle bruge digital signatur.

Det andet problem er, at jeg nu bliver tvunget til at afgive mit password langt oftere end tidligere. At man lige skal aktivere signaturen, er en fin ting - og det ville have været rart, hvis den ikke, som før, var en del af den rodebunke af sager med stærkt varierende grad af følsomhed, som udgør en browsers keystore . Men nu er den simpelthen blevet for hysterisk. Og - som for at føje spot til skade - så tror de websites, som bruger den, heller ikke rigtigt på den, så har man først sagt "logout", så kommer man ikke ind igen, førend hele browseren er blevet genstartet, hvorved hele cirkusset starter en gang til.

Så det kan godt være, at den digitale signatur er blevet mere sikker, og derfor nu kan nå grupper, som før måtte vende den ryggen, men samtidigt er den blevet for besværligt for en casual user som mig. Og jeg vurderer, at det nu, trods alt, er blevet nemmere at rekvirere tastselv-koder og oprette brugerlogins de steder, hvor jeg nu kommer på nettet. Hvad ejerne af projekt "digital signatur" ser som et fremskridt, ser jeg som et tilbageskridt.

...og nu var jeg ellers lige blevet så glad for den!

PS: Jeg ved, at der en af mine læsere som nu sidder og griner, for han har vist mig, hvordan jeg alligevel kan få den flyttet - det husker jeg skam udemærket, pointen var såmænd også kun, at det nu er blevet alt for besværligt set i forhold til alternativet.

Pæreskud

PæreskudAt have en blog er vel et stykke selvpromovering, og lad mig derfor benytte denne lejlighed til at henvise til mit web-album. Det var jo et vidunderligt vejr i dag, og jeg fik lejligheden til at gå lidt rundt i haven, og tage et par billeder.

Alt er godt nok langt fremme, og jeg kan se, at vores have ikke engang er noget specielt - der er mange steder, hvor man er længere fremme. Jeg synes at det er flot, og det håber jeg også at I andre gør.

Selvom forårsblomsterne lige nu er i overflod - pånær lige erantis, som frosten tog den anden nat - og selvom at vi sådan selv stadig går og venter på liljer og tulipaner, så er der kommet meget gang i det. Der som nok glæder mig mest, at man allerede nu kan se knopper på frugttræer og kan se f.eks. rabarberen skyde. Ja, selv den ene af mine sommerfuglebuske er begyndt at sætte nye blade.


RabarberMan kan godt blive helt nervøs. Det klarer nok en let omgang nattefrost - men selvom foråret godt nok er begyndt i følge kalenderen, så kan vi stadig nå at få en ordentlig omgang kulde. Og sker det, så lad os i det mindste håbe, at der kommer godt med sne med - ellers kan det godt blive lidt af en massakre.

Et lille hint - man kan lægge kommentarer både her, og til de enkelte billeder i albummet. Og det behøver ikke altsammen være ros - hvis man kritiserer, så er der stor chance for, at man får ret (og motiverer mig til at prøve lidt mere næste gang).

Tilbage til fremtiden

Nu kommer tidspunktet snart, hvor jeg tager tilbage til fremtiden igen. Selvom nutiden er meget interessant, så må jeg sige, at jeg gået og ventet på muligheden for at komme retur til fremtiden. Og nu ser det ud til, at det snart lykkes.

Turen bliver ikke så vanvittig lang - kun en ca. 1500-1600 år. Og så kan den tages på et øjeblik, hvis forudsætningerne ellers er opfyldt. Og det er de næsten - det kræver bare en mindre investering fra min side.

Hvad sker der så i det 36. århundrede? Jo, menneskeracen har spredt sig helt pænt ud i galaksen, og den forøgede udviklingshastighed, som vi allerede nu kan måle, har betydet, at vi har udviklet os meget - og meget forskelligt. Fysisk død er ikke nogen særlig ting længere, for sindet kan overføres til en ny krop og livet derfor forsætte det med et mindre afbræk (og med de fordele og ulemper en ny start medfører).

Den lille investering, som jeg påtænker, er at købe Peter F. Hamiltons nye bog "The dreaming void". Anmeldelser kan f.eks. læses her på dansk hhv. udenlansk. Hvis du ikke skulle have stiftet bekendtskab med Hamilton og hans bøger før, så er det lige på sin plads med et par advarsler:

1. Det er den første bog i en trilogi.
2. Der er i nogen grad tale om en fortsættelse af bøgerne om Starflyer-krigen (Pandoras Star/Judas Unchained). Nye læsere skulle kunne starte her, men Pandoras Star er en af hans bedste bøger (til gengæld er Judas Unchained noget middelmådig).
   
3. Han skriver meget lange bøger med mange tråde (genren kaldes ikke uden grund for space opera).
4. Bøgerne kan være meget svære at lægge fra sig, hvis man først er blevet fanget.

Nu skriver jeg, at Pandoras Star er en af hans bedste. Flere mener, at det er den bedste, men jeg synes faktisk, at der er en, som er bedre - og det er Fallen Dragon. Den kan i modsætning til de fleste andre af hans bøger læses selvstændigt - og så har den en slutning, som er så elegant, at man lige bliver nødt til at læse den igen, for at se om det nu også holder vand hele vejen igennem (og det gør det, kan jeg så afsløre!).

Min rejse tilbage til fremtiden afhænger nu kun af, om jeg kan vente til at paperback udgaven kommer til Danmark, eller om jeg giver efter og betaler overpris for en i hardcover. Uanset, så vil jeg nok være tabt for omverdenen et stykke tid efter.

God SOA

Det har været en mærkelig uge. Jeg har læst to artikler om SOA, som fik mig til at tænke.

Den første artikel, var Computerworld's (ja, ja, og jeg læser også Jumbobøger - og hva' så?) artikel om, hvordan PFA selv mente at SOA havde gjort det muligt for dem at skifte leverandør med meget mindre smerte end ellers (jeg kender ikke CW's holdning til dybe link, så find den selv - den er fra 26. febr. og hedder "PFA-direktør: SOA sikrer nem fyring af mægtige CSC").

Artiklen beskriver, hvordan det at man har kunnet opbygge et grundlæggende antal services for forretningen, og så lade applikationerne tilpasse sig forretningen, fremfor som det klassisk set sker, nemlig at forretningen tilpasser sig applikationerne.

Og som så ofte, så er det mest interessante det, som ikke står der. Der står ikke et ord om teknik. Ingen "Enterprise Service Bus", ingen "WSDL", ingen "UDDI", ingen "MOM". Intet af alt det, som man ellers altid hører soft- og hardwaresælgere fra det store firmaer sige, er den magiske ingrediens i sovsen, som uden hvilken succes ikke vil være muligt.

Den anden var en knapt så konkret blog fra Kaare Kjelstrøm om spader og skovle, hvor han beskriver behovet for en fælles forståelse af domænet som forudsætning for kunne implementere fælles services. "Nåe ja", fristes man til at sige, "det vidste vi da egentlig godt (det havde vi bare lige glemt...)". Eller som Peter Nørregaard siger i en af kommentarerne til Kaares blog: "Hvis ikke det fungerer på papir, så kommer til heller til at fungere elektronisk."

Det fik mig også til at tænke over en af de overvejelser, som jeg i sin tid gjorde mig i min hovedopgave. Den handlede om objekt-orienterede databaser, som lige var ved at blive stort dengang, og der filosoferede jeg over sammenhængen imellem programmer og data:

Mit postulat var dengang, at vi var i den anden af 3 faser (og - mente jeg - lige ved at komme over i den tredje):

Første fase var dengang, hvor programmer og data havde været rodet ubehjælpeligt sammen, så hver program havde sine egne data, og kun programmet selv kunne forstå dem.

Anden fase var, at databaser havde gjort det muligt for data at blive frigjort fra programmerne og blive delt på en abstrakt og generelt tilgængelig form.

Til gengæld, så savnede jeg dengang, at det som jeg kaldte "viden om data" blev frigjort fra programmerne - at vi kom ind i det, som jeg så som den tredje fase. Dvs. at de datanære forretningsregler - som f.eks. at debet og kredit skal stemme i en postering - kom til at følge data. For nok var data delt, men forståelse og håndhævelse af forretningsreglerne lå stadig spredt ud over de forskellige programmer, med alle ulemperne ved redundans. Men data og forretningsregler kunne jo kombineres i forretningsobjekter. Tanken var så, at applikationerne ikke skulle operere direkte på data, men i stedet på forretningsobjekter.

Nu vil jeg ikke påstå, at jeg forudså SOA dengang, for det var jeg slet ikke fremsynet nok til - faktisk så mente jeg dengang i høj grad, at det var de objekt-orienterede databaser, som var det der skulle redde os. Historien har alt for tydeligt vist, at det var forkert - det er alt for detajlenært og slet ikke omfattende nok. Man genbruger ikke objekter - næ, vi skal helt op på service eller komponent niveau, før genbrug virkelig kan give mening.

Så måske er SOA løsningen? Det har i hvert fald større potentiale end objekt-orienterede databaser...

Hybrid versionsstyring

Jeg har før blogget lidt om distribueret versionsstyring (DVCS), og her kommer lidt mere.

En af de store fordele ved at have en decentraliseret opfattelse af versionshistorikken er, at man ikke har alle sine æg i en kurv. Et centralt repository kan være mere eller mindre utilgængeligt, og har man prøvet det, så ved man hvor fortabt man føler sig. Det kan være så alvorligt, at man skal til at have fat i backuppen, selvom det heldigvis er yderst sjældent. Men det kan såmænd også være noget så simpelt, som at man er udenfor rækkevidde (ja, det kommer nok som et chok, men det er faktisk stadigt muligt at finde steder, hvor der ikke er nogen form for netadgang!).

Skulle man så være helt uden mulighed for at kigge i historikken - eller for at kunne checkpointe udviklingen undervejs med velplacerede commits? Nej vel. Og her kommer distribueret versionsstyring virkelig til sin ret. Og der er jo ikke noget som forhindrer en decentraliseret struktur i netop at have struktur, og derfor i at have et repository, som er mere lige end alle de andre.

Men hvad nu, hvis der allerede er truffet en klog og velovervejet beslutning om at bruge f.eks. Subversion? Er man så tvunget til hele tiden at være online for at få det fulde udbytte?

Ja, i princippet, og så alligevel ikke. For der er jo som udgangspunkt ikke noget som forhindrer en i at versionsstyre de samme filer i to forskellige versionsstyringssystemer, som f.eks. Subversion og Git. Så ville man kunne have en offline historik, offline commits og alligevel kunne koeksistere fredeligt med de andre brugere af det centrale repository.

Dvs. ikke ud over, at det bliver et koordineringsmæssigt mareridt. F.eks. skal ændringer fra det ene skal committes manuelt i det andet.

Men heldigvis er der andre, som har fået samme tanke. Det er f.eks. lavet en integration imellem Git og Subversion med titlen git-svn. Er man mere til Mercurial, så bør man nok holde øje med hgsvn, selvom der vist stadig er plads til forbedring der.

Hvis man kaster sig ud i hybrid versionsstyring af denne slags, så husk at det ikke skal være for at kunne styre at lave sjældne monster-commits - der skal stadig committes de samme sammenhængende klumper af funktionalitet så ofte som praktisk muligt. Når det er interessant, så er det for at dels at kunne arbejde offline, og dels for at kunne lave lokale commits - commits, som ikke behøver være så afrundede eller komplette som ellers - ja, faktisk behøver de slet ikke kunne compilere, og som derfor kan ske undervejs - og ikke først når man er helt sikker på at være færdig.

Giv mig en anden virkelighed

To history, choices are merely directions. The Trouser of Time opened up and Vimes began to hurtle down one leg of them. And, somewhere else, the Vimes who made a different choice began to drop into a different future.

Terry Pratchett: Jingo

Jeg har før skrevet om versionsstyring, og dengang forholdt jeg mig mest til det paradoks, der er i, at en merge-strategi som oftest er en låsestrategi overlegen - også selvom det umiddelbart føles forkert. Denne gang vil jeg dykke lidt mere ned i branching, som mange har et had-kærlighedsforhold til (de fleste endda uden ret megen kærlighed...). Og det er egentlig både synd og uforståeligt.

Lad os starte med at slå fast, at vi gør det hele tiden:

Branching er det, hvor man fastfryser virkeligheden, og arbejder sig ud i en alternativ retning.

Når vi tager en fil ind i en editor, så gør vi det samme - vi skaber en lille alternativ virkelighed, som kun eksisterer i vores editor. Gode editorer lader os måske endda sammenligne med det, som var vores udgangspunkt, nemlig det som stadig ligger på det eksterne lager. Avancerede brugere vil endda kunne editere flere filer på en gang. Denne lille "branch" består indtil vi vælger at gemme vores ændringer - indtil det punkt har vi faktisk en reelt mulighed for at fortryde.

En anden almindelige måde at lave en lille "branch" på, er at tage en kopi fra et fælles netværkdrev, og så arbejde på kopien et stykke tid. Herefter kan man vælge at lægge kopien tilbage igen (eller lade være).

I de fleste versionsstyringsværktøjer har hver bruger sin egen arbejdskopi, og vælger selv hvor tit denne arbejdskopi skal bringes i sync med repository. Samtidig kan brugeren have sine egne ændringer, og dermed sin egen virkelighed, indtil det tidspunkt, hvor brugeren beslutter sig for at flette ændringen ind i den egentlige version i repository. Her er også en lille tidslomme.

Vi har hele tiden brug for at lukke døren til virkeligheden - at melde os ud for en kort bemærkning - imens vi laver vores arbejde uden at blive forstyrret af den flux, der er omkring os. Og også brug for at kunne eksperimentere uden at forstyrre vores omverden. Varer det længe nok, så bliver vi nødt til at en gang imellem at åbne døren og bringe os selv up-to-date med, hvad der er sket omkring os. Når det har stået på længe nok, så vil vi på et tidspunkt åbne døren igen og åbenbare vores resultatet af vores omverden.

Sådan er det også med branches. Bare i en større målestok, og noget mere formaliseret. Men rationalet, udfordringerne og effekten er den samme.

Der er to store beslutninger, som følger med beslutningen om at branche.

Når man brancher, så skal man gøre sig klart dels, om man vil vende tilbage, og i givet fald, hvordan og hvornår.

Selvom man godt kan forestille sig, at man laver en branch, for at gå i en helt anden retning uden noget behov for nogensinde at kigge sig tilbage igen, så er det som oftest ikke tilfældet. Som oftest, så er det man laver, en ændring, som giver god mening - man skal bare lige have fred til at gennemføre den. Og i så fald skal man overveje, hvordan man kommer tilbage.

Den første overvejelse er, hvordan man kan skal håndtere, at andre kan have ladet udviklingen gå i en anden retning imens. Versionsstyringsværktøjer vil hjælpe os med dette i en vis udstrækning, men specielt i de to første eksempler, hvor vi bare havde en lokal kopi som vi kopierede tilbage igen, vil der klart kunne opstå en konflikt, hvis ikke man er omhyggelig.

Risikoen for konflikter stiger med tiden, så en god strategi er oplagt ikke at bruge for lang tid inden afslutter sin branch.

Overvej, hvordan man kan holde sig opdateret undervejs.

Det er klart, at jo længere man har været væk, jo sværere bliver det at komme tilbage. Modtrækket imod dette er at lægge en strategi for, hvordan man løbende holder sig opdateret.

Det koster helt klart tid og kræfter, så det er ikke noget, som skal gøres for tit. På den anden side, så skal man heller ikke vente for længe, for så stiger prisen ved at være ude af sync for meget.

_________

Her burde et være klart, at branching dels ikke er noget magisk, men derimod noget som vi helt naturligt foretager os, og dels at det først for alvor bliver besværligt, når vi lader det løbe for længe. Der er tre altså store udfordringer i det: At starte det, at håndtere det undervejs, og at afslutte det (doh!).

Opstarten vil jeg ikke sige så vanvittigt meget om. Der er flere former for best practice for det - for en grundig oversigt se f.eks. denne Branching and Merging Primer, som oplister ti typer af branches, fem strategier for branching og en pæn mængde antipatterns.

Selv har jeg med rimelig succes talt for en kombinationsløsning imellem clean og dirty trunk. Som udgangspunkt sker udviklingen på trunk, men ikke andet end hvad der stadig med rimelighed kan nå at komme med i næste release. Når denne nærmer sig, så branches der ud i en releasespecifik branch, som så får lov at stabilisere sig. Tilsvarende vil aktiviteter, som rækker længere ud end næste release blive sendt ud på featurebranches. Man vil kunne se, at dette er meget stærk inspireret af afsnitttet Common branching patterns i online bogen Versioncontrol with Subversion.

Afslutning vil jeg her faktisk slet ikke sige noget om, udover det lidt som allerede er sagt. Så resten af dette indlæg går med at snakke om det "ind imellem".

Det burde nu være klart, at det vigtigste ved det "ind imellem" er, på en kontrolleret måde at holde sig opdateret med det, som sker omkring en. I eksemplet med en lokal arbejdskopi af et fælles repository er det rimeligt simpelt, i det at værktøjet går langt for at hjælpe en. Man skal bare finde en passende rytme for at holde sig opdateret, så skal det nok holde styr på, hvilke opdateringer man har brug for, og om de evt. skulle konflikte med det, som man nu har gang i.

For de mere manuelle eksempler er der ikke andet at sige, end at man må håbe på det bedste, og så ellers holde tungen lige i munden.

For "rigtige" branches i versionsstyringsværktøjer, findes der fine beskrivelser af best practice for håndtering af, hvordan bogholderiet ifm. f.eks. succesive opdateringer skal håndteres. Det lyder besværligt og bureaukratisk, og det er det faktisk også. Se f.eks. ovenstående bog om Subversion - der er der fint beskrevet. Og mon ikke at det er dette bogholderi, som er pæn del af grunden til at branches er blevet lagt sådan for had?

Men der er i hvertfald to ting, som for nyligt at kommet til min opmærksomhed, som vil lette denne byrde mærkbart:

Den ene af disse er, at der i næste version af Subversion kommer noget som de kalder "merge tracking" (det er scheduleret til version 1.5, og i skrivende stund er den aktuelle version 1.4.6). Her lover subversionfolkene, at de vil hjælpe os med bogholderiet vha. snedige markeringer i metadata, så alt hvad vi skal gøre er, med jævne mellemrum at skrive "svn merge". Se f.eks. Subversion: Merge Tracking og Merging og branching in Subversion. Udover problemstillingen med succesive merges, så skulle det kunne håndtere "cherry picking" (dvs. merging af udvalgte ændringer alene) og tilbagerulning at merges uden at blive forvirret. Se det er efter min mening grund nok til at skifte til Subversion, hvis man ikke allerede har gjort det! At have branches og at holde dem opdateret, burde da ikke blive mere omstændeligt end at have lokale arbejdskopier og holde dem opdateret i forhold til det fælles repository - og dermed er en stor administrativ byrde fjernet.

Den anden ting er et markant brud med det grundlæggende vilkår ved branches, at man skilles på et bestemt punkt, og at dette punkt som udgangpunkt ligger fast. I værktøjet AccuRev erstatter man begrebet branches med et andet begreb kaldet streams. Tanken er, at man baserer streams på andre stream - det som vi vil opfatte en som branch, vil være en stream baseret på trunk. Men en stream ligger ikke fast - den er så at sige transparent alle de steder, hvor der ikke er lokale ændringer. Det betyder, at sker der ændringer i de stream, som en given stream baserer sig på, så vil man få disse ændringer med næste gang man opdaterer. Når man er klar, så kan man sende sine ændringer op til den overliggende stream, og så fremdeles, hvis der er tale om flere niveauer af streams. Se evt. mere i Streambased architecture for SCM.

Det er efter min mening et yderst interessant alternativ, da det umiddelbart ser ud til, at man her helt kan undvære at skulle merge imellem branches undervejs. Om man kan håndtere den "støj", som det vil være altid at få alting med, kan jeg ikke overskue - og det betyder i hvertfald at der er en lang række af vores etablerede mønstre for brug af versionsstyringsværktøjer, som skal gentænkes.

Jeg håber at jeg her har fået afdramatiseret brug af branches lidt, så flere nu tør give sig ud i at branche, hvor det giver mening. Vedr. citatet i indledningen, så kan jeg fortælle at de to Com. Samuel Vimes formår at få fat i den andens "disorganiser" (en "disorganiser" svarer nogenlunde til vore dages PDAere). Resultatet er ganske mange forviklinger, bl.a. at "vores" Vimes på et tidspunkt får reminders om sit alternative jegs begravelse. Parallelle virkeligheder er forvirrende - hold jer fra det i større målestok!