Produktivitet fik konsulentfirma til at fravælge Java

Niels Jørgen Bagger og Jesper Steen Møller (th.) fra virksomheden Nine, mener at nichesproget Groovy har givet produktivitetsgevinster i forhold til gammeldags Java. Men måske er situationen ikke helt så klar længere. Illustration: Søren Berg Glasius
Da konsulentfirmaet Nine skulle udvikle system til Erhvervsstyrelsen, var det Groovy, der blev valgt, for dets højere produktivitet. Men syv år senere er valget ikke helt så klart.

Da konsulentfirmaet Nine for en del år tilbage skulle skabe et system til indberetning af regnskaber for Erhvervsstyrelsen, var det unge sprog Groovy det, der blev teknologivalget. Men syv år senere er det ikke sikkert, at Nine ville vælge sproget.

Det fortæller Jesper Steen Møller og Niels Jørgen Bagger, der begge er partnere i firmaet og med på fabriksgulvet, da Version2 taler med dem på konferencen Gr8conf, der løb af stablen i København tidligere på måneden.

Groovy er en del af Java-familien, kører på Javas virtuelle maskine og har en meget høj grad af interoperabilitet med modersproget. Og Groovy er ikke noget stort sprog. I målinger over programmeringssprogs popularitet ligger det langt, langt nede på hitlisten.

Om valget af et nichemiljø siger Jesper Steen Møller:

»Det handler først og fremmest produktivitet. Groovy kan meget mere end Java, selvom det ligner Java meget. Mange kan lide sproget, fordi man har friheder og kan implementere ting, der er mere kraftfulde, og syntaksen er mere koncis end Javas lange 'boilerplate.' Samtidig kan sproget levere de ting, som man er glad for i Java – gode biblioteker, integration, stabil runtime – men det er bare i Groovy. Det hele får et ekstra ‘gear’, produktivitetsmæssigt.«

Hvad der især gjorde sproget attraktivt i sin tid, var frameworket Grails, som var et svar i JVM-verdenen på det populære Ruby on Rails-miljø til effektiv webudvikling. Det bygger på Groovys styrker, mener Jesper Steen Møller.

Sådan sælger man en nicheplatform

Nine introducerede sproget hos Erhvervsstyrelsen i 2011, til projektet ‘Regnskab 2.0,’ som handlede om indberetning af regnskaber i digital form.

»Erhvervsstyrelsen har været gennem et moderniseringsprogram, hvor vi introducerede Groovy i større skala, så det nu er det rammeværktøj, som styrelsen bygger deres arkitektur på,« fortæller Niels Jørgen Bagger.

Hvordan sælger man en nicheplatform til en kunde?

»Da vi lavede Regnskab 2.0, var systemet baseret på JVM’en, så det var ikke et kæmpe skridt. Det blev solgt på, at der var højere produktivitet i Groovy. Og så lærte vi en masse ved hjælp af proof-of-concept-projekter, i stedet for at analysere til døde,« siger Niels Jørgen Bagger.

Jesper Steen Møller supplerer:

»Dengang var der opmærksomhed på, at det ikke skulle blive et silo-monster. Og så havde systemet sprog-uafhængige snitflader udadtil. Det handlede også om, at kunden havde travlt, og der var en deadline. Svaret var: Vi har open source teknologi, som kan accelerere jeres deadline.«

Et kritisk sted for Groovy

Situationen er anderledes i dag. Groovy har ligefrem nået til et kritisk punkt, mener Jesper Steen Møller.

Det skyldes blandt andet, at Java har gennemgået en fornyelse de sidste år, med eksempelvis closures, en facilitet, Groovy havde fra starten – langt tid før Java. Groovy har faktisk været en inspiration for Javas sprogdesignere, mener de to.

Og måske har det gamle sprog løbet op på siden af de unge alternativer. Det ses for eksempel i webframeworket Spring Boot.

»Spring Boot har givet nogle af de samme produktivitetsgevinster som Grails, og i dag er Grails baseret på Spring Boot – så jo, det er interessante tider,« mener Jesper Steen Møller.

»Kotlin er også på vej som ny darling i miljøet, og inden for visse områder er Scala også stort. Der er plads til en del sprog, fordi investeringen er ikke ligeså stor, som hvis man går uden for JVM-verdenen. Men Java er i live, på en måde, som det ikke var for fire år siden.«

I dag er produktivitetsgabet mellem Java og Groovy måske ikke så stort. Det er et pendul, der svinger, mener Niels Jørgen Bagger:

»Java har ligget stille længe, og så søger man andre marker, men det gennemgående element er JVM’en. Nu har man oppet sig med Java, og så kan man begynde at kigge derover igen. Der er nu også en højere udgivelsesfrekvens på Java, som gør at det ikke virker så støvet. Men vi kigger på Micronaut og andre frameworks. Vi vandrer også væk fra backend-tunge applikationer til single page-applikationer.«

På det område er der et hav af andre frameworks, ofte skrevet i Javascript.

I værste fald: Næsten-Java

Vil I fastholde Groovy i fremtiden?

»Jeg ved ikke hvor meget Groovy, vi bruger om for eksempel tre år. Vi skal både kigge på den korte bane og holde øjet ud over horisonten. Hvordan det ser ud med Groovy om fem-ti år, det ved jeg ikke,« siger Niels Jørgen Bagger.

»Det er ikke sikkert at vi starter nye kunder op på Groovy i samme omfang. Men Groovy er stadig et godt valg, og udviklerne er glade for det.«

Og det gælder i særdeleshed når man skriver test, mener Jesper Steen Møller

»Hvis jeg skulle lave et rent Java-projekt i dag, så ville jeg insistere på at bruge Spock,« siger han, med henvisning til det Groovy-baserede testværktøj, der har basis i tankegangen om 'behavior-driven development.'

»Det er meget nemmere end Junit. Og mindre mærkeligt end Cucumber.«

Men det er ikke altid så nemt at rekruttere nye programmører i et nichesprog, når behovet opstår.

»Der er vi udfordrede,« siger Niels Jørgen Bagger.

»Vi har støvsuget markedet for de bedste Groovy-udviklere. Vi må selv lære dem op.«

Og det kan også æde noget af produktivitetsgevinsten.

»Men typisk er vores udviklere også folk, der har været mange år i branchen og har prøvet mange programmeringssprog.«

Meget af det handler om at få Java-unoderne ud af programmørerne. Og det er nok ikke det store problem, mener Jesper Steen Møller, for Groovys syntaks tillader det meste Java-kode:

»I værste fald kan de bare skrive ‘næsten-Java’.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (13)
Jesper S. Møller

Jeg refererede til brug af nogle af den boilerplate-kode som en del Java-udviklere har taget til sig fordi det blev beskrevet som 'best practice' for ti år siden: Overdreven brug af factories, singletons, komplicerede klassehierarkier, m.m. er i moderne applikationsframeworks (f.eks. Grails, Spring, etc.) erstattet af bedre teknikker:
- IoC i stedte for tunge factorystrukturer
- Tests med mocks i stedet for "alt skal kaldes igennem interfaces"-regler
- Frameworkstyret livscyklus i stedet for singletons
- Deklarative styring af sikkerhed, transaktioner m.v. (med gode defaults) i stedet for håndkodet logik

Generelt: Brug nu de frameworks, der findes, i stedet for at spilde tid på at opfinde dine egne frameworks (for at være "teknologiuafhængig").

Og så er der også en masse "gammel-Java"-unoder derude, fordi folk har siddet fast i Java 6 eller før: Der var en gang hvor det var OK at bruge 4-5 linjer kode på at filtrere udvalgte elementer over i en anden.

List<Dims> visseDimser = new ArrayList<>();  
for (Dims d : alleDimser) {  
  if (erUdvalgt(d)) {  
    visseDimser.add(d);  
  }  
}  
return visseDimser;

I 'idiomatisk' Groovy hedder det bare:

return alleDimser.findAll { d -> erUdvalgt(d) }

Og det er jo både nemmere at læse og skrive.

Anders Djursaa

Uden at forholde sig til de finere detaljer mellem Groovy og Java vil jeg påstå at det er meget vigtigt at vælge en teknologi som passer til applikationens formodede livslængde. I dette tilfælde er der tale om en funktionalitet som må formodes at skulle virke mere eller mindre uændret i mange år og det er derfor vigtigt at vælge teknologi som må formodes at være så langlivet at programmeringsssproget ikke i sig selv giver anledning til omskriving.
Det er selvfølgelig svært at spå - men hvis man vælger et nichesprog/teknologi så øges risikoen.
Den konkrete sag er vel ikke ligefrem nogen ulykke - men synes dog at indeholde en erfaring som man bør tage ved lære af.

Jesper S. Møller

Jeg er principielt enig i din betragtning om forventet levetid - dog med et tvist:

I dette tilfælde er der tale om en funktionalitet som må formodes at skulle virke mere eller mindre uændret i mange år

Tværtimod - administrative systemer må forventes at skulle ændres løbende, fordi der hele tiden kommer nye krav:

  1. Lovændringer og nye love
  2. Nye tekniske integrationer (omkringliggende systemer, fællesoffentlige systemer, etc.)
  3. Ændret administrativ praksis
  4. Krav til øget/ændret brugervenlighed

Det gør, at det er nødvendigt holde systemernes udviklingsmuligheder i live. Vælger man for konservativt, fordi man forventer kravstabilitet over lang tid, risikerer man også at reducere sine manøvremuligheder.

Det er selvfølgelig svært at spå - men hvis man vælger et nichesprog/teknologi så øges risikoen.

Og hvis man vælger et sprog, ingen gider røre med en ildtang, øges risikoen for at man får et system man ikke tør/har råd til at ændre. Det er selvfølgelig også svært at spå om...

I begge tilfælde er man bedre hjulpet af at have valgt open source -- så har man i den sidste ende altid muligheden for at komme videre.

Frank Vilhelmsen

Enig, men applikationens livslængde er blot en faktor af mange. For eksempel kunne time to market være en væsentlig faktor, måske kunne den mest betydningsfulde faktor være kreativitet omkring et nyt produkt og her synes jeg det bliver spændende, idet at de forskellige teknologer ofte har forskellige tilgange til problemløsning. Modulus 11 check fx kan nogle få til at fylde en A4 side mens man i Clojure kan nøjes med

(mod (reduce + (map * [crp] [4327654321])) 11)

:-)

Anders Djursaa

Udsagnet "Mere eller mindre uændret" skal ses fra helikopterperspektivet.
Dine detaljeringer - som jeg er enig i - understreger at det samlede ressourceforbrug i en appplikations livslængde og dermed vedligeholdelsesvenligheden (i bredeste forstand) er langt vigtigere end om der er en eller anden gevist i den initielle udvikling.
Derimod er "Time to market" ikke noget reelt problem for offentlige løsninger
Risikoen for at ende i en blindgyde minimeres ved at vælge noget der er meget udbredt og meget gerne standardiseret. Der er meget open source som netop lever op til disse krav.

Jesper S. Møller

Derimod er "Time to market" ikke noget reelt problem for offentlige løsninger

Der fik jeg så lige min kaffe galt i halsen!
Det er da et ENORMT tab for samfundet når offentlige it-systemer halter efter f.eks. lovgivningen, reelle brugerbehov, etc. Mange systemer er så længe undervejs at det giver nogle flaskehalse, eller inviterer til både administrative og lovgivningsmæssige hovsa-løsninger.

Jeg kunne f.eks. nævne: https://www.version2.dk/artikel/forlig-kmd-skal-betale-100-mio-kroner-ko...
(nu er der selvfølgelig meget andet end teknik, der påvirker time-to-market - og ofte grelt meget, f.eks. udbudsprocessen, manglende forretningsviden, og uheldige "makroarkitektur"-beslutninger)

Risikoen for at ende i en blindgyde minimeres ved at vælge noget der er meget udbredt og meget gerne standardiseret.

Jeg er nysgerrig - hvad ville du kalde et "standardiseret" applikationsframework?

Anders Djursaa

Udsagnet (at time to market ikke betyder noget) skal selvfølgelig læses i lyset af om man vælger det hurtigste programmeringssprog (at udvikle i) eller det mest langtidsholdbare og vedligeholdelsesvenlige :-)
Jeg tror det bliver svært at finde offentlige IT skandaler hvor programmeringshastighed og "smarthed" har haft nogen udslagsgivende indflydelse.
For så vidt offentlige IT skandaler så er årsagen vist mere en anden. Se mit bud på dette på https://www.linkedin.com/pulse/public-scandals-founded-during-contract-p...

Jesper S. Møller

Jeg tror det bliver svært at finde offentlige IT skandaler hvor programmeringshastighed og "smarthed" har haft nogen udslagsgivende indflydelse.

Jeg vil mene at de offentlige it-success'er, jeg har bidraget til, har være kendetegnet ved at vi har kunnet kommet hurtigt i gang, og derved tidligt kunne se hvad der virkede, og hvad der ikke gjorde.

+1 til at kontraktformer ofte kommer i vejen for offentlig it. Men altså ikke altid.

Henrik Hansen

Enig, men applikationens livslængde er blot en faktor af mange.

Jeg mener at en langt vigtigere faktor for offentlige IT-projekter er, at det både er nemt og muligt at finde andre leverandører, der både kan og vil overtage projekter programmeret i div. uortodokse programmeringssprog.

Jeg er selv kæmpe fan af både Clojure og Rich Hickey, men jeg ville da aldrig anbefale mine kunder at implementere udviklingsprojekter i Clojure, indtil Clojure bliver et mere mainstream programmeringssprog!?!

Hvor mange Clojure-programmører kan Visma, NNIT, Tieto, Trifork, KMD , DXC og de andre standard SKI-leverandører skaffe, hvis min kunde ikke gider have mig som leverandør på deres projekt længere?

Dette er faktisk ikke en kritik rettet mod Nine - for de har sådan set bare gjort, hvad konsulentfirmaer gør, altid har gjort og hele tiden har levet af. Regnskab 2.0 ser også ud til at være et meget velfungerende system.

Hvad Erhvervsstyrelsen der imod har gang i, fatter jeg ikke en brik af.

Hvad skal det offentlige Danmark med endeløse SKI-indkøbsaftaler, standardiserede platforme hos Statens IT, og hvorfor bruger Digitaliseringsstyrelsen mandeår på at udvikle guides og retningslinjer for offentlig IT, når en Digitaliserings- eller IT-chef hos Erhversstyrelsen bare kan vælge at kortslutte hele baduljen, i sit eget lille prestigeprojekt?

Jesper S. Møller

Jeg er selv kæmpe fan af både Clojure og Rich Hickey, men jeg ville da aldrig anbefale mine kunder at implementere udviklingsprojekter i Clojure, indtil Clojure bliver et mere mainstream programmeringssprog!?!

Nu handlede interviewet først og fremmest om Groovy, men ok, lad os snakke Clojure, så:

Hvor mange Clojure-programmører kan Visma, NNIT, Tieto, Trifork, KMD , DXC og de andre standard SKI-leverandører skaffe, hvis min kunde ikke gider have mig som leverandør på deres projekt længere?


Der er nok lidt flere end du tror, og ikke mindst bliver nyuddannede heldigvis også udsat for en mere blandet palet end C og Java.

Lige nøjagtig Clojure har fundet udbredelse hos f.eks. Implementeringscenteret for Ejendomsvurdering (under Skatteministeriet) men også hos f.eks. YouSee.

Hvad skal det offentlige Danmark med endeløse SKI-indkøbsaftaler, standardiserede platforme hos Statens IT, og hvorfor bruger Digitaliseringsstyrelsen mandeår på at udvikle guides og retningslinjer for offentlig IT, når en Digitaliserings- eller IT-chef hos Erhversstyrelsen bare kan vælge at kortslutte hele baduljen, i sit eget lille prestigeprojekt?

Øh - SKI forholder sig overhovedet ikke til programmeringssprog.

Jeg kan ikke udtale mig om udbredelsen af Statens ITs applikationsservice- og driftstjenester, men i deres øvrige servicemodeller står kunden for applikationslaget.

Digitaliseringsstyrelsen arbejder i øvrigt tæt sammen med Erhvervsstyrelsen, f.eks. om den fællesoffentlige digitaliseringsstrategi. Programmeringssprog er slet ikke strategi, det er allerhøjest taktik.
Det er et strategisk valg at anbefale at nedbryde siloerne, skabe åbne snitflader og muliggøre fælles brugerrejser på tværs af myndigheder.
Det er et taktisk og decentralt valg hvordan disse mål indfris.

Jeg kan selvfølgelig ikke udtale mig på Erhvervsstyrelsens vegne, men jeg kan slet ikke se at der skulle være tale om nogen kortslutning dér.
Måske emne for en opfølgende artikel, Tania?

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder