Dette indlæg er alene udtryk for skribentens egen holdning.

Er "best practices" en and?

2. juni 2014 kl. 08:598
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Da jeg gik på universitetet, var det sjældent, at vi fik brugt egentlig versionskontrol på vores projekter, test var noget vi kørte manuelt til sidst, og parprogrammering var mest noget, vi lavede, fordi det var rigtig hyggeligt. Så fik jeg mig et “rigtigt” job, og pludselig var kodebasen større, der var standarder for, hvordan koden skulle se ud, og alt skulle checkes ind i CVS (utroligt nok var der i øvrigt stadig 12%, der brugte CVS i 2013).

Og som tiden gik, samlede vi flere og flere idéer om, hvad der var det rigtige at gøre, nu skulle al koden igennem et peer review, man havde omtrent fortjent en sherifstjerne, hvis man glemte at checke en regressionstest ind (det mener jeg nu stadig), det blev forbudt at lave commits, der ikke var linket til et JIRA issue, og vi fik Git og kunne nu lykkeligt branche tidligt og silde.

Undervejs i denne her historie blev vi så opkøbt af et firma, som har adskillige produkter og udviklingsafdelinger, og prøver i et vist omfang at få alle de her udviklingsafdelinger til at samles om nogle “best practices”. Fordi hvis kode-review nu er godt for den ene udviklingsafdeling, så er det vel også godt for den anden udviklingsafdeling. Eller hvad?

Artiklen fortsætter efter annoncen

Vores kære testere har for eksempel været meget optaget af hele “context-driven testing”-tankegangen, hvor man faktisk forkaster idéen om, at der findes praksisser, som altid er det bedste, uanset konteksten. For kan det virkelig passe, at den samme praksis altid er optimal, uanset om alle udviklerne er erfarne rotter eller lige taget ind fra et AMU-kursus i webdesign, uanset om man laver et produkt, der skal videreudvikles i årevis, eller et one-shot spil til en reklamekampagne, uanset om man har 50 udviklere fordelt på 3 forskellige lokationer eller sidder alene mand (m/k) i kælderen?

Jeg kender en selvstændig udvikler, som laver et fantastisk stykke software, for hvilket han har nul - NUL - automatiske tests. Jeg var ved at falde ned af stolen, da han sagde det, for jeg synes, at det at lave kode uden tests føles ligeså utrygt som at køre i russiske taxaer uden sikkerhedsseler. Men måske har han ret; det er ikke sikkert, at den praksis giver mening i en kontekst, hvor man sidder som ene udvikler med stort overblik og fagligt overskud.

Tror du på “best practices” - og i givet fald hvilke, eller er det en and, at der skulle findes sådan nogle?

8 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
8
2. juni 2014 kl. 18:00

Hvis man kigger på http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition så mener jeg, at brugen af Best Practice - f.eks. indenfor sprog, frameworks og metoder - kan bringe en relativt hurtigt til niveauet Competent - så man rent faktisk kan få lavet noget. Derfra er så ens eget ansvar at uddanne sig videre til Proficient og Expert.

7
2. juni 2014 kl. 16:40

Erfarne folk (programmører, testere, designere, ... ) har nogle metoder og erfaringer, som de trækker på i deres daglige arbejde. De ved hvilke værktøjer de skal anvende hvornår. Når den erfaring skal videregives til yngre kollegaer, eller når den skal koordineres på tværs i organisationer, så er det en fordel at kunne systematisere beskrivelserne, og så kan man kalde det best practices eller guidelines eller hvad der nu passer.

Men det er ikke det samme som at den samme hammer kan bruges på alle problemer, og det ved de erfarne også godt. Så ja, best practices kan være glimrende, man skal "bare" vide hvilke man skal benytte hvornår.

5
2. juni 2014 kl. 12:35

Det handler om at kunne undgå at blive beskyldt for inkompetence og begrebet har hverken noget egentligt indhold eller nogen brug bar metrik for noget som helst.

Så glem alt om "best practice" og tal i stedet om hvad der virker -- hvad der dokumenteret virker.

3
2. juni 2014 kl. 11:06

Jeg har ca. 20 års taekwondo bag mig men skiftede til karate for to-tre år siden. De sparker lidt anderledes og for dem, som har trænet karate i mange år er det den mest effektive måde...jeg, som har taekwondobaggrund synes, at det er en utrolig ineffektiv måde...jeg er bare formet anderledes nu.

Tror det er det samme med programmering. Er du flasket op med funktionel programmering, så er det det eneste, der duer.

Mange best practices har ikke direkte modstridende practices så da kan man bare inddrage løs, men når der er to modstridende, så kan det være en idé at lade forskellige hold arbejde på forskellige måder. Nok ikke altid hvis det hele skal samles til ét produkt, men hvor jeg arbejder har vi mange helt separate produkter, og hver gruppe følger samme kodestandard og bruger samme versionsstyringssystem (Subversion, som har fantastisk branching funktionalitet!!!), men deres arbejdsgang og hvorvidt de vil holde en masse møder, er op til dem selv...bare de får arbejdet udført hurtigt og effektivt.

1
2. juni 2014 kl. 10:48

Tænk jer om!

Når det så er sagt så tror jeg netop at "One size fits all" som du så rigtigt påpeger er en dårlig tankegang. Lister over best practices giver mest mening som checklister og ikke som dogmer.

2
2. juni 2014 kl. 11:02

Hej Anne

Jeg betragter mig selv som pragmatiker og det betyder en naturlig skepsis overfor alle de idealistiske tiltag der sker indenfor vores branche og som prøver at trække bestemte "patterns" eller "udviklingsmodeller" ned over hovedet på os. Somregel skyldes det at nogen er blevet solgt på alle fordelene i den givne model og behændigt ignorerer eller endnu ikke har stiftet bekendtskab med alle ulemperne. Det er ikke meget ulig politik.

Mit udgangspunkt er ikke hvilke koncepter jeg nu skal hive ned over mine udviklere - mit udgangspunkt er projektet. Et essentielt spørgsmål i forhold til det her med automatiseret test du er inde på er hvad ens fejltolerance er? Er det et bank-system så kan fejl groft sagt ikke tolereres og det stiller store krav til både tests og Q/A. Er det derimod et intranet system du udvikler så er det måske ikke så kritisk om noget kan risikere at gå galt og nogen så er nød til at oprette en ticket for at få det løst - overheadet'et i at skrive og vedligeholde alle disse tests og for meget Q/A kan være sløvende for udviklingen af et sådant system. Men her er du også som du selv er inde på nød til at se på erfaringen af udviklerne i dit team - for har du ikke kompetente udviklere der skriver en meget høj grad af strukturet og fejlfri kode, så kan det godt være at test-driven igen er en bedre løsning fordi fejl-raten ellers er for høj. Igen det handler om at spørge sig selv hvad forretningsrisikoen er ved fejl - og kan vi leve med risikoen? Personligt designer jeg meget sjældent "bank-systemer", så jeg hælder generelt til at test-driven udvikling er for dyrt, men det er der mange holdninger til.

Pointen er at der er rigtig mange faktorer der spiller ind og overvejelser man skal gøre sig i forhold til det givne projekt i forhold til hvilke "værktøjer" og "metodikker" som giver mening.

At forsøge at hive en ensartet udviklingsprocess igennem på tværs af organisationer og udviklingsteams er sådan noget MBA'er drømmer om, men det er dømt til katastrofe.

4
2. juni 2014 kl. 12:27

At forsøge at hive en ensartet udviklingsprocess igennem på tværs af organisationer og udviklingsteams er sådan noget MBA'er drømmer om, men det er dømt til katastrofe

Som grænsende til at være IT/MBA'er, er jeg ikke helt enig i ovenstående. Du siger selv i dit indlæg, at det handler om "hvad forretningsrisikoen er ved fejl" - med andre ord, en cost/benefit-analyse. Denne cost/benefit-analyse må nødvendigvis bero på de karakteristika som er essentielle for systemet, og i en nogenlunde diversificeret virksomhed (der udvikler mere end én type af systemer) giver det selvfølgelig ikke mening at prøve at forcere én type af proces for alle udviklingsprojekter. En MBA'er med almindeligt fornuftigt omløb, må kunne se denne problematik ved at benytte en ensartet udviklingsproces. Forhåbentligt :-)

Derimod er det vigtigt for denne type af virksomheder at fastlægge en enterprise arkitektur, med hvilken de kan systematisere typerne af udviklingsprojekter, men uden at skulle kræve at alle projekterne følger samme proces. I denne kontekst er der mulighed for at etablere best practices som forskellige typer af udviklingsprojekter bør følge - især når det kommer til rapporteringen til den overordnede portefølje af projekter. Eksempler kunne være Best Practices ved Agil Udvikling, Vandfald etc. og Best Practices ift. systemkarakteristika (høj stabilitet, høj prioritet af UI etc.).

Så ja og nej: Medmindre at scope er meget, meget småt (f.eks. Backup af SharePoint 2007 Content Database...), så er der ikke én best practice. Til gengæld kan en større virksomhed sagtens have flere best practices - de skal bare tilpasses kontekst.

6
2. juni 2014 kl. 13:13

Hej Christian

Mit indtryk fra de store virksomheder jeg har arbejdet i er at det somregel besluttes fra centralt sted at køre PRINCE2, ITIL, COBIT etc. uden at nogen rigtig forstår hvad det indebærer - sådan gør alle de andre, så det må vi også hellere gøre! Ingen er jo blevet fyret på at hive en enterprise process ned over hovedet på folk.

Nogle gange er det endda ikke engang virksomheden selv som har beslutningskraft her - jeg har flere gange oplevet at det kommer som krav fra investorer eller ejer-selskaber at alle datter-selskaber følger den samme bestemte metode - uagtet hvor meget mening det giver for det enkelte selskab.

At pisse kreative folk som udviklere af med for mange rigide metoder er en sikker måde at sløve udviklingen ned på med en kraftig faktor - oftest gælder det at less is more, hvis du ikke er 100% sikker på værdien i en given metode, så lad være.

(Det skal måske lige præciseres at det altså ikke er fordi jeg har leget job-hopper at jeg har kendskab til mange store virksomheder - det skyldes jeg i en årrække har arbejdet som selvstændig konsulent hvor man kommer rundt omkring og oplever lidt af hvert i de danske virksomheder)