Fagperspektiv

Python og Django leverte varene

I utviklingsprosjekter der de som skal bruke systemet ikke har grunnlag for å vite hva de skal etterspørre, kan veien være viktigere enn målet når teknologi skal velges.

Ved teknologivalg er det viktig å velge ut fra behovene det konkrete prosjektet står overfor. Programmeringsspråk og rammeverk kan påvirke mer enn drift, vedlikeholdbarhet og tilgang på kompetanse. Det kan også legge føringer for fremdriften i prosjektet og kvalitet på tilbakemeldinger fra brukerne

- Det spesielle med dette prosjektet var at DNV utviklet prosjektet for en annen organisasjon, slik at avstanden til brukerne var ekstra lang. Det økte viktigheten av å avstemme faktisk utviklet funksjonalitet med behov jevnlig, sier Anders Haugeto, som ledet prosjektet hos Iterate.

Et annet aspekt var at det er vanskelig å ha ønsker om noe man ikke vet hva er. Gode demoer med faktisk funksjonalitet, gir høyere kvalitet på tilbakemeldingene fra brukerne.

- Mye av funksjonaliteten var helt ny for brukerne. De hadde ikke grunnlag for å vite alt de ville ha før de fikk se forslag. Totalt la disse behovene føringer for prosjektet i form av behov for fleksibilitet og evne til endring, sier han.

Python og Django

Valget falt på det tolkede programmeringsspråket Python, og webrammeverket Django. Sistnevnte kunne levere masse funksjonalitet rett ut av boksen, mens Python banet vei for å snu seg ekstremt raskt.

Fordelen med et tolket språk er at alt – inklusive utviklingsmiljø – er live når man testkjører programmet. Man slipper kompilering ved endringer, og kan i ytterste konsekvens gjøre forandringer over bordet mens man demonstrerer. I et prosjekt der veien i stor grad blir til mens man går, viste Python seg å være et svært riktig valg.

Django leverte på sin side automatisk genererte administrasjonsgrensesnitt som var tilstrekkelige til alt fra å være grunnlag for diskusjon om funksjonalitet til å være grensesnitt som faktisk ble brukt.

- Python og Django gjorde det mulig for oss å raskt få opp basisfunksjonalitet, slik at den videre utviklingen kunne baseres på tilbakemeldinger og endringsønsker. I dette tilfellet var selve utviklingsprosjektet den viktigste føringen for teknologivalget, sier han.

- Teknologien underbygde prosjektmodellen som kanskje var den viktigste suksessfaktoren.

Mer enn nok ytelse

Et ankepunkt for tolkende programmeringsspråk og innholdsrike rammeverk kan være ytelsen på løsningen. Det krever mer kraft å tolke fortløpende enn å kjøre kompilert kode. Men det er ikke alle som trenger den samme ytelsen som Altinn på store leveringsdager. Langt flere kunne ha valgt løsninger der man får mer gratis, på bekostning av ekstremytelse.

- Man må se på de faktiske behovene kunden har og ytelseskravene løsningen faktisk har. For DNV, og jeg vil tro for mange andre vanlige norske bedrifter eller offentlige virksomheter, holder dette rammeverket i lange baner, sier Haugeto.

- Det er lett å ta teknologivalg som er overkill av gammel vane. Og gå glipp av enklere muligheter som sparer både innsats og kostnader. Dessuten er det ikke gitt at man får god ytelse i et Java-prosjekt heller. “Enterprise”-prosjekter kan stå i fare for å drukne i mange lag med abstraksjon. Både systemet og utviklingsprosessen blir tregere av slikt, avslutter Haugeto.