søndag den 21. september 2008

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.

søndag den 14. september 2008

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!

lørdag den 6. september 2008

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

onsdag den 3. september 2008

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:


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.