Har besluttet mig for at lave en selvstændig blog om Tech-Ed 2009. Du finder den her.
photostream 130
3 dage siden
onsdag den 28. oktober 2009
tirsdag den 27. oktober 2009
Tech-Ed 2009 i Berlin
Der er ihvertfald mange interessante sessioner, men nu må vi se hvad det bliver til - Berlin er jo en dejlig by, også om aftenen...
mandag den 26. oktober 2009
Quick-and-dirty løsninger – del II: Den hurtigste vej til kundens tillid?
I Quick-and-dirty løsninger – del I: Definition af et tveægget sværd har jeg forsøgt at definere hvad en quick-and-dirty løsning er, når det kommer til softwareudvikling. I 2. del vil jeg skrive om den lyse side af quick-and-dirty løsninger - den mørke side gemmer jeg til 3. del...
Operationen lykkedes, men patienten døde
Ofte synes jeg at analogier kan være ret belastende, i hvert fald de lange og meget søgte, men i denne sammenhæng er det meget nærliggende:
Når en patient bliver bragt ind på skadestuen i en kritisk tilstand – hjertestop, organsvigt eller med blodet sprøjtende ud af arme & ben, så er det lægens allervigtigste job at få patienten stabiliseret og redde patientens liv. Det kan være essentielt at lægen får nogle få, men præcise informationer om, hvad der er gået forud: er det en trafikulykke, i så fald, hvor var personen placeret i bilen, eller hvis det er noget medicinsk (fx selvmordsforsøg) – er der fundet tomme pilleglas, hvor mange, etc. Informationer, som kan gøre lægen i stand til at redde patientens liv her og nu. Det er ikke relevant at vide om bilen er af et bestemt mærke, hvor hurtigt bilen kørte –eller om patienten gennem længere tid har været deprimeret og har en historie med selvmordsforsøg.
Når patienen er blevet stabil, når livet er blevet reddet, kan det så i nogle tilfælde være relevant at se på årsagen, og dermed forhindre en gentagelse – fx samtaler og terapi til en person, der har forsøgt selvmord, eller diæt og ændret levevis til en person, der er blevet opereret for forkalkning i kranspulsåren.
Det er nærmest banalt indlysende, at hvis man gør det omvendt – dvs. fokuserer på den bagvedliggende årsag først, og fx beder hjertepatienten om at omlægge sit liv, men undlader at lave den nødvendige by-pass operation for at løse det konkrete problem med manglende blodgennemstrømning i kranspulsåren, så ender man i situationen, hvor ”operationen lykkedes, men patienten døde”: Vi fik ham rent faktisk til at begynde at dyrke motion, og spise salat i stedet for wienerbrød, men desværre døde han under sin første løbetur ned til salatbaren...
Det er nemt at overføre denne analogi på et softwareproblem (et tænkt og helt tilfældigt eksempel):
I en e-handelsvirksomhed findes tilsyneladende en hukommelseslæk i den anvendte e-handelsplatform, som medfører at web-serverne mange gange om dagen smider brugerne af eller helt holder op med at svare. Det betyder, at virksomheden mister ordrer, og ydermere at kunderne forsvinder for måske aldrig at komme tilbage igen. Virksomheden mister derfor mange penge hver dag, og problemet kan i sidste ende betyde, at virksomheden må lukke.
Det er ikke umiddelbart muligt at identificere hukommelseslækken, og det vil kræve en større analyse og debugging af koden at finde og løse den grundlæggende årsag til problemet. Hvis man derfor går denne vej er der overhængende risiko for, at virksomhedens forretning tager ubodelig skade, også selvom det efter et stykke tid skulle lykkes at identificere og fjerne hukommelseslækken.
Et fornuftig problemløser vil derfor i ovennævnte scenarie derfor starte med at stoppe blødningen med en quick-and-dirty løsning, som i dette tilfælde kunne være, at recycle application pools på web-serverne løbende, at sætte flere webservere op i en farm eller at komme mere hukommelse i serverene. Muligvis en kombination af de nævnte. Når systemet er blevet stabiliseret så godt som muligt, dvs. ordrer kan modtages og kunderne ikke mere bliver smidt af systemet, så kan det egentlige arbejde med at identificere og løse årsagen til hukommelseslækken påbegyndes.
Det er naturligvis et meget simpelt eksempel, men princippet er præcis det samme i mere komplekse scenarier.
Fokus og handlekraft skaber tillid
Hvad har det at gøre med tillid fra kunden? Nogle vil sige ALT (jeg kender ihvertfald én som vil sige det...)
Kunden har et alvorligt problem, og har brug for en løsning nu og her. At man fokuserer på det, som kunden betragter som sit største problem ( jeg mister penge/kunder), og laver en tilfredsstillende løsning skaber tillid. Hvis man i stedet begynder at tale om "at analysere problemstillingen", "at sætte et monitoreringsprogram op", osv, så vil mange tænke: Det lyder dyrt, og kan jeg i det hele taget være sikker på, at mit problem bliver løst hurtigt nok? Og de tanker er ikke tillidsskabende.
Når patienten bløder kraftigt, så er det med at stoppe blødningen som det første – ikke at analysere hvad der er skyld i at han bløder. Dette er en sandhed der gælder såvel på skadestuen som i serverrummet!
Det er i øvrigt nogle af de tanker, som ligger bag Miracles PerformanceDuo – der ovenikøbet fungerer helt efter No Cure No Pay princippet: Hvis vi ikke løser dit problem i dag - i dette tilfælde, forbedre performance på dit system - så skal du ikke betale noget. Se dét er forretning, der er til at forstå!
Men nu vokser træerne ikke ind i himlen (ok, den vending hader jeg også, men i mangel på bedre..), og selvom der er mange gode grunde til at stoppe blødningen nu og her, så er der også tilfælde hvor man bestemt IKKE skal hengive sig til de hurtige løsninger.
For at blive i de irriterende analogiers verden, så vil det nok ikke være hensigtsmæssigt, at sende et overvægtigt barn til fedtsugning for at løse det umiddelbare problem (der måske er defineret som: Ungen er alt for tyk til at køre på sin cykel, og skal iøvrigt hele tiden have nyt tøj...). Her vil en mere langsigtet strategi, og en fokus på den grundlæggende årsag til overvægten nok være den foretrukne løsningsmodel for de fleste læger og diætister.
Og når vi taler de fatale (mis)brug af quick-and-dirty løsninger i it-projekter, som et middel til at nå deadlines og leverancer, så vi på vej over i min oprindelige kæphest: At quick-and-dirty løsninger kan være en hurtig vej til en langsom død.
Det vil jeg skrive mere om i næste del, som handler om den mørke side:
Quick-and-dirty løsninger – del III: En hurtig vej til en langsom død. (to be written...)
Ofte synes jeg at analogier kan være ret belastende, i hvert fald de lange og meget søgte, men i denne sammenhæng er det meget nærliggende:
Når en patient bliver bragt ind på skadestuen i en kritisk tilstand – hjertestop, organsvigt eller med blodet sprøjtende ud af arme & ben, så er det lægens allervigtigste job at få patienten stabiliseret og redde patientens liv. Det kan være essentielt at lægen får nogle få, men præcise informationer om, hvad der er gået forud: er det en trafikulykke, i så fald, hvor var personen placeret i bilen, eller hvis det er noget medicinsk (fx selvmordsforsøg) – er der fundet tomme pilleglas, hvor mange, etc. Informationer, som kan gøre lægen i stand til at redde patientens liv her og nu. Det er ikke relevant at vide om bilen er af et bestemt mærke, hvor hurtigt bilen kørte –eller om patienten gennem længere tid har været deprimeret og har en historie med selvmordsforsøg.
Når patienen er blevet stabil, når livet er blevet reddet, kan det så i nogle tilfælde være relevant at se på årsagen, og dermed forhindre en gentagelse – fx samtaler og terapi til en person, der har forsøgt selvmord, eller diæt og ændret levevis til en person, der er blevet opereret for forkalkning i kranspulsåren.
Det er nærmest banalt indlysende, at hvis man gør det omvendt – dvs. fokuserer på den bagvedliggende årsag først, og fx beder hjertepatienten om at omlægge sit liv, men undlader at lave den nødvendige by-pass operation for at løse det konkrete problem med manglende blodgennemstrømning i kranspulsåren, så ender man i situationen, hvor ”operationen lykkedes, men patienten døde”: Vi fik ham rent faktisk til at begynde at dyrke motion, og spise salat i stedet for wienerbrød, men desværre døde han under sin første løbetur ned til salatbaren...
Det er nemt at overføre denne analogi på et softwareproblem (et tænkt og helt tilfældigt eksempel):
I en e-handelsvirksomhed findes tilsyneladende en hukommelseslæk i den anvendte e-handelsplatform, som medfører at web-serverne mange gange om dagen smider brugerne af eller helt holder op med at svare. Det betyder, at virksomheden mister ordrer, og ydermere at kunderne forsvinder for måske aldrig at komme tilbage igen. Virksomheden mister derfor mange penge hver dag, og problemet kan i sidste ende betyde, at virksomheden må lukke.
Det er ikke umiddelbart muligt at identificere hukommelseslækken, og det vil kræve en større analyse og debugging af koden at finde og løse den grundlæggende årsag til problemet. Hvis man derfor går denne vej er der overhængende risiko for, at virksomhedens forretning tager ubodelig skade, også selvom det efter et stykke tid skulle lykkes at identificere og fjerne hukommelseslækken.
Et fornuftig problemløser vil derfor i ovennævnte scenarie derfor starte med at stoppe blødningen med en quick-and-dirty løsning, som i dette tilfælde kunne være, at recycle application pools på web-serverne løbende, at sætte flere webservere op i en farm eller at komme mere hukommelse i serverene. Muligvis en kombination af de nævnte. Når systemet er blevet stabiliseret så godt som muligt, dvs. ordrer kan modtages og kunderne ikke mere bliver smidt af systemet, så kan det egentlige arbejde med at identificere og løse årsagen til hukommelseslækken påbegyndes.
Det er naturligvis et meget simpelt eksempel, men princippet er præcis det samme i mere komplekse scenarier.
Fokus og handlekraft skaber tillid
Hvad har det at gøre med tillid fra kunden? Nogle vil sige ALT (jeg kender ihvertfald én som vil sige det...)
Kunden har et alvorligt problem, og har brug for en løsning nu og her. At man fokuserer på det, som kunden betragter som sit største problem ( jeg mister penge/kunder), og laver en tilfredsstillende løsning skaber tillid. Hvis man i stedet begynder at tale om "at analysere problemstillingen", "at sætte et monitoreringsprogram op", osv, så vil mange tænke: Det lyder dyrt, og kan jeg i det hele taget være sikker på, at mit problem bliver løst hurtigt nok? Og de tanker er ikke tillidsskabende.
Når patienten bløder kraftigt, så er det med at stoppe blødningen som det første – ikke at analysere hvad der er skyld i at han bløder. Dette er en sandhed der gælder såvel på skadestuen som i serverrummet!
Det er i øvrigt nogle af de tanker, som ligger bag Miracles PerformanceDuo – der ovenikøbet fungerer helt efter No Cure No Pay princippet: Hvis vi ikke løser dit problem i dag - i dette tilfælde, forbedre performance på dit system - så skal du ikke betale noget. Se dét er forretning, der er til at forstå!
Men nu vokser træerne ikke ind i himlen (ok, den vending hader jeg også, men i mangel på bedre..), og selvom der er mange gode grunde til at stoppe blødningen nu og her, så er der også tilfælde hvor man bestemt IKKE skal hengive sig til de hurtige løsninger.
For at blive i de irriterende analogiers verden, så vil det nok ikke være hensigtsmæssigt, at sende et overvægtigt barn til fedtsugning for at løse det umiddelbare problem (der måske er defineret som: Ungen er alt for tyk til at køre på sin cykel, og skal iøvrigt hele tiden have nyt tøj...). Her vil en mere langsigtet strategi, og en fokus på den grundlæggende årsag til overvægten nok være den foretrukne løsningsmodel for de fleste læger og diætister.
Og når vi taler de fatale (mis)brug af quick-and-dirty løsninger i it-projekter, som et middel til at nå deadlines og leverancer, så vi på vej over i min oprindelige kæphest: At quick-and-dirty løsninger kan være en hurtig vej til en langsom død.
Det vil jeg skrive mere om i næste del, som handler om den mørke side:
Quick-and-dirty løsninger – del III: En hurtig vej til en langsom død. (to be written...)
Quick-and-dirty løsninger – del I: Definition af et tveægget sværd.
Jeg har længe haft lyst til at skrive om brugen af "quick-and-dirty" løsninger i sofwareudvikling, med udgangspunkt i min holdning om, at disse løsninger hurtigt holder op med at være "quick", men til gengæld bliver mere og mere "dirty", som tiden går. Blogindlægget var derfor planlagt til at hedde noget i retning af "Quick-and-dirty – den hurtigste vej til en langsom død".
Så var der en god kollega, der i bedste provokerende stil spurgte, om jeg ikke skrev et indlæg med titlen "Quick-and-dirty panikløsninger – den hurtigste vej til kunden tillid". Dén kunne jeg naturligvis ikke sidde overhørig, og efter at have rumlet et stykke tid besluttede jeg mig for, at der måtte være basis for mere end ét indlæg om dette emne.
Første del er en simpel definition af, hvad en quick-and-dirty løsning er når det drejer sig om softwareudvikling.
Definition af quick-and-dirty
En tur i wikipedia giver følgende definition (frit oversat til dansk):
"Quick-and-dirty er et begreb der anvendes i forbindelse med en løsning, som er en nem måde at implementerer en workaround eller en "kludge" på. Begrebet er populært blandt programmører, der anvender det til at beskrive en rå løsning, som ikke er perfekt, er uelegant (eller på anden måde utilstrækkelig), men som løser et konkret og nærværende problem, og som ofte er hurtigere og nemmere at implementere end en mere korrekt løsning"
Når man læser hvad wiki skriver om begrebet "kludge", der er et begreb hvis anvendelse er bredere end softwareudvikling, så er det tydeligt at det er to sider af samme sag. Den indledende definition lyder nemlig som følger:
"A kludge (or kluge) is a workaround, a quick-and-dirty solution, a clumsy or inelegant, yet effective, solution to a problem, typically using parts that are cobbled together. This term is diversely used in fields such as computer science, aerospace engineering, Internet slang, and evolutionary neuroscience."
Det fører mig frem til min definition af begrebet quick-and-dirty løsning i forhold til softwareudvikling:
"En quick-and-dirty løsning er en uelegant, men effektiv løsning af et konkret problem. Løsningen tager ikke nødvendigvis hensyn til kontekst, design og arkitektur af det omkringliggende system, men er alene fokuseret på den rå løsning."
Med denne definition på plads går vi videre til anden del:
Quick-and-dirty løsninger – del II: Den hurtigste vej til kundens tillid?
Så var der en god kollega, der i bedste provokerende stil spurgte, om jeg ikke skrev et indlæg med titlen "Quick-and-dirty panikløsninger – den hurtigste vej til kunden tillid". Dén kunne jeg naturligvis ikke sidde overhørig, og efter at have rumlet et stykke tid besluttede jeg mig for, at der måtte være basis for mere end ét indlæg om dette emne.
Første del er en simpel definition af, hvad en quick-and-dirty løsning er når det drejer sig om softwareudvikling.
Definition af quick-and-dirty
En tur i wikipedia giver følgende definition (frit oversat til dansk):
"Quick-and-dirty er et begreb der anvendes i forbindelse med en løsning, som er en nem måde at implementerer en workaround eller en "kludge" på. Begrebet er populært blandt programmører, der anvender det til at beskrive en rå løsning, som ikke er perfekt, er uelegant (eller på anden måde utilstrækkelig), men som løser et konkret og nærværende problem, og som ofte er hurtigere og nemmere at implementere end en mere korrekt løsning"
Når man læser hvad wiki skriver om begrebet "kludge", der er et begreb hvis anvendelse er bredere end softwareudvikling, så er det tydeligt at det er to sider af samme sag. Den indledende definition lyder nemlig som følger:
"A kludge (or kluge) is a workaround, a quick-and-dirty solution, a clumsy or inelegant, yet effective, solution to a problem, typically using parts that are cobbled together. This term is diversely used in fields such as computer science, aerospace engineering, Internet slang, and evolutionary neuroscience."
Det fører mig frem til min definition af begrebet quick-and-dirty løsning i forhold til softwareudvikling:
"En quick-and-dirty løsning er en uelegant, men effektiv løsning af et konkret problem. Løsningen tager ikke nødvendigvis hensyn til kontekst, design og arkitektur af det omkringliggende system, men er alene fokuseret på den rå løsning."
Med denne definition på plads går vi videre til anden del:
Quick-and-dirty løsninger – del II: Den hurtigste vej til kundens tillid?
tirsdag den 13. oktober 2009
Et estimat er IKKE en forpligtelse
Projektleder: ”Hvornår kan I være færdige med komponeten til ERP-integration?”
Udvikler: ”Tja, vi har estimeret den til 5 dage, og da vi ikke er kommet i gang med opgaven endnu, så er det stadig bedste bud.”
Projektleder: ”Er det 5 arbejdsdage?”
Udvikler: ”Øh, ja, vi regner med det tager 5 dage, hvis alt gå godt...”
Projektleder: ” Det er fint, 5 arbejdsdage, og det er mandag i dag...dvs. at den er klar på fredag .”
Udvikler: ”Fredag? Det tror jeg ikke du skal regne med, men spørg mig igen i morgen eftermiddag, så kan jeg sige det mere præcist.”
Projektleder: ” Mere præcist? Har du ikke lige sagt komponenten er færdig om 5 dage? Og hvis du arbejder på den hver dag i denne uge, og så måske giver den en skalle en aften, så er den vel færdig på fredag, hvis ellers jeg kan regne...”
Udvikler: ” Måske er den færdig på fredag, men jeg kan ikke sige det mere præcist nu.
Projektleder: ”Ok, jeg siger til kunden at vi er færdige med komponeten på fredag som vi har lovet!”
Kan du nikke genkendende til ovenstående dialog mellem en projektleder og en udvikler? Eller er det et fuldkomment urealistisk & tænkt eksempel, som ikke har gang på denne jord ...?
Jeg tror de fleste udviklere har prøvet at stå i en situation, hvor deres estimater bliver opfattet som en forpligtelse til at levere på et bestemt tidspunkt. Og det er en kilde til mange alvorlige problemer i et it-projekt!
Det er egentlig utroligt, når man tænker på, at dygtige mennesker har skrevet stolpe op & stolpe ned om estimering inden for softwareudvikling. Man fristes til at mene, at der må gå en masse sindssyge mennesker rundt i vores branche, hvis sindssyge kan defineres ved, at man foretager de samme handlinger om og om igen, men alligevel forventer forskellige resultater hver gang!
For ikke at blive beskyldt for at være useriøs har jeg slået ordene estimat og forpligtelse op i værker, som må betegnes som værende rimelige troværdige kilder:
Estimat: ”Statistisk udregnet skøn over den faktiske værdi af en talstørrelse ud fra et sæt måleresultater”
Kilde: Gyldendals encyklopædi – (statistik og matematik)
Forpligtelse: ”Det forhold, at man forpligter sig til noget; skyldighed; pligt; ogs. mere konkr.: betingelse, som man forpligter sig til at opfylde
Kilde: Ordbog over det danske sprog
Det burde være indelysende for enhver, at man ikke kan forpligte sig til at aflevere noget, som er baseret på et skøn, selvom det i bedste fald er underbygget af noget erfaring eller empiriske data.
En særlig variant af begrebet estimat er det i udviklerkredse nok så bekendte ”guesstimat”. Det er det man ofte bruger, når de empiriske data ikke er tilstede og erfaringen også er sparsom, f.eks. når man har intet eller kun lidt kendskab til den opgave man skal i gang med, men alligevel skal komme med et bud på hvor lang tid det tager.
Det giver ikke mening at komme med et længere blog indlæg om hvordan man skal estimere, og ikke mindst, at komme med værktøjer og gode argumenter – der findes en masse god litteratur om emnet, og jeg kan klart anbefale at læse Mike Cohns bog ”Agile estimating and planning”. Den findes også min liste over gode bøger her på bloggen.
Ligeledes har Giovanni Asproni skevet en glimrende artikel om emnet ” Fingers in the air: a Gentle Introduction to Software Estimation”, som enhver softwareudvikler og ikke mindst projektleder, burde læse igennem.
Og lad mig så lige til sidst slå fast med syvtommersøm:
Et estimat er IKKE en forpligtelse og det er IKKE til forhandling.
Hvor svært kan det være?
Leverancens forbandelse - når softwareudvikling bliver reduceret til et verbum
Et it-projekt handler om at levere noget til kunden. Og vi skal levere det, som kunden forventer, og helst til tiden... og til den aftalte pris. Så det gør vi, og alle glade, og dét var så dét blog indlæg. Eller hvad?
Ja, hvis virkeligheden så sådan ud, så ville der flyde mælk og honning på gangene hos landets it-leverandører, og ikke mindst hos alle deres kunder, men det gør der ikke – sidst jeg så efter…
I stedet for er virkeligheden fuld af kuldsejlede it-projekter både inden for den offentlige sektor (dem vi hører om, for her taler vi skattekroner..) og inden for den private sektor (dem vi IKKE hører så meget om... hmmm). Nuvel, der findes mange vellykkede it-projekter, men de er i denne sammenhæng ikke så interessante – og jeg tør godt vove det ene øje på, at de heller ikke udgør et flertal.
Der er rigtig mange kloge mennesker, der har skrevet mange kloge ord om dette emne – senest har jeg læst om ”5 holdninger til statslige it-understøttede forretningsprojekter”, der er formuleret af DANSK IT. Her står mange fornuftige ting, der helt sikkert ikke alene gælder for it-projekter i det offentlige, men også i den private sektor. Hent de 5 holdninger i pdf-format hos DANSK IT her.
Men hvordan ser det dårlige it-projekt egentlig ud indefra, dér hvor udviklerne sidder og tamper febrilsk i tasterne, høje på pizza & coca-cola, alt imens projektlederne kæmper med graferne og forsøger at overbevise kunden om, at der bliver leveret til tiden…
Det er hér vi kommer til leverancens forbandelse. For når et it-projekt er presset, så kommer det alt for ofte til at handle om AT levere, og ikke om HVAD der bliver leveret. Det skyldes som udgangspunkt den indgåede kontrakt, som kan indeholde meget rigide deadlines, og hårde bodsbetingelser hvis ikke der leveres. Og det betyder, at der bliver gået på kompromis med... hvad som helst! Udviklerne bliver bedt om at lave hurtige løsninger på komplekse problemer, og de leveringsansvarlige laver kreative fortolkninger af kravspecifikationen, fordi vi SKAL jo levere – koste hvad det vil.
Så der BLIVER leveret, i bedste fald noget halvfærdigt, i værste fald noget ubrugeligt. Den tekniske gæld eskalerer, og når der skydes genveje i den interne kvalitet – f.eks. mangelfulde eller helt udeladte unittest, dårligt design, etc., så kan det have alvorlige langsigtede konsekvenser, som der aldrig bliver kompenseret for. For hvornår bliver der tid & penge til at rette op på dårlige tekniske beslutninger taget under hårdt pres før en deadline? Never, ever...
Og mens kunden får en dårlig leverance og leverandøren et dårligt ry, så mister teknikerne – udviklere, arkitekter, testere - deres integritet, ja måske oven i købet troen på, at deres arbejde bliver taget alvorligt. For selvom softwareudvikling er en kreativ proces, så er det i højeste grad også et håndværk, hvor dygtige og stolte håndværkere står værn om kvaliteten af deres arbejde.
Når softwareudvikling derfor blive reduceret til ”at levere”, hvor det er sekundært hvad der bliver leveret, så er det et spil, som kun har tabere – kunden, leverandøren og udviklerne.
Hvad skal vi så gøre for at imødegå dette scenarie, når vi ofte arbejder i et landskab med fastpriskontrakter, hvor it-projekter på samme tid er tids- og funktionalitetbundet?
Det vil jeg komme med et bud på i et kommende indlæg på denne blog, men indtil da, kære læser, kan du jo tænke over, om du ville bygge dit hus eller en storebæltsbro eller et operahus på samme måde, som vi nogen gange accepterer at bygge software.
Abonner på:
Opslag (Atom)
