Ola Bini, selvudnævnt sprog-geek og taler på GOTO 2013, efterlyser mere præcise og transparente programmeringssprog samt større professionalisme i udviklingsvirksomhederne.
Egentlig synes Ola Bini, at alle eksisterende programmeringssprog er noget møg. Og det er grunden til, at han selv har eksperimenteret med udvikling af indtil videre to nye sprog, Ioke og Seph.
– Vi er stadig i ”the dark ages of programming”. Det kræver en urimelig stor indsats at udvikle selv forholdsvist enkle løsninger. Og den måde, vi kommunikerer med vores kolleger på, er helt forskellig fra den kode, vi skriver. At få computeren til at gøre noget bestemt er kun en lille del af programmeringen. Kommunikationen med kollegerne i teamet, med domæneeksperterne og alle andre involverede i et projekt er et mindst lige så vigtigt aspekt, siger han og tilføjer:
– Ordet ”kode” afslører i sig selv problemet. Kode er noget, man bruger, for at andre ikke kan forstå, hvad man skriver!
Kompleksitetssammenbrud
For Ola Bini er programmeringssproget udviklerens suverænt vigtigste værktøj. Så udvikling af sprogene i retning af meget større transparens og præcision er et vigtigt element som værn mod den kompleksitet, der i dag præger løsningerne – og selv små trinvise forbedringer af sprogene har en relativt stor positiv effekt på gennemsigtigheden og produktiviteten.
– Vores branche skal til at tage sig alvorligt sammen, da vi efter min mening er på vej mod et ”complexity crash”. De løsninger, vi udvikler i dag, er så komplekse, at vi snart ikke vil have den fjerneste idé om, hvordan de hænger sammen. Hvis vi ikke snart får dem under kontrol, får vi et crash og vil blive nødt til at bygge det hele op fra grunden igen, siger han.
Kompleksiteten opstår ifølge Ola Bini dels ved, at vi i dag anvender computere til mange flere formål end tidligere, dels ved at vi slæber rundt på rigtigt meget gammel teknologi. Han nævner som eksempel, at hvis man etablerer en ny bank i dag, implementerer man en kopi af et eksisterende banksystem, som måske er 30-40 år gammelt – ingen tør give sig i kast med at udvikle et banksystem fra grunden.
– Det er faktisk et forholdsvist realistisk apokalyptisk scenario, vi taler om her. Hvis vi får det store kompleksitetssammenbrud, vil den globale økonomi bryde sammen. Vi ser allerede ”små” sammenbrud som det, der skete 1. august 2012, hvor fejl i en nyinstalleret ”high-frequency trading”-algoritme på få øjeblikke gav Knight Capital Group et tab på 440 millioner dollars på New Yorks børs.
Professionalisme efterlyses
Ola Bini hævder ikke, at han har silver bullet-løsningen på problemet, men ét element er en forbedring af programmeringssprogene, så de, blandt andet, tydeligere kommunikerer hensigten uden støj fra unødvendige detaljer. Et andet element er en erkendelse i branchen af, at der er brug for radikale ændringer, for eksempel når det gælder support af systemerne.
– Det er ret normalt at skrive noget ufærdigt kode og bare sende det videre til driftsfolkene, der så må forsøge at håndtere problemerne. Det er ikke en professionel måde at gøre det på, og jeg mener, det er på tide, vi virkelig tager ansvar for det, vi udvikler. Jeg kan for eksempel godt lide Amazon-modellen, hvor udviklingsteamet også står for al fremtidig support, siger han.
Det rigtige sprog til opgaven
Ifølge Ola Bini kan man ikke opstille generelle regler for valg af programmeringssprog. Flere undersøgelser har dog vist, at antal fejl pr. linje kode stort set er konstant. Så jo flere linjer kode, jo flere fejl. Han anbefaler derfor som udgangspunkt at gå efter et kompakt og præcist programmeringssprog – eksempelvis Ruby i stedet for Java. Opgavetypen er dog den vigtigste faktor, når der skal vælges sprog.
– Forskellige typer opgaver kræver forskellige sprog. Hvis man har friheden til at vælge det rigtige sprog til opgaven, kan man reducere kompleksiteten og udviklingsomkostningerne betragteligt, siger Ola Bini.
Sammen med tre kolleger fra ThoughtWorks var han for nylig involveret i et cancer-projekt, hvor man primært anvendte Ruby til dataprocesseringen, mens Clojure blev foretrukket til den del af projektet, der handlede om biologisk modellering – valg truffet ud fra specifikke styrker i sprogene i forhold til opgaven.
– Friheden til at vælge det rigtige sprog gjorde, at vi kunne håndtere den store kompleksitet, der lå i projektet inden for en forholdsvis stram tidsramme. Ola Bini understreger pointen med tørre tal:
– Vi havde omkring 10.000 linjer Clojure-kode, som efter min vurdering matcher 6-700.000 linjer Java-kode.
Undervejs i projektet skiftede man også fra JavaScript til CoffeeScript til udvikling af frontend'en.
– Efter omkring seks måneders udviklingsarbejde kunne vi se, at koden blev svær at håndtere. Selvom man skriver god JavaScript-kode, er den ikke særlig nem at læse. Så vi begyndte at konvertere til CoffeeScript, hvilket tog omkring en måned, fortæller Ola Bini.
Udviklerne skal presse på
Friheden til at vælge sprog og andre teknologier var afgørende i cancer-projektet på grund af kompleksiteten af det problem, der skulle løses. Den frihed har man ikke altid og er heller ikke nødvendigvis afgørende.
– Det er altid vigtigt at vælge det rigtige sprog til opgaven, men i en mere traditionel udviklingsvirksomhed har man ikke altid den frihed. Men da udbyttet af at vælge det rigtige sprog stiger med kompleksiteten af opgaven, er det heller ikke altid afgørende, om man for eksempel vælger Ruby eller Clojure, siger Ola Bini.
Han mener, at udviklere generelt ikke presser nok på for at få mulighed for at vælge det rigtige sprog.
- Mange er desværre fanget i en tankegang, der siger ”vi er en Java-udviklingsvirksomhed, og derfor bliver vi ved med at udvikle i Java”. Teknologiskift kommer aldrig ovenfra, så det er op til udviklerne at presse på for at få friheden til at vælge sprog. Og en god programmør skal være i stand til ret hurtigt at lære et nyt sprog. Faktisk bør programmører have en bred erfaring med forskellige sprog. Jeg ville for eksempel ikke råde til at ansætte en programmør, der kun har udviklet i Java, siger Ola Bini.
