Hemmelig rapport afslører CSC's og Scanjours katastrofale Polsag-kode

»Det forhold, at JavaScript er et typesvagt sprog, medfører, at øget kompleksitet har en væsentlig større negativ impact for udvikleren end ved andre sprog.«

Det gik jo egentligt OK indtil denne kommentar. Jeg kan regne ud af en del af Polsag består af en webklient, og så er Javascript nu engang det vi har at arbejde med (jaja, der er alle mulige sære sprog der kan oversættes til javascript, men hvor mange mon rent faktisk bruger den slags i enterprise-applikationer?).

Ét ord: Typescript.

<qoute>
Det vurderes at være svært at udlede de forretningsmæssige krav og ønsker på basis af SDD'erne,« hedder det i gennemgangen.
</quote>
Den næste forespørgsel om aktindsigt kunne så netop fokusere på hvordan politiets "ikke-it-nørder" har beskrevet og dokumenteret deres forventninger/krav til POLSAG's støtte til forretningsprocesserne. (altså hvordan skal betjenten registrere en udstedt fartbøde, registrere en henvendelse fra en borger, osv. osv. )

Store gamle IT-firmaer har typisk en stor kodebase af ældre dato, som de gerne bygger nye applikationer ovenpå i den tro, at de sparer tid og penge ved dette. Derfor bruges ofte forældede platforme såsom .NET 2.0, og koden bliver patch-på-patch og derfor mere og mere uoverskuelig og tung. Endvidere vil egenskaber såsom samtidig brug og sikkerhed være meget vanskelige at tilføje, da den slags skal være bygget ind fra grunden og kun vanskeligt lader sig bygge ovenpå en kodebase, der ikke er forberedt til dette.

Men historien viser gang på gang, at der ikke er noget sparet ved at bygge et stort IT-projekt som modifikation et ældre projekt. Man skal bruge mere tid på at omgå begrænsningerne i den gamle kode, end den tid, man sparer ved ikke at skulle skrive det fra bunden.

Men desværre er der mange såkaldte softwareudviklere, der ikke magter at skrive ting fra grunden: De kan til nød modificere eksisterende kode og sætte parametre på biblioteksfunktioner, men hvis der skal laves grundlæggende ny funktionalitet, smider de håndklædet i ringen -- eller koder tåkrummende dårlig og skrøbelig kode, hvilket faktisk er værre.

Enig -
Patchwork oven på gammel kodebase kan aldrig løse de grundlæggende mangler.

• og delvist enig.
  Der er stadig gode programmører derude. Det er sjældent at projektet tillader at de kan bruge tid på at skrive koden helt fra bunden. Men vi kan godt lave quicksort og dobbelt linkede lister, hvis vi altså finder olie i norske mængder.

Det er i øvrigt forbavsende ofte vi ser, at store IT monstre partout skal erstattes af et større - og at projektet fejler.

Selv om JavaScript kan kaldes for et vilkår for programmering til browser-klienter, ændrer det ikke på at sprogets karakter medfører at kompleksitet nemt bliver ekstra svært at overskue uden en grundig disciplin og strukturering af koden. Jeg ser ikke denne passus som et "angreb" på brugen af JavaScript, men blot en ekstra faktor omkring at koden vurderes som værende for kompleks (rodet). Og det forekommer mig at være et fair kritikpunkt.

NEEDS MORE BREAKING...
Kan i offentliggøre rapporten her ? Den lyder ret interessant (undskyld hvis jeg har overset det åbenlyse link)

TypeScript er først blevet offentliggjort i løbet af i år, så jeg synes ikke vi kan klandre dem for ikke at have brugt det i denne specifikke sag.

Og hvis de rent faktisk kritiserer dem for at have brugt javascript i en webklient så skal de holde op med at ryge fjolleurt. Hvis de kritiserer dem for at kode slamkode er det noget helt andet.

Det er jo nok forholdet mellem klientkode og serverkode som er kritisabelt. At bygge et stort system op omkring en tyk javascript klient lugter langt væk.

Kan du så fortælle mig hvor det link, er for jeg kan sgu ikke finde det, ikke særligt åbenlyst.

Til alle jer, der efterlyser selve rapporten:

Selve aktindsigten er en meget omfattende sag, og vi er blevet bombarderet med dokumenter. I første omgang går vi efter at grave de mest åbenlyse historier frem fra materialet, sidenhen skal vi nok offentliggøre de mest oplagte dokumenter.

God jul & vh Morten, Version2.

Det er forkert at skrive .NET 2.0 er forældet; ja vi har .NET 4.5 men CLR er stadig meget lig den der findes i .NET 2.0 omend der er lavet forbedringer. .NET 2.0 og frem er meget tidsvarende.

Har de brugt et automatisk standard værktøj til at måle kodekompleksitet eller har de reelt vurderet kvaliteten?

Det virker i det hele taget temmeligt søgt at kritisere for brug af .Net 2.0, eftersom projektet blev startet i 2003, mens .Net 2.0 først udkom i 2005. Man har altså valgt at opgradere platformen midt i udviklingsforløbet mindst én gang. Det kan selvfølgelig være fordelagtigt i nogle tilfælde, men kan også være risikabelt, og kan da på ingen måde siges at være et must.

Gætter på det er en statisk analyse af det.
Var faktisk ved at skrive en kommentar lig med din, men efter lidt omtanke tror jeg faktisk ikke det er så dum en måde at betragte kvalitet af software. Altså givet at man skal sige noget generelt.

Det har ellers været ganske meget fremme i nyere tid at bygge websider hvor serverside-delen ikke er meget mere end data-validering og et API der bruges af klienten.

Kan ikke sige jeg er 'forbavset' over kompleks kode.
Det virker som om der ofte er en ... nærmest nødvendighed i at lave kode kompleks fordi det så virker mere 'programmøragtig'.

Der er jo ikke meget prestige i bare at lave noget der virker ordentligt hvis det ikke implementerer 17 interfaces, nedarver nogle klasser og benytter en masse andre teknikker.

Det sjoveste eksempel jeg har set på det var en gut der lige havde læst om en Y-Combinator, og så implementerede en generel sorterings-metode med den i C#. (Koden skulle bruges eet sted, og var temmelig krøllet).
Jeg foreslog ham at refaktorere det, og det gjorde han heldigvis.

Lysten til at spille med den intellektuelle muskel uden god grund, skal holdes til egne side-projekter, og ikke ind i den fælles kodebase :-)

Jeg tror (håber) at kritikken skal ses i sammenhæng med kritikken af test-coverage og kompleksitet. For med et dynamisk sprog som JavaScript er det sandt, at det er ekstra vigtigt at du skriver test til din kode.

Men hvis du til gengæld skriver de tests der skal til, kan du sagtens bygge seriøse ting med JavaScript.

Det er muligt jeg husker forkert, men var det ikke en væsentlig antagelse, at løsningen skulle baseres på et standardprodukt, i dette tilfælde ScanJours ESDH-system?

Hvis projektet aldrig har været tænkt som et udviklingsprojekt, men som implementering af "standardfunktionalitet med mindre tilretninger", så er det ikke overraskende at det går galt, når der opstår behov for langt mere udvikling end forudset. Man kommer til at mangle ressourcer med de nødvendige evner og projektplanen indeholder ikke aktiviteter til den nødvendige analyse, dokumentation og test.

Samtidig har projektet en størrelse, hvor erkendelsen af, at vigtige forudsætninger ikke længere er opfyldt, har en meget langsom vej til de beslutningstagere, der kan (eller burde kunne) agere på den omstændighed at standardløsningen er for langt fra de stillede krav. Er der det mindste element af personlige politiske agendaer eller "management by fear" på vejen fra den tekniske erkendelse af problemet til den forretningsmæssige løsning, så går det galt.

Det er jo nok forholdet mellem klientkode og serverkode som er kritisabelt. At bygge et stort system op omkring en tyk javascript klient lugter langt væk.

Citation needed.

Hvad er dine erfaringer med tunge javascriptklienter bygget med moderne webteknologier som får dig til at drage den konklusion?

Vi skal i vores branche til at stille større formelle krav til udviklere, som man f.eks gør med læger. Her har man opbygget et system med turnus, specialisering og lægeløfte etc. I dag kan alle kalde sig for software ingeniør og hvis arbejdsgiver ikke er skarpe til at hyre kompetente mennesker der selv stiller høje faglige krav til resultatet af deres arbejde, så går det nemt helt galt med en kodebase.

Det ville være perfekt for CSC at finde nogle grunde til at deres POL sagssystem haverede i hegnet.

Men det har intet med Javascript at gøre. Jeg gætter på at flere af de mennesker der er fremkommet med det argument bruger gmail som privat mail konto. En applikation der er skrevet i 90% Javascript (152.000 LOC) som virker ganske fortræffeligt. Om MS produkterne er outdated aner jeg intet om.

Mem jeg ved at "greenfield" system kræver mange beslutninger. Hvis nogle af de beslutninger der tages tidligt i projektet er forkerte kan de næste beslutninger ikke rede situationen.

Sådan som jeg læser Globeteams rapport er det tydeligt at problemet handler om mennesker og dårligt håndværk. Globeteam er bare for konfliktsky til at sige det ligeud.

Jeg funderer om der kunne være tale om en usund arbejdskultur.
Dvs. at management ikke vil have alt det der pjat med tests, og dokumentation - det eneste der skal laves er funktionalitet.

Begrebet teknisk gæld er måske også ukendt for management.

Hvis de har irettesat gode udviklere for at lave tests, og dokumentation, så er det næsten helt sikkert at ingen knap så dygtig udvikler ville turde tage et initiativ til noget der ligner kvalitetskode.

Det fremgår ikke her, men af min kendskab til deres arbejde, bygger det på begge dele. En værktøjsbaseret analyser med Sonar el. lign., og så derfra manuelle undersøgelser og vist nok også interview med div. projektdeltagere.

Det har ellers været ganske meget fremme i nyere tid at bygge websider hvor serverside-delen ikke er meget mere end data-validering og et API der bruges af klienten.

Det er måske populært (google er gode til det) men det er svært. Jeg påstår at det er meget nemmere at lave et solidt stort system med kringlet forretningsregler i et typestærk sprog com c#. I min verden er .net 2 desuden forældet, når jeg tænker over hvordan jeg kan løse samme problemer med .net 3.5+. Man skal turde skifte version midt i et udviklingsprojket, hvornår skulle der ellers komme et bedre tidspunkt?

Dette bekræfter mig blot i at leverandørene aldrig havde planlagt at levere et fungerende system.
De stod sig langt bedre ved at levere noget dårlig kode, som aldrig ville kunne bringes til at fungere og score den betaling som de nu kunne få for det.

Det kan man jo sige, men et eller andet sted tror jeg heller ikke de fleste steder er klar over hvordan man faktisk udvikler IT. Mange steder kører stadig efter 70er og 80er "principper", hvor udviklerne reelt står for alt tekniske styring, og som der er blevet påpeget i kommentarerne så halter mange udviklere langt efter hvad der reelt er påkrævet for at udvikle store moderne web applikationer i "god kvalitet".

.NET 2.0, og med de tal der nævnes, så er jeg sikker på at alle udviklere kan nikke genkendende til det et projekt de har arbejdet med selv, skrevet af folk som ikke kender grundlæggende framework koncepter, med de medfølgende gamle/propriatære UI web forms kontroller iblandet den obligatoriske JS blanding af forsøgt OO/lib og funktions suppe. For slet ikke at tale om når et projekt også går amok på databasen med tusinder af stored procedures/functions/views oven på alt det andet. Og naturligvis må der være en trillion integrations punkter, og hvad der så deraf kommer af ekstra kompleksitet.

Jeg har ikke arbejdet på noget i Polsag skalaen, så selv jeg har svært ved at forestille mig det absolutte rod det må være (50% af koden i 7% af funktionerne, jesus).

Nu har vi ikke set hele rapporten, men jeg synes også deres kommentare om .NET 2.0 og JS virker mærkelige, men der er måske også tale om nogle få sætninger i en flere hundrede sider lang rapport.

Alle mulige sære sprog, sådan som Java? Som Google har bygget gmail i og så oversat det til Java. Det lyder ret mainstream for mig.

https://developers.google.com/web-toolkit/makinggwtbetter

GMail er bygget vha Google Closure Tools, ikke GWT.

Desværre er der jo ikke noget der tyder på at det ændrer sig i nær fremtid. Det offentlige bliver ved med at fortsætte denne måde at udbyde IT opgaver på.

Jeg er af den overbevisning at sandsynligheden for, at et IT projekt fejler på denne måde, er proportionel med, hvor meget den SKAL omfatte ved første release.

Hvis man starter småt, men dog har opmærksomhed på at systemets fundamentet skal kunne håndtere et uvist mængde af tilføjelser, kan man sagtens ende med en løsning, der ikke har karakter af knopskydninger.

Spis elefanten lidt ad gangen og til sidst er man i mål.

Utroligt mange af de store systemer, der har haft succes, er startet småt og er efterhånden forbedret og udvidet indtil man løser de opgaver der rent faktisk skal løses.

Ulempen ved at man har hele problemet defineret i en STOR kravspecifikation er, at man så kun fokuserer på det der er defineret. På den måde lukker man muligheden for tilføjelser eller ændringer da hele system er internt afhængigt. Sagt på en anden måde, hvorfor skal en projekt leder afsætte tid til at gøre system generisk hvis der ikke er brug for det? Alt er jo beskrevet nøgternt i krav spec ikke?
Hvorfor bruge tid på besværlige patterns og lagdelinger hvis man bare kan skrive en funktion der kan det hele. Det lyder uhyggeligt men der sker. Som jeg læser det:

»50% af kildekoden til POLSAG-serverapplikationen er samlet i kun 5% af metoderne (19% af kildekoden er samlet i kun 0,7% af metoderne),« skriver Globeteam i rapporten.

Så lyder det som en forfærdelig gang spagetti kode.

Et andet problemer er at man fra start af, sjældent har et overblik over, hvilke problemer systemet rent faktisk skal løse.

Tit er der en tendens til at tro man ved det. Jeg har flere gange oplevet at man løser problemerne på den måde man altid har løst dem. Dette er selvom man aldrig har løst problemerne med de tekniske hjælpemidler man nu har. Altså man indbygger en del af de eksisterende løsninger i et IT system, selvom de kun løste nogle problemer man havde, da man gjorde tingene manuelt. Eller man indbygger nogle af de Userinterface paradigmer man havde da applikationen stort set bare var en SQL forms app.

Andre gange har jeg oplevet at jeg har løst problemet PRÆCIST som det var defineret, men når man så bruger det, finder man ud af, at det alligevel ikke var det man ville have. Først bagefter kommer der så en gradvis forbedring af løsningen indtil den er acceptabel. Hvis hele løsningen så er designet til det der oprindeligt var defineret i kravspec betyder det så at der er lavet nogle opfindsomme hacks der får systemet til at virke med den løsning man til sidst fandt. Desværre gør det så løsningen lidt langsommere og langt mere uforståelig fra et teknisk perspektiv.

Jeg har meget svært ved at vurdere disse tal, altså om det er spaghettikode eller ej.

Som jeg har forstået det er serverdelen et webserver-program, skrevet i C# på .Net 2.0, som læser og skriver data i en database. Til dette er der sikkert et godt kodegenereret objektorienteret data-tilgangs-lag, som sikkert er mange tusinde klasser med metoder der kun henter eller sætter værdien at en variabel (get og set). Der skal altså skrive rigtig mange forretningslogik metoder til at nå op på 5% af samtlige metoder...

Tilsvarende har jeg det svært med analyseprogrammers angivelse af kompleks kode, brug af abstrakte eller interface klasser, eller en simpel try-catch er som regel nok til at koden er kompleks. Det siger mere om analysen end programmøren.

Når det er sagt, så forventer jeg da at firmaet har haft programmøre til at kigge kode grundigt efter, og at rapportens konklusioner er baseret på dette og ikke de nævnte tal.

Så vidt jeg husker blev POLSAG købt under FESD aftalen - og altså ikke som et "rigtigt" EU-udbud?! Korrigér mig, hvis jeg tager fejl?!?

For heri ligger hele misæren.

Politiet var med i følgegruppen til FESD arrangementet - og havde dermed en form for forpligtelse til at vælge en af de tre leverandører, som kom med på aftalen.

Men i realiteten stod Politiet med nogle noget mere komplicerede problemstillinger, end den typiske journalsystem-kunde i den offentlige sektor - og burde som sådan nok aldrig have sat sig med i følgegruppen!!

Da leverandørerne var valgt, fremstod CSC/ScanJour så som det, om man så må sige, "mindst ringe" af de tre.

Men man havde nok været bedst tjent med at springe op og falde ned på "sin forpligtelse" overfor FESD - og være gået den lange, tunge vej over et eget EU-udbud, istedet for at vride et standardsystem om til noget, det ikke var egnet til...

Undrer mig over den kraftige kritik af, at koden er 'kompleks'.

Enkelhed er godt.
KISS er et godt princip.
Unødig kompleksitet er af det onde.

Men det fremgår ikke, at kodegennemgangen påviste, at koden faktisk kunne skrives enklere og samtidigt opnå samme funktionalitet (at samme funktionalitet så viser sig at være utilstrækkelig er en anden (pol)sag).

Koden kan være berettiget kompleks, hvis datastruktur, ønsket funktionalitet og behov nødvendiggør det.

At noget er 'komplekst' bør anvendes som en objektiv, beskrivende, ikke(for)dømmende værdineutral beskrivelse. At beskrive noget som 'unødigt komplekst' bør følges af en beskrivelse af hvordan problemet kunne være løst af simplere kode (hvad det så end er: færre kodelinjer?, flere kodelinjer med lettere gennemskuelig logik?, kodning i samme stil som dén læseren foretrækker og har erfaring med?)

Uden adgang til hele rapporten er det svært at forholde sig til kritikken.

Men som det fremgår i artiklen får man nemt den tanke, at hvis man (Globeteam) er købt og betalt til at kritisk at gennemgå kode, er det sikre valg netop at være kritisk og fordømmende - er de ikke nærmest 'bestilt' til at komme med dén konklusion givet opdraget (kritisk kodegennemgang) og den kedelige forhistorie med tids- og budgetoverskridelser samt en katastrofal pilot-afprøvning hos Bornholms Politi?

Derudover er en naturlig menneskelig reaktion på noget, man (konsulenten, der foretager kodegennemgang) ikke forstår, at beskrive det som 'for komplekst'. Og en modtager (Rigspolitiet og Justitsministeriet) med samme lave forståelsesniveau vil være lykkelig for at blive bekræftet i, at vedkommende ikke mangler forståelse, indsigt og en koncis kravsspecifikation, men at koden vitterligt er 'for kompleks'.

Jeg har intet kendskab til kvaliteten af ressourcerne sat på opgaven hos hverken CSC, Globeteam, Rigspolitiet og Justitsministeriet, men man bør nok betragte rapporten som et partsindlæg ligesom et indlæg fra CSC i samme sag måtte betragtes med en vis skepsis.

Jeg tolker ordet "kompleks" som en lidt mere stueren måde at sige "rodet spaghetti-kode", især set i sammenhænge med de ganske få gengivne metrics.