Bekk er et norsk konsulentselskap med over 470 ansatte. Samtidig klarer Bekk å være noe litt annet enn de mange andre konsulentselskapene her til lands - i alle fall i våre øyne.
De har ivrige bloggere, blant annet i React-faggruppa som leverer ForrigeUke-innlegg til kode24 hver bidige uke, og Bekk stakk av med kode24s Årets Bidragsyter-prisen. De lanserer enorme julekalendere. De har en nettside med en diger WebGL-animasjon på toppen.
Alt dette gir Bekk en aura av å være i forkant med nye teknologier - igjen, i alle fall i våre øyne. Vi ville derfor høre hva de har starta med og slutta med i året som gikk, og ikke minst hva tror om året som kommer.
Bekk er derfor nestemann ut i vår serie Kodeåret, og selv om svarene skal komme fra fagmiljøet som helhet, er de festa på skjermen av fagsjefene Andreas Heim og Erik Wendel.
Hvilke teknologier begynte dere å bruke i 2019? ✨
Teknologiåret 2019 preges av at teknologier som allerede har eksistert en stund vokser i bruk, heller enn helt nye teknologier kommer inn og revolusjonerer bransjen.
Overordnet opplever vi at politikk, organisering og forståelse for softwareutvikling preger utviklingsfarten mye mer enn teknologi og rammeverk.
For veldig mange har nok Kotlin blitt et nytt tilskudd i verktøykassa i løpet av 2019, selv om flere prosjekter har brukt språket en stund allerede. Ktor er et nytt og spennende alternativ til Spring, som foreløpig er langt fra like modent, men spiller godt inn i et Kotlin-miljø.
GitHub Actions fikk raskt fotfeste som bygg- og automatiseringsverktøy, og forsøker med dette å ta et jafs av kaka fra CircleCI, Travis CI og Bitbucket.
«React forblir de-facto standardvalg på frontend, men Elm vinner stadig mer terreng.»
React Native er ikke nytt for oss i 2019, men vi registrerer at det fortsetter å fungere bra for oss. Utviklingsfarten er høy og utvikleropplevelsen god. I år har flere prosjekter tatt i bruk CodePush, som gir teamet muligheten til å faktisk levere kontinuerlig, rette feil umiddelbart og dermed redusere up-front testing gjennom å heller teste i produksjon.
React forblir de-facto standardvalg på frontend, men Elm vinner stadig mer terreng da kodebaser skrevet med det er lett å vedlikeholde, og vi ser at nye utviklere onboardes raskt.
En gledelig utvikling de siste årene, som har fortsatt i 2019, er at utviklingsteamene i stadig større grad overtar ansvaret for driften av sine egne løsninger. Heller enn store overleveringer og up-front testing, er leveransene små og hyppige, og teamet kan selv kontinuerlig justere retning for produktet og selv ta ansvar for kvaliteten.
Dette henger sammen med, og nærmest forutsetter, en annen gledelig utvikling: nemlig at teamet besitter både designkompetanse, forretningskompetanse og beslutningmyndighet til å beslutte hvordan de best når sine mål (tverrfaglige og autonome team).
Hvilke teknologier slutta dere å bruke i 2019? 💩
Dette er noe vi har sagt i mange år, men utypet JavaScript er i 2019 definitivt ute i kulden til fordel for TypeScript eller mer sofistikerte språk som Elm.
Nå begynner selv late adopters å ta i bruk TypeScript, og stadig flere oppdager gleden med gode typesystemer som man finner i Elm, F#, Haskell eller lignende språk.
Flere prosjekter har sagt farvel til Redux i år. Denne, eller lignende løsninger for tilstandshåndtering i webapplikasjoner, blir mindre aktuelle etterhvert som React Hooks blir mer utbredt. Dette er i tråd med utviklingen vi har sett de siste årene, hvor man shopper mer rundt etter optimale løsninger på konkrete problemer og setter sammen sin egen pakke av biblioteker, heller enn “one size fits all”-løsninger.
Sbanken har prøvd å bli kvitt jQuery i fire år
- Mystisk nok klarte vi ikke å bli kvitt kakerlakken i år, heller.
På mobilsiden opplever vi at React Native har utkonkurrert native mobilteknologi til vanlige forretningsapplikasjoner. Skal du lage den nye Snapchat med fancy interaksjon, eller et spill som trenger ekstrem ytelse, er det fortsatt native som gjelder. Til vanlige applikasjoner, som de fleste i vår bransje jobber med, er React Native et brennaktuelt valg.
Du slipper unna med én kodebase fremfor to. Med Fast Refresh er feedbackloopen langt kortere. Du kan deploye til produksjon når du vil med CodePush. Nye utviklere kan onboardes relativt lett med litt JavaScript- og React-kompetanse i ryggsekken, og behovet for nativekompetanse er svært begrenset.
Hvilke teknologier antar dere å begynne å bruke i 2020? 🔮
Vi ser stor interesse i markedet for utrulling til offentlig sky, da særlig hos aktører som lenge har sittet på gjerdet. Dette er gode nyheter, både på grunn av økt produktivitet og at utviklerne blir mer fornøyde! Vi håper denne trenden fortsetter og at 2020 blir året der “alle” går til offentlig sky.
Neste år bør også være året der man skrur av Jenkins 2 og bytter til CircleCI, endelig pensjonerer det siste Subversion-repoet sitt til fordel for BitBucket eller GitHub, og tenker på å flytte monitoreringsverktøyene sine til skyen.
«Vi håper at ikke alle bare kaster seg på Kubernetes-bølgen fordi “alle andre” gjør det.»
På backendsiden så er det ingen tvil om at Kubernetes er det store. Det blir tatt i bruk i stor skala, både i intern sky og på offentlig sky. For store aktører som ønsker å bygge plattform, så er Kubernetes det som stort sett blir valgt.
Vi håper derimot at ikke alle bare kaster seg på Kubernetes-bølgen fordi “alle andre” gjør det, men at man gjør en behovsanalyse og vurderer om man faktisk trenger all fleksibiliteten Kubernetes tilbyr. Kubernetes må fortsatt driftes, har en til tider kronglete konfig, og passer nok best for mer modne team. Vi håper at flere vil ta i bruk tjenester på et høyere abstraksjonsnivå, som gir utviklingen enda større fart.
Her stiller gamle travere som Heroku sterkt, men de store skyleverandørene har også liknende NoOps-tjenester som for eksempel Google Cloud Run, Amazon Elastic Container Service og Azure App Service.
Om dere bare skulle lært dere én ny teknologi for å bli klare for 2020, hvilken ville det vært? 💡
Folks krav til brukervennlighet, ytelse og funksjonalitet i nye IT-løsninger bare øker og øker. For å lykkes som utvikler i en slik tid, tror vi at man trenger et bredere sett med kompetanse enn tidligere.
Den best tilpassede utvikleren mestrer både frontend- og backendutvikling, er like fingernem med CSS-animasjoner som databasetuning og tar det som en selvfølge at det er utvikleren selv som skal drifte løsningen i produksjon.
Aller helst har man et basis av kompetanse innen UX og skjermdesign. Gjerne også et snev av forretningsforståelse for hvorfor og hvordan det man lager vil skape verdi for brukerne.
Vi vil derfor oppfordre til å ta en titt utenfor sitt vante fagområde. Bygg heller kompetanse på noe nytt, heller enn å lære seg enda et språk som ligner veldig på det man kan fra før!
- Lær deg SwiftUI og Jetpack Compose!
Shortcut om 2020. - React Native er fullstendig på vei ut av radaren vår.
Hva tror dere blir bransjens største utfordringer i 2020? 🔥
En av den norske IT-bransjens største utfordringer i 2020 er at det fortsatt kastes enorme pengesummer på gigantiske, offentlige prosjekter. Når skal det offentlige klare å utnytte kompetansen som bor i bransjen og ta igjen digitaliseringsforspranget til nasjoner som England og Estland?
Vi tror at flere og flere selskaper vil få utfordringer når de tar i bruk offentlig sky og mikrotjenestearkitektur uten å endre tankegangen rundt systemutvikling! Mange er fortsatt mentalt låst i gamle utviklings-, test- og utrullingsregimer, uten helt å se hvordan utrulling til offentlig sky og mikrotjenester kan og bør endre måten man jobber på.
Vi spår også at mange arbeidsgivere kommer til å slite med å beholde flinke utviklere. Ved mange arbeidsplasser er det nå en trend at utviklerne får større påvirkningsmulighet i sin egen hverdag, både på det tekniske, men også på produkt og metodikk. Når arbeidstakerne har mulighet til å velge blant disse arbeidsgiverne, så vil det da bli mye vanskeligere for mindre fremoverlente arbeidsgivere å tiltrekke seg flinke hoder.
«Vi spår også at mange arbeidsgivere kommer til å slite med å beholde flinke utviklere.»
Vi ser også at mange i bransjen sliter med å gjennomføre endringen fra prosjektarbeid til produktarbeid. Utfordringene vi ser spenner fra hvordan man klarer å dele opp organisasjonen i fornuftige team, til hvordan man prioriterer teknisk gjeld mot nyvinninger på produktsiden. Er man enda mer fremoverlent så spår vi at inndelingen i autonome team med egne mål som ikke nødvendigvis er justert mot organisasjonens mål også kan skape hodebry, både organisatorisk og teknisk.
For offentlige aktører som er drevet av politiske planer kan det bli svært smertefullt å jobbe med smidige, autonome team, hvis man ikke har gjort grunnarbeidet og satt gode mål for organisasjonen på forhånd.