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