– AI er den nye outsourcingen
Jørgen i kode24 ser likheter mellom hvordan selskaper bruker AI i dag, og hvordan de brukte outsourcing før.
- Security and privacy risks
- Hidden costs
- Lack of domain expertise
- Communication barriers
- Lack of experience with tools and technologies
Heisann! Satt opp en liste over potensielle farer ved å integrere for mye AI i tech-stacken, jeg.
Nei vent, nå surrer jeg – dette er jo én av ørten lister over problemene ved outsourcing.
Høres likt ut, eller?
Er AI i ferd med å bli den nye outsourcingen?
Mere gass!
Hva gjør man når man er sjef i et tech-selskap og vil ha mer fart – MERE GASS!?
- Snakker man med de ansatte og legger en plan? Neida, neida, neida.
- Senker man ambisjonene og fokuserer på kjerneoppgaver? Neida, neida, neida.
- Vurderer man rydding i legacy-kode, slik at man kan få mere fart på sikt? Neida, neida, neida.
I 2025 vurderer man kanskje AI. Men på 2010-tallet var det outsourcing som gjaldt!
En telefon til et outsourcingsbyrå, og vips satt man i en videosamtale med et flunkanes nytt team. På andre siden av verden.
Et team som skulle ha tilgang til kodebasen din, task-systemet ditt, Github-prosjektet ditt, og ikke minst koden din.
Hva kunne gå galt?
Fullverdige team-medlemmer
Som du kanskje skjønner, har jeg opplevd dette før.
For ti år siden var det nettopp denne avgjørelsen ledelsen i firmaet jeg jobbet for da, tok. Uka etter ble staben utvidet med en haug med utviklere fra Sri Lanka.
I starten syntes vi det var stas å få ekstra utviklere i selskapet. Og gikk i gang med grubling på hvordan vi skulle få til et godt samarbeid.
Vi landet på at det beste var å integrere Sri Lanka-utviklerne inn i hvert enkelt team. Det betød at de skulle være tilstede på hvert morgenmøte, og ideelt sett alle andre møter også.
Fullverdige team-medlemmer. På andre enden av kloden.
De sier alltid ja. Uansett om de har forstått oppgaven eller ikke.
De sier alltid ja
Det tok ikke lang tid før problemene begynte å tårne seg opp.
Tidsforskjellen var én ting. De var alltid på jobb før oss, eller ute av kontoret på ettermiddagen vår. Morgenmøte var lunsjmøte for dem. Ettermiddagsmøte betød at de måtte jobbe overtid.
I starten følte vi at møtene gikk veldig bra, de ga inntrykk av å forstå alt, også hvordan problemene skulle løses. Men det viste seg å være for godt til å være sant.
"De sier alltid ja", bemerket en kollega seg. "Uansett om de har forstått oppgaven eller ikke".
Etterhvert skjønte vi at arbeidsflyten deres bestod i å si ja til hva som helst, så ha et eget møte hvor de prøvde å forstå hva i huleste vi ga dem i oppgave på morgenmøtet.
Resten av dagen ga de ingen lyd fra seg mens de kodet i vei på en løsning. Dagen etterpå beklaget de eventuelle innsigelser vi hadde, og fortsatte å si ja.
To kodebaser
Etterhvert som vi prøvde å samarbeide, oppdaget vi at vi egentlig motarbeidet hverandre.
Før vi visste ordet av det satt vi på to kodebaser i én. Den ene delen bestod av den vi forstod, den andre delen bestod av gigantiske kodechunks i pull requests signert våre team-medlemmer i Sri Lanka.
Kvaliteten var ikke god nok. Det visste vi. Ofte bestod koden av klipp og lim fra StackOverflow, ymse nettsider, og gammel kode fra andre steder i kodebasen vi allerede hadde merket som legacy.
Og det var ikke rart at ting gikk galt. Oppdraget vi hadde gitt de stakars utviklerne i Sri Lanka var ikke realistisk. De var ikke ræva utviklere, tvert i mot var de flinke folk som stod på! Men de skulle forstå hele kodebasen vår, hva kundene våre ville ha, og fikse problemer vi ikke klarte å forstå selv, på rekordtid.
For å være greie merget vi ting inn, og prøvde å være litt mindre kritisk. Oppdraget fra ledelsen var mere fart, tross alt!
Den kjipeste koden
Vi innså etterhvert at vi ikke kunne jobbe sammen på samme kode.
Så da ga vi den gamle koden til utviklerne i Sri Lanka. Og med den gamle koden, mener jeg koden som kjørte i produksjon. Den alle kundene våre brukte. Den som gjorde at vi hadde en jobb.
Og det funket, føltes det som. Bugs ble fikset, nye kunder ble satt i produksjon.
Vi i Norge jobba på gøyale sideprosjekter hvor vi eksperimenterte med NoSQL, nye rammeverk som Angular, og drømte oss bort i ny funksjonalitet.
Gjett hvem som satt igjen med en rotete legacy-kodebase med sikkerhetshull?
Sikkerhets-krise
Men, så begynte vi å innse nedsiden av moroa vår:
Ingen av prosjektene våre ble integrert tilbake i hovedapplikasjon. Både fordi de ikke var kompatible, og fordi ingen av oss kjente til legacy-kodebasen lenger.
Vi ble så desperate at vi til og med satt i gang å skrive om legacy-kodebasen fra scratch, som selvfølgelig ikke funka.
Så kom det beskjed fra ledelsen om at vi måtte kutte i outsourcing.
Gjett hvem som satt igjen med en rotete legacy-kodebase med sikkerhetshull?
Det var oss, det.
Gjett hvem som sa opp?
Jo, det var oss, det.
AI vs. outsourcing
Outsourcing har kanskje gått litt av moten. Jeg hører hvert fall ikke så mye snakk om det lenger. Og det er nok absolutt noen der ute som lykkes med outsourcing. Akkurat som det er mange som lykkes med AI i dag.
Men mange mislykkes, og det kan være greit å ta lærdom av alle de som feilet med outsourcing for ti år siden.
For akkurat som med outsourcing lar vi nå eksterne utviklere – i form av AI – bidra til kodebasen vår. Vi risikerer å miste kontroll over kvalitet, og hvor koden kommer fra. Og oversikt over vårt eget produkt. Mens AI-en smiler og sier ja til alt.
Men hva gjør du den dagen AI ikke kan hjelpe deg?
Da kan legacy-koden din bli ganske kostbar.
Spesielt hvis du aldri engang har sett din egen legacy-kode.
Da blir AI den nye outsourcing.
