Advarer mot cowboy-tilstander: Data-scientister må skrive kode som er klar til produksjon

Bedrifter med data science-ambisjoner har ofte vansker med å komme fra proof-of-concept-fasen til det punktet hvor modellene er i produksjon. En av de sentrale utfordringene som må løses, er å styrke de data-profesjonelles evne til å levere produksjonsklar kode.

Dette er budskapet fra Laurits Søgaard Nielsen, som for tiden er frilans-konsulent og tidligere har vært kontorsjef hos det danske skattevesenet samt senior manager hos Deloitte med fokus på avansert analyse (advanced analytics).

– Data-scientists kommer vanligvis fra en matematisk eller økonomisk bakgrunn eller kanskje med en bakgrunn som biostatistiker eller fysiker, forklarer han. – Og når de kommer fra denne bakgrunnen, har de ikke lært å programmere slik en datamatiker eller en datalog lærer det. Håndverket i det å kunne kode – og å kode hensiktsmessig – er de vanligvis ikke gode til. Og når du skal utvikle noe som skal settes i produksjon, kan du ikke skrive søppelkode.

En typisk data scientist er også ung, og dermed som regel også nyutdannet, poengterer Laurits Søgaard Nielsen.

– De kommer rett fra universitetet, vil gjerne jobbe med data science, og har ikke peiling på å utvikle i en enterprise-kontekst. Og det gir en masse utfordringer, sier han.

– De har erfaringer med å lage hack-ish-løsninger. De henter en Python-pakke her og en R-pakke der, og så smekker de alt dette sammen – og slikt kan du ikke sette i produksjon.

• Utviklerintervjuet: Tror kampen mellom JavaScript-rammeverkene snart er over

Enkle grep

Å være i stand til å levere produksjonsklar kode innebærer ikke at data-scientister skal være rene programvareutviklere, understreker Laurits Søgaard Nielsen. De må ha både kreativitet og matematisk samt statistisk forståelse for å utføre jobben sin. Og de trenger også å kunne samspille med for eksempel programvareutviklere, maskinlærings-ingeniører eller dataingeniører.

Men du kan komme langt med enkle grep, mener Laurits Søgaard Nielsen.

– Det er ikke tvil om at hvis du kan heve det kodemessige nivået lite grann for en data scientist, kan du komme skikkelig langt med tanke på å kunne skrive produksjonsklar kode, sier han.

– Det dreier seg om helt enkle ting som å bruke versjonskontroll, eller kunne finne ut av å skrive unit-tester til en forretningsregel som er kodet til en egenskap. Disse enkle arbeidsrutinene løser veldig mange problemer. Hvis det i tillegg benyttes et standard framework som er egnet til data science til å skrive kode i, så er du nesten der hvor du må være.

Tester krever struktur

Nettopp evnen til å skrive tester er et viktig skritt for å øke kvaliteten av utviklingsarbeidet sitt, mener Laurits Søgaard Nielsen. Og det har du som regel ikke lært hvis du kommer inn med en bakgrunn i økonomi eller fysikk.

– Egenskaper som springer ut av harde forretningsregler, er testbare. Og det bør skrives unit-tester til koden som beregner dem, påpeker Laurits Søgaard Nielsen.

• Lær mer om unit-testing: Slik skriver du enhetstester

– Den matematiske modellen som du trener, er det ikke noen særlig vits i å for eksempel funksjonsteste. Men du kan foreta en aksepttest av de resultatene du får ut, for å se om de gir mening for brukeren. Og til slutt må resultatet til modellen omsettes til en forretningskontekst – for eksempel hvordan en modellscore mellom 0 og 1 omsettes til eksempelvis rød, gul eller grønn. Denne delen av koden bør også testes. Og det krever at du har en god struktur på den måten som du utvikler på. Har du ikke det, blir det veldig vanskelig å levere høy kvalitet.

Ville vesten

I dag er det til dels cowboytilstander når det gjelder måten mange data science-prosjekter gjennomføres på, mener Laurits Søgaard Nielsen. Han anbefaler at struktur og frameworks tas på alvor fra starten – også selv om det bare skal lages et proof-of-concept.

– Jeg er en stor tilhenger av å utvikle analytiske modeller reproduserbart. Kort fortalt betyr det at det skal være en veldefinert flow fra datauttrekk til ferdigtrenet modell. Dette gjør det nemlig mye enklere å bytte datakilder og senere gjentrene eller forklare modellen, sier han.

– Når du lager en analytisk modell, skaper du en bit programvare som ut fra data lager en metamodell av dataene dine. Når du gjør dette, er koden viktig, men enda viktigere er treningsdataene dine. Og hvis ikke du har kontroll over hvordan treningsdataene har blitt «renset» (wranglet) eller endret underveis, har du et enormt problem. For da har du en modell som ikke kan forklares, som du ikke kan replikere, og som du ikke kan gjentrene.

• De er Norges aller fremste konsulenter. Her deler de sine beste tips for å lykkes

Ikke bruk bare en data-scientist

Når jobben med Proof of Concept ikke kommer videre, er det naturligvis ikke bare på grunn av kompetansen hos data-scientisten. En annen utfordring ligger i å benytte en svært smidig utviklingsprosess, mener Laurits Søgaard Nielsen.

– Mange større bedrifter er vant til å kjøre utviklingen etter en fossefallsmodell (plandrevet modell). Allerede her ligger det problemer. Data-science er for meg en utviklingsprosess som er langt mer smidig – helt over i Kanban. Du kan gjerne ha et klart mål om hva du vil oppnå, men veien dit kan være veldig uklar. Det innebærer at utviklingen av en analytisk modell ikke passer inn i en fossefallsmodell, og er vanskelig å legge inn i en Scrum Sprint.

I tillegg kommer det at data science-rollen er for bred, og at mange bedrifter derfor ikke er klar over hvor mange kompetanser en data scientist rent faktisk dekker.

– Begrepet data science har også blitt veldig utvannet, og brukes i dag om mange forskjellige data-disipliner, sier Laurits Søgaard Nielsen.

– Data science-enhjørninger som både kan gjennomføre ETL-delen, kan snakke med bedriften, kan kode den perfekte modellen og sette den i produksjon som en programvareutvikler, finnes stort sett ikke. Og det er den første erkjennelsen som bedrifter bør ha når de gjerne vil hyre en data scientist: Du kan ikke bare bruke en data-scientist.

– Du må også bruke noen som har kontroll på å være bindeledd til bedriften: noen som kan lage gode ETL-prosesser til data, og de må bruke noen som er dyktige til å lage programvare som kan hjelpe til med at koden kommer i produksjon. Og siden analytiske modeller ofte endrer en forretningsprosess veldig grunnleggende, er det også bruk for en god porsjon endringsledelse og forståelse for endringsprosesser.

• Data science: – Data brukes i stadig mer avanserte IT-løsninger, men det er urovekkende liten fokus på kvaliteten

Artikkelen har tidligere vært publisert på Datatech. Datatech tilhører Teknologiens Mediehus.