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...)
Ingen kommentarer:
Send en kommentar