The Design Death! September 14, 2010 12:56 about 1 year ago
Virksomheder der udvikler software har svært ved at se sammenhængen mellem pris og kodekvalitet. Derfor risikere de at lide design døden. Undervejs kæmper de med teknisk gæld og enterprise død.
Design død henviser til at et projekt er stagneret eller nået dertil hvor det stort set er umuligt at tilføre mere ny funktionalitet. Det handler om udviklingsprocessen og udviklingsteams men er i realiteten et ledelsesstyret fænomen ofte set i virksomheder hvor IT endnu ikke tages alvorligt som en betydningsfuld del forretningen.
Design for mig er en måde at fastholde tanker, krav og forudsætninger omkring forretningsprocesser der ønskes udført af en computer. Det er ikke vigtigt hvorvidt det er UI design, interaktions-mønster eller aktivitetsdiagrammer.
Enhver udviklingsproces må have en designfase hvor målet er at organisere og strukturere hvad der skal ske og i hvilken rækkefølge det skal foregå. Når processen er forstået af alle for en fastlagt periode er det tid til at omsætte ord til handling i form af kode. Og hermed mener jeg kode af en vis kvalitet. God kvalitet.
IT ledelse, projektledere og udviklingsteams kan ikke altid se det essensielle i god kodekvalitet og kodeforbedringer. Høj kodekvalitet giver normalt ikke mere funktionalitet men brænder alligevel tid af kalenderen.
Man høre ofte fra et udviklingsteam: Vi behøver mere tid til at rense koden, vi skal refactorere eller vi skal rette nogle tekniske bugs. Hvis vi dog bare fik lov at fjerne mananeren, den centrale dims i programmet vil alt blive bedre. Alle disse undskyldninger(statements) er højst sandsynligt et tegn på teknisk gæld.
Kodekvalitet ser mange som en subjektiv opfattelse men der findes ret klare ideer om hvad der er god kode. At fremstille kode er en tankemæssige proces. Det er ikke en kreativ proces der er åben for “Thinking outside the box”. Tværtimod, det er langt bedre at være i boxen.
Kvalitetskode følger beautfull code principperne og den løser de forretningsmæssig problemer på en simple, enkelt og koncis måde. Kvalitets-kode løser senarie fra den virkelige verden. Kvalitetskode løser ikke tekniske problemer man selv har skabt med dårlig kode i en tidligere release.
På en konference hørte jeg en tale om god og dårlige kode-filosofi. Den dårlige er at der findes tusind måder at udføre en rutine på og alle er korrekte. Det er ikke en god måde at betrakte kode på. En bedre måde er at der kun findes en korrekt måde at udføre en rutine på. Måske findes der ikke tid nok til den perfekte løsning men det er godt at stræbe efter. I takt med man får en bedre forståelse af problemområdet kan den forfines. Pointen er at man skal fremstille kode af dem best mulige kvalitet man magter på den afsatte tid.
Når man læser kode er det et væsenligt problem hvis man ikke forstår det! Kode er skrevet for mennesker, selvom det hedder kode. Assembly language er skrevet for maskiner. Hvis man læser kode og ikke umiddelbart kan forstå hvad det gør er det dårlige kode. Kode representerer menneskelige tanke og processer, denne forståelse skal kunne overføres til andre mennesker. Hvis det kræver lange kognitive processer at forstå koden er den af ringe kvalitet.
At fremstille kode en kognitiv proces. Hvis man vil være produktiv i denne proces kræver det et roligt og afbalanceret miljø for at være produktiv. Hvis man presses yderlige af tidsfrister, støj eller andre irritationsmomenter vil de kognitive tankeprocesser forringes og produktiviteten går ned.
Der er foretaget mange undersøgelser på grupper der udføre kognitive opgaver med forskellige forme for pres. Konklusionen er at der er signifikant diametralt lighed mellem hastighed og pres. Jo mindre pres grupperne udsættes for jo hurtigere arbejder de kognitive processer og jo før bliver opgaverne færdige.
Denne erkendelse er grunden til at man i SCRUM selv tager opgaver af produktbacklog’en.
Technical debt
Tekniske gæld er en metafor der fokuser på konsekvensen af dårligt fremstillet softwarearkitektur og forhastede softwareudvikling. Metaforen drager sammenligninger mellem en teknisks kompleksitet og gæld. Første ilteration af en kodebase har måske en lille gæld. Det er ikke farligt men det skal betales tilbage omgående og helst uden renter. Bliver gælden ikke tilbagebetalt løber der renter på og den samlede gæld bliver større. Hver minut der bruge på at tilbagebetale gæld bruges ikke på ny funktionalitet.
Når man planlægger et “greenfield project” er det muligt at planlægge et simpelt design og nå at implementere det meste med kun nogle få hacks. (hacks = dårlig kode) I næste fase estimers på samme måde men nu skal udviklerne også nå at tage hensyn til den dårlige kode fra første fase med ringere fremdrift til følge. Presset stiger og alle må arbejde hårde for at nå deadline og laver derved mere dårlig kode. Kodekvaliteten i løsningen begynder at falde.
Den tekniske gæld er området mellem den mængde software der kunne være konstrueret med normal udviklings hastighed og den mænde der rent faktisk er konstrueret med for høj udviklings hastighed og dårlig kvalitet til følge.
Kodenbasen kan stadig være fuld funktionel og eksekvere alle test men hvis ikke den tekniske gæld bliver betalt inden næsten iteration vil mængden af teknisk gæld bliver større og større og det bliver mere og mere besværligt at tilføre ny funktionalitet, hvilket i sidste ende føre til totalt design død. Ved total design død er kodenbasen så inficeret med dårlige beslutninger og dårlig kode og den kognitive oplevelse er så dårlig at det tager dage blot at skaffe sig et minimum af forståelse. Det betyder at ingen i realiteten vil røre koden. Det vanskeliggør defekt rettelser og alle håber at den ene person der stadig tør lave ændringer ikke rejser.
Et ikke uvæsenligt problem ligger i at stor mængder af forretningsviden, afstemt af forretningen, tilrettelser/bugfix/defects ligger kodebasen som ingen tør røre. Den direkte effekt er at den mindste defekt rettelse nu tager en måned fremfor en dag. Alting hænger sammen og ved enhver rettelse ødelægges noget andet. Højst sandsynligt vil der skabes flere defects end der rettes.
Resultatet er flere ansatte eller konsulenter i afdelingen. Hvis man vil drive en ægte legacy kodebase frem skal der mange hænder til og ofte af den slags der udføre arbejder meget lig vedligehold. De rigtige udvikler typer er væk og applikationsegenskaberne bliver kun værre.
Meget få virksomheder har viljen eller evnen til at se sammenhængen mellem kodekvalitet og pris mens de stadig har en change for at ændre vilkårne. Forskel på god kvalitet kode og dårlig kvalitet kode kan indirekte aflæses i IT afdelingens mandtal. Det er muligt at tilføre flere ressource uden at få større throughput. En smidig vidensorienteret virksomhed vil hurtigt opdage at denne process er for dyr
Enterprise Dead
Denne tilstand må dog på ingen måde forveksles med “enterprise dead”. Enterprise Dead kan man erkende ved det valgte afdelingslayout eller mangle på samme. Problemet er at forskellige afdelinger har forskellige forudsætninger og bygger forskellige forretningsprocesser op omkring deres ansvarsområder og dermed også deres services overfor andre afdelinger. Udviklingsafdelingen er ofte sidste led og skal overholde en række regler og overbevisninger der i sagens natur ikke stammer fra områder der noget med udvikling at gøre. Enterprise Dead er virksomhedens egen inerti og kan dræbe al fremgang.
Konklusionen er at det kan lade sig gøre at være en adræt udviklingsorganisation men det kræver smidehed, simpelhed og vilje i den tilstødende organisation.
By Frank Vilhelmsen - 2 tags: architecture development - Add comment