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!

Pinligt

Her den anden morgen holdt jeg for rødt i et stort vejkryds, hvor jeg skulle til højre. Fra den modsatte retning kommer der en ambulance med fuld udrykning. Da den nærmer sig krydset, så skifter det til grønt.

Jeg bliver selvfølgelig holdende for lige at afvente, hvad han vil - man giver vel plads til udrykningskøretøjer, ikk'? Men der går ikke engang tre sekunder, så begynder ham omme bagved gud-hjælpe-mig at dytte af mig!

Pinligt! Mon ikke han har siddet tilbage med noget temmeligt røde ører, da han endelig opdager ambulancen?

I øvrigt skulle ambulancen selv til højre, så vi kom hurtigt videre - tabet var nok alt i alt på 10 sekunder for vores vedkommende.

Vinterpause?

Jeg har før sagt, at nu er vinteren kommet, men min have er ikke enig med mig. Den er begyndt at tage forskud på foråret, og det pibler op med forårsblomster overalt.

Udover de blomster, som er der billeder af her, så er vi begyndt at se liljer og tulipaner skyde, selvom de selvfølgelig ikke er kommet så langt. Bare det nu går godt.

I sidste weekend var vi selv i haven med beskæresaksen. En vittig nabo ville vide om det var en meget sen efterårsklargøring eller en meget tidlig forårsklargøring? Der var nok mest gået forår i os lige som med haven, men det var nu mest hverken eller. Det er sandt, at vinteren i høj grad er hviletid for haven, og specielt græsplanen skal have ro (det også bare noget værre sump, når man har lerjord som her).

Men derfor er der nu stadig noget at lave. Beskæring kan i princippet ske året rundt, bare man holder sig fra perioden, hvor alt vågner om foråret (det er klart at et saftspændt træ er meget sårbart), og tilsvarende holder sig fra perioden om efteråret, hvor alt forbereder sig på vinterpausen (beskæring stimulerer nyvækst, og sker det for sent, så kan det ikke nå at etablere sig inden vinteren).

Vinen fik derfor sin vinterbeskæring, og frugttræerne har også fået en tur (minus stenfrugterne, som min havebog anbefaler at man sommerbeskærer aht. faren for svampeangreb). Den sene et-årige hindbær blev skåret helt ned (det var vist det med den sene efterårsklargøring, som nok ikke helt nåede ud i krogene), og jeg fik skåret sommerfuglebusk og lavendel ned (og så er vi mere ovre i den alt for tidlige forårsklargøring, men der var markeringer til knopper, så jeg vil mene at der er gode chancer for at jeg har ramt rigtigt med saksen).

Vildnisset ud imod den store vej skar vi ned i et par meters højde for en tre års tid siden - det er nu nået op i noget der ligner fire meter, og derfor skal det have en tur mere. Det sker også nu, dels pga. at der er hvileperiode, så træer og buske har bedst af at der sker nu, men også af hensyn til de dyr og fugle som ellers har det som fristed om sommeren. For taler også, at det er meget nemmere at se, hvor man skal save og skære, når der ikke er nogen blade på træerne - jeg skal dog hilse og fortælle, at torne fungerer glimrende som forsvar hele året rundt.

Men når dagene er korte og vejret omskifteligt, som det er nu, så når man ikke så meget. Og det egentlig ikke så skidt...

Nikon perspektivkontrol linse

Det er for længe siden, at jeg har eksponeret(!) den side af mig, som gode venner kalder "fotonørden", så hermed lidt om, hvad jeg fandt på nettet i dag. En ny linse fra Nikon til perspektivkontrol: PC-E Nikkor 24mm f/3.5D ED (og her er pressemeddelelsen).

Nu er der sikkert mange af jer, som tænker "og hva' så?", og det er også helt i orden. Tak for at I kiggede forbi, og kom snart igen.

For dem som stadig hænger på, kan jeg så lige sige, at linsen sandsynligvis kommer til at koste et femcifret antal kroner i Danmark. Nå, der røg endnu flere...

Ja, ja, da. Men til gengæld, så har den manuelt fokus og - på de fleste kameraer - manuel blændeindstilling. Hallo, er der stadig nogen tilbage?

De er jer, som stadig hænger på, kan man vist opdele i to grupper: Dem som ved, hvad en perspektivkontrol linse er for noget, og dem som ikke rigtig har en fornemmelse.

Til de første vil jeg sige, at grunden til at jeg synes at det her er stort, er at denne linse (og rygtet vil vide at der kommer flere) udfylder et efter min mening stort hul i Nikons linseprogram - det har i lang tid været sådan at Canon havde en, mens Nikon savnede den. Og så må I iøvrigt godt stoppe læsningen her, for nu vil jeg blamere mig med et forsøg på nogle pseudovidenskabelige bortforklaringer.

Hvad er så ideen i en perspektivkontrollinse (eller en såkaldt tilt-shift-linse?). Jo, lad os starte med normaltilfældet:



Og det er jo dejligt, når man bliver præsenteret for så symmetriske motiver. Men hvad sker der, når man møder noget, som ikke er symmetrisk, f.eks. fordi at man vil tage et billede af et højt træ eller et stort hus. Jo, men tipper da bare kameraet:



Og så sker det, som næsten altid er tilfældet, nemlig at motivet også "tipper" på afbildningsplanet. Lodrette linier, som i virkeligheden er parallelle vil i afbildningen få "perspektiv", dvs. at det langtfra vil forekomme nærmere hinanden i afbildningen end det der er tæt på. Hvis man overdriver det, så kan man få ganske dramatiske billeder ud af det (tip: prøv ikke med svigermor!), men hvor det kun er en smule, der kan det være ganske forstyrrende.

Løsningen er, at i stedet for tippe kamera (linse + afbildningplanet), så holder man afbildningsplanet parallelt med det man vil afbilde, og forskubber i stedet linsen.




Tilsvarende så kan man ved at "tilte" linsen i forhold til afbildningsplanet opnå at fokus også "tilter", så en del af afbildningsplanet fokuserer tæt på, og den anden del fokuserer længere væk.

Disse effekter er kendte for folk, som er vant til at fotografere med bælgkameraer - det er ikke mindst pga. den store fleksibilitet en bælg giver en, at det er interessant (småformatkameraer bruger dog næsten udelukkende bælg til makroarbejde). Men prisen for fleksibiliteten er, at det ender med at blive "pille-nusse" arbejde, og derfor er linser af denne type til folk, som er villige til at stå og skrue og justere på alle parametre for at få det helt rigtige billede. Det er sikkert ikke mindst derfor, at autofokus og andre former for automatisk er blevet fravalgt i denne linse.

Der er ingen tvivl om, at for specialister, så er dette en stor og velkommen nyhed. Vi andre må nøjes med at synes at det er snedigt, og så i øvrigt drømme om den store lottogevinst.

Agil opsplitning

Hvordan kan det være, at lige når man har trykket "Udgiv"-knappen, så går der mindre end et døgn inden man opdager noget, som burde have haft med? Jeg har prøvet at gå og vente med at skrive indlægget og jeg såmænd også prøvet at skrive det, og så ladet det ligge, men ingen af delene virker - effekten er uløseligt forbundet til "Udgiv"-knappen.

Og selvfølgelig er der lige sket igen. Jeg skrev så sent som i går om udfordringerne ved off-shoring under titlen Lost in translation, og allerede i dag falder jeg over blog-posten med titlen Agile India, som undrer sig over at der dels er en stor interesse for agil udvikling i Indien, men samtidig også bemærkelsesværdigt få succeshistorier. Forfatteren overvejer, om ikke dette skal tilskrives de udfordringer, der ligger i at kommunikationen ikke er så god, som hvis man sad lige ved siden af hinanden.

Men en egentlige perle i blog-posten er henvisning til Martin Fowlers artikel med titlen Agile Software Process with Offshore Development. Her beskriver Fowler en lang række snusfornuftige overvejelser omkring udfordringerne i at få agil udvikling til at fungere med Thoughtworks teamet i Bangalore. Bemærk at mange af overvejelser går på at få distribuerede teams til at fungere, så læs den endeligt selvom det ikke er Bangalore, men derimod Bagsværd eller Ballerup. Og læs den også selvom at det "kun" er kunden og udviklingsteamet som er adskilt, for Fowler prøver at få alt til at foregå offshore, men erkender at kravsspecifikation naturligt kun kan ske on-shore - og det svarer til det setup, som desværre er meget almindeligt med en offsite kunde.

Fowler har desuden flere pointer, som i bund og grund ikke er relateret til distribuerede teams, men som faktisk er generelt gode råd:

Han nævner, at en effektiv måde at få et nyt team introduceret til kodebasen på, er ved at lade dem lave fejlrettelser den første tid. Hans argument er, at fejlrettelser naturligt involverer langt mere kodelæsning end kodeskrivning. Det kan jeg skrive under på, og det gælder ikke kun for teams, men også når man skal introducere nye folk på projektet. Dels tvinger det en ud i hjørnerne af koden og dels så er det nemt at få en succesoplevelse - det er svært tilfredsstillende at få noget til at fungere, også selvom det i virkeligheden kun bestod i at skrive "not" foran en betingelse i en if-sætning. En anden effekt er, at det er nemmere at finde en fejl i en eksisterende programstump, når man ved hvordan den manifesterer sig, end det er en skrive en rimeligt fejlfri implementation fra bunden af.

Det er også med en vis glæde at jeg ser hans anbefaling af at foretrække en funktionelt opdeling. Han fodrer her en af de kæpheste, som jeg i går spændte foran min vogn, og det ser man specielt, hvis man følger linkene helt ud og ser at hans definition af funktionel opdeling er, at lade forretningen (eller med lidt god vilje, problemdomænet) determinere grænsernes placering.

Fowler har to pointer om distribuerede team, som jeg vil fremhæve:

Dels bemærker han, at hvis man påtænker at påtage sig det overhead der ligger i at have distribueret udvikling, så skal man gøre sig klart, at man i høj grad fraskriver sig en af de helt store fordele ved at være agil, nemlig at man kan erstatte store dele af den formelle dokumentation med uformel kommunikation, som jo er mange gange mere effektivt. Men i kraft af adskillelsen, så bliver det igen nødvendigt med en større formalisme i kommunikationen.

Desuden er hans klare anbefaling, at hvis man skal retfærdiggøre distribuerede teams og de udfordringer, som det bringer med sig, så skal man gøre det i forhold til at kunne tiltrække de rette kompetencer. Forskellen i produktivitet overstiger langt forskellene i aflønning, så det er dyrt i længden, hvis man køber billigt.

En enkelt ting, som jeg umiddelbart har svært ved at se, hvordan man skal implementere hvis udviklingen sker i Bagsværd fremfor Bangalore, er hans anbefaling af at udveksle lokale informationer og specialiteter. Så spændende er det heller ikke at høre om Bagsværd BK, og lokale specialiteter fra Bagsværd og omegn kan jeg ikke rigtigt komme i tanke om (selvom jeg har hørt øst-sjællændere beklage sig over de usle hotdogs, som de mener at vi har her i Jylland...).