DevOps-ekspert: Udviklere bliver bedre, hvis de selv skal lide under dårlig kode

Illustration: REDPIXEL.PL/Shutterstock Inc.
Udviklere laver bedre kode, hvis de selv får lov til at opleve problemerne, når applikationer tages i brug, mener DevOps-konsulent.

En almindelig beskrivelse af DevOps-konceptet er, at man skal nedbryde siloerne mellem udvikling og drift for at udvikle løsninger hurtigt og få dem hurtigt ud til kunderne.

Ofte indebærer det at gøre softwareudviklere ansvarlige for koden - også når applikationen er afleveret og i drift - og dermed sikre, at der ikke sidder en drifts- eller supportafdeling længere nede ad gangen, der lever med alle de problemer, som halvfærdig kode skaber.

Læs også: Undersøgelse: DevOps-organisationer arbejder langt hurtigere end andre

Og når udviklere selv skal bøvle med mangelfuld kode, bliver arbejdet sjovt nok også bedre, fortæller Leif Sørensen, der er partner og medstifter i selskabet Praqma, som vejleder virksomheder i agil udvikling, continuous delivery og DevOps-principper.

»Du har alle de her ikke-funktionelle krav som udvikler. Og dem har man en helt anden forståelse af, hvis det er en selv, der bliver ramt, når man ikke har en ordentlig log-besked, og der går noget galt med en funktion,« siger han til Version2.

Mærsk nedlagde supportgruppe

Når udviklere er ansvarlige for koden, mens den er i produktion, oplever de selv alle problemerne, beretter Leif Sørensen.

»Og det hjælper dem til at lave bedre kode. Kode, som er driftbar,« siger Leif Sørensen.

Leif Sørensen har tidligere arbejdet i Mærsk, hvor arbejdet dengang var fordelt mellem en udviklingsafdeling og en supportgruppe, som fik ansvaret for et release, så snart det var færdigt.

Læs også: Amazons DevOps-strategi: Udviklingshold skal kunne mættes med to pizzaer

Ved at fjerne supportafdelingen blev udviklere ansvarlige for koden, mens den var i produktion.

»Og vi satte udviklere ind til at være med til at deploye og supportere systemer, så de kunne se betydningen af at lave fornuftige logfiler og så videre. Pludselig gik det ud over dem selv, hvis det manglede, for så vidste de ikke, hvad der var gået galt,« siger Leif Sørensen.

Undgå at DevOps bliver ny silo

Hvis DevOps-strategien blandt andet skal få udviklere til at forbedre deres eget arbejde, kræver det en helhjertet implementering.

Nogle virksomheder tager i al simpelhed den eksisterende ops-gruppe og begynder at kalde den for DevOps.

»Og det er jo ikke løsningen,« understreger Leif Sørensen og fortsætter:

»Andre steder laver man en gruppe midtimellem og kalder det for DevOps. Det kan godt fungere, men det kræver ekstremt meget af den gruppe.«

Læs også: Er du obs på DevOps?

Problemet er, at man let opnår blot at skabe endnu en silo, mens man i virkeligheden prøver at nedbryde barrierer mellem drift og udvikling, fastslår Leif Sørensen.

I stedet ser man hos ledende it-virksomheder som f.eks. Facebook, at man sammensætter udviklingsteams, der er ansvarlige for koden hele vejen til produktion.

Sund fornuft

Den organisering betyder ikke, at man ikke kan have en specialgruppe, der f.eks. fokuserer på automatisering, så det er let for udviklere at slippe af med deres produkt.

»Men ideen er, at du laver nogle teams, der har DevOps-ingeniører og andre roller besat, så man kan dække det hele,« siger Leif Sørensen, der tilføjer, at det også kræver fullstack-udviklere og inddragelse af specialister efter behov.

Læs også: Startup look-alike: København opretter agil udvikler-gruppe

Mange virksomheder har længe haft gang i DevOps med både agil udvikling og automatiseret deployment. Leif Sørensen erkender også, at meget af det, som DevOps-konceptet handler om, kan beskrives som sund fornuft.

»Men vi kommer tit ud til steder, hvor de er meget, meget langt fra at arbejde på den her måde,« understreger han og fortsætter:

»Man kan sætte alle mulige buzzwords på, men i sidste ende handler det om, at man kan udvikle noget og få det ud til brugeren relativt hurtigt.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Rasmus Kaae

Tanken om at teams får feedback på deres leverancer er fantastisk motiverende. En fejl som brugeren oplever er i mange tilfælde ikke grundet i dårlig kode, men nærmere nye anvendelses måder af softwaren. Devops eller afarter heraf er en god måde at fuldende feedback loopet fra slutbruger til udvikler!

  • 2
  • 0
Carsten Poulsen

Der er argumenter, som trækker begge veje.
Oprindeligt blev udviklings- og supportafdelingerne adskilt for at give udviklerne arbejdsro og gøre projekterne mere forudsigelige.
Men det gav også afstand mellem brugerne og udviklerne: det var ikke altid, at udviklerne lavede det, som brugerne forventede!!
I et af de firmaer, jeg har været i, blev udviklingsafdelingen ligefrem kaldt "det beskyttede værksted". Folk der, havde en direkte avertion mod at komme ud til brugerne, eller blot tale i telefon med dem.
Nogle firmaer har i mange år ikke skelnet mellem udviklings- og projektafdelingerne. Det undrede mig, indtil jeg fandt ud af, at deres produkter var bedre!! Til gengæld blev projektafviklingen lidt mere usikker, men dog ikke mere end at alle var mere tilfredse; både kunder med kørende systemer, under implementering og udviklerne selv.
Mit nuværende arbejdssted, som leverer - skal vi bare kalde det mechatronics - bruger en mellemting: Vi har en driftafdeling, som tager sig af kunderne, og har en mekanisk og en elektronisk udviklingsafdeling. Driften har den primære kundekontakt, men alle har reelt kundekontakt. Oven i det har vi en 'udstationeringsordning', hvor folk på skift 'udstationeres' i driftsafdelinegn for at få erfaring gennem primær kundekontakt, som godt kan være lidt af en øjenåbner.
Så, ja, hvis det er nødvendigt at isolere af hensyn til projekters forudsigelighed, så gør det i det mindste kun i perioder.

  • 4
  • 0
Morten Sabroe Mortensen

Det er skærende, hvordan at udlægninger af verden hænder at vende rundt og som tiden går.

For 15 år siden fik siloerne et mere markant udtryk i de større it-virksomheder. Som udviklere kunne vi tigge og bede om at få indsigt i og i øvrigt analysere, hvordan at vores systemer kørte på test- og produktions-systemer, der har forskellige anvendelsemønstre, og ofte måtte vi ikke så meget som på offline-vis se simple logfiler eller få information om systemmetriker. Selv om vi lige som forklarede at det var nødvendig med feedback om både forretning og teknik. Vandtætte skodder var nødvendige, fordi så skete der ingen ulykker.

Nu kan vi så få lov til "selv at lide under dét, som vi laver". Nå, det kan vi? Det er en herlig, moderne tanke.

Som udvikler af it-systemer på tredje årti holder jeg fortsat på, at det, som jeg er med til at producere, er af en kvalitet, sådan at jeg selv vil være med til at drive det bagefter.

  • 1
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize