Ekspert: Kun en fyring af Cowi kunne forhindre test-skandalen

Hr Bønnerup har garanteret ret i alle sine iagttagelser. Der er dog én af dem jeg personligt tvivler kraftigt på (som i: Jeg tror ikke en Bønne på den):

At bod hjælper.

Jeg har set MASSER af projekter i mit alt for lange liv, hvor der har været bodsbestemmelser, og hvor de også er trådt i kraft (fordi alle store, offentlige projekter jo bliver forsinket - ikke kun IT-projekter), og det har da ALDRIG afhjulpet problemerne.

Fint nok at have en trussel hængende over hovedet, så man har fokus på at blive færdig (bortset fra, at jeg personligt IKKE synes om det menneskesyn der ligger bag). Men når først bodsgangen træder i kraft, så er det jo kun med til at svække leverandøren og tvinge ham til kun at gøre det allermest nødvendige og gøre modstand mod alt fra kundens side.

Udover det er selve idéen med bod/bøder jo også meget skidt for små og mellemstore bikse, mens de store er totalt ligeglade pga deres internationale forbindelser og forsikringer i millionklassen.

Om COWI så havde gået med til en bod på 42 milliarder havde det jo ikke løst problemet. Hvad problemet så end er. Det må vi jo finde ud af. For al den dårlige offentlige omtale som dette har givet COWI i nogle år nu er langt værre for dem end nok så store boder.

Så lige netop dén iagttagelse tror jeg ikke på, Hr Bønnerup.

Faktisk prøver vi i min biks bare at sige nej til alle de tossestreger med bod og bøder, når vi snakker med kunderne.

De kan som regel heller ikke helt forklare, hvorfor de vil have dem. Det er bare - øh - ligesom noget man GØR, ikke?

Det handler som regel enten om at få HÆVN over en leverandør eller det handler om et menneskesyn, hvor penge driver al menneskelig aktivitet. Iøvrigt ofte et menneskesyn fra de der gamle kollektivister/68ere, der tror alt muligt grimt om private virksomheder, indtil de selv starter én, høhø...

Nå, vi må videre.

Mvh.

Mogens

Det er lidt lige som når ens avis gang på gang er forsinket grundet problemer med bude i lokalområdet. Man får naturligvis refunderet sin forsinkede eller udeblevne avis – men hvad kan man bruge det til? Man har jo ikke tegnet sit abonnement for blot at få sine penge tilbage, men fordi man rent faktisk ønskede at starte sin dag med en morgenavis.

Mange bodsaftaler er skruet sammen på en tilsvarende måde, og resultatet er jo netop, at man får nogle penge retur – og stadig står uden en fungerende løsning.

Jeg er sikker på, at det ikke gør sig gældende i dette tilfælde, men man har da gennem tiden set eksempler på, at det for en leverandør bedre har kunnet betale sig at betale boden end at kaste de nødvendige ressourcer efter at få løst problemet. I sådanne tilfælde ville en højere bod måske kunne have hjulpet.

Bod og/eller tilbageholdt betaling kan være et effektivt middel mod leverandører, der »strammer skruen« for hårdt, hvilket nogle leverandører har en tendens til at gøre. Men jeg er ganske enig med dig i, at det sjældent er effektivt i tilfælde, hvor en leverandør har vist sig at forpligte sig ud over evne, eller hvor projektet har vist sig at have et meget større omfang end forudset.

Jo, men betaler COWI eller andre firma pengene tilbage for det system der ikke virker? Eller betaler de for de ulemper et ikke færdigt system giver - det er vel her en bod kommer ind.

MVH Niels

Ganske enig. Som de siger i Bladkompagniet: Gårsdagens avis er faktisk ikke ret meget værd :-)).'

Det var da også dejligt at få 218 pund forleden af BA, fordi deres fly til København var forsinket. Men for det første kender man ligesom risikoen ved at flyve, eller køre bil til Jylland, for den sags skyld: Man kan blive forsinket i forhold til ideel-planen.

For det andet bliver jeg jo ikke lykkeligere af at få de 218 pund, når jeg først har fået at vide, at grunden til at jeg får dem IKKE er, at BA vil være søde ved mig, men at det er et EU-regulativ nu om dage.

PUF! Dér røg fornøjelsen ved at få udbetalt penge ved forsinkelser i gamle dage. Nu er det noget man har KRAV på, og så er det jo ikke noget man bliver glad for på samme måde. Sjovt, ikke?

Vi kunne jo prøve at kigge på, hvem der bliver gladere/lykkeligere, når COWI betaler bod:

COWI? Næh.

Folkeskoleeleverne? Næh.

Mig (og andre skatteborgere)? Næh.

Undervisningsministeriet? Jeg tror det ikke.

Hvem Søren er der så tilbage?

Mvh.

Mogens

Nej, det er ikke formålet med bod.

Det du taler om er vel snarere no cure no pay.

Bod er beregnet på at fremtvinge en løsning når parterne ikke kan blive enige.

Mvh.

Mogens

Det eneste argument jeg har hørt for at indfører bod, går ud på at leverandøren herved vil prioritere denne kunde højere end de andre ... Det holder kun så længe der ikke er andre kunder der har bodsaftaler.

Hvor meget ekstra laver en leverandør, med en bodaftale?

Hvor mange programmør-mande-år giver 110 millioner? Det virker som et beløb helt ude af proportioner! Jeg vil men (uden at have set kravspec) at en enkelt (dygtig) programmør kunne løse denne opgave på mindre end 6 måneder. Og så lige en server eller to og så spiller det. Og skulle to servere ikke være nok så sæt nogen flere op - det er jo et problem som er let at partitionere (brugere med fornavn 'A' bruger server1 osv). Og hvor svært er det lige at teste at det performer uden at holde brugerne for nar?

Undskyld COWI, men det er virkeligt svært at forestille sig hvad der har ført til det forløb vi har set her!

Jeg skulle lige til at skrive et indlæg som vel stort set ord for ord kunne have været det samme. Hvad fanden foregår der?

Jeg mener jo også personligt, at EPJ burde kunne laves af tre gode mand på tre måneder (som de fleste ting jo kan, hvis de får fred og ro til opgaven) :-).

Omvendt ved jeg også fra kilder inde i ministerierne, at man bare kan GLEMME at komme igennem med idéer derinde, der er for billige.

Hvis man kan lave en landsdækkende løsning på ét eller andet for 10 millioner, så bliver det ligesom ikke rigtigt til noget før en af de store kommer med et bud på 100-300 millioner kroner.

SÅ ligner det noget - problemet er jo desværre, at de skal have brugt alle de penge de har fået tildelt i det offentlige. Så nytter det jo ikke at ivrige og dygtige gutter kommer rendende med et sølle forslag til 10 millioner, der ovenikøbet kan køre oppe i skyen for 42 Euro om måneden, vel?

Mit favoriteksempel er den elektriske kirkebog. 300 millioner fik ingeniørfirmaet for løsningen. Da jeg spurgte, hvorfor det havde taget mere end 42 timer at designe et system til håndtering af de samme felter som man altid har brugt på papir OG som samtidig stort set ikke har noget som helst transaktioner, og derfor formentlig kunne håndteres i 2-3 tabeller i en hvilken som helst relationsdatabase ... fik jeg svaret (af ham, der stolt havde stået for projektet): "Der var også en del sikkerhed, der skulle bygges ind i systemet...".

Udover de 300 millioner kroner til systemet skulle der naturligvis også anskaffes ny hardware til præsterne og alt muligt.

Det egentlige problem i 10-årene har været alt, alt for mange penge og for få projekter at bruge dem på i sådan nogle ministerier. Kirkeministeriets 0.7% af indkomsten fik jo fordoblet sin værdi mellem 2002 og 2007 - hvad hulen skulle de bruge pengene på?

Og så skulle de lade sådan en som mig lave en simpel web-applikation i Skyen, der kunne håndtere de par småting for dem, og så stå tilbage med endnu flere ubrugte midler? Næh, nej. Når der kommer et seriøst bud på 300 millioner, så sker der noget.

Så COWI (og vi andre) har altid valget: Vil vi komplekse og fordyre systemer indtil vi ser seriøse nok ud m.h.t. at kunne bruge det offentliges mange penge, eller vil vi se på, at de andre gør det?

That's the Question :-)).

Mogens

Da er da positivt.
Så er eleverne forhåbentlig fri for testene så længe.
Udformningen er så ringe, at vi ikke kan være bekendt at byde børn at de skal bruge tid på det.
Jeg startede forfra. d.v.s. 3. klasse matematik.
Opgaverne tog kun et øjeblik, men at gætte sig til, hvor tåbeligt, man skulle bære sig ad for at vise systemet, at man havde løst opgaven, tog rigtig lang tid.
Det kan vi IKKE være bekendt.

Det handler som regel enten om at få HÆVN over en leverandør eller det handler om et menneskesyn, hvor penge driver al menneskelig aktivitet. Iøvrigt ofte et menneskesyn fra de der gamle kollektivister/68ere, der tror alt muligt grimt om private virksomheder, indtil de selv starter én, høhø...

Du kan kalde det 'bod' eller reservere den sidste del af den samlede kontraktsum som 'bonus'. Det koster COWI på imagefronten når et system som dette fejler, men det er vel efterhånden blevet helt normalt den slags sker.

Som Jens Fallesen er inde på, så kan det være en bedre forretning at betale boden, end at løse problemet med overarbejde, specialister, ekstra hardware, ekstra tests. Havde boden været 20 millioner i stedet for 2 ville der naturligvis være mere fokus og flere resurser til at kontrollere systemet.

Det har intet med menneskesyn at gøre.

Usædvanlig tågesnak fra Bonnerup

DSB's IC4 projekt er jo et godt eksempel på hvormeget bod hjælper på leveringsprocessen.
Når først boden når et vist niveau mister leverandøren fuldstændigt interessen for projektet (under forudsætning om at de havde interessen til at starte med).

Under alle omstændigheder syntes jeg det lyder som opskriften på en fiasko at udvikle et centraliseret IT-system med snævre svartider der kun skal bruges et par gange om året med så tilgengæld har 50.000 samtidige brugere. Den slags koster mange penge til test og en masse erfaring som nok ikke kan skaffes i danmark. Det er ikke en opgave for en hobbyprogrammer i 6 måneder :-)

Under alle omstændigheder syntes jeg det lyder som opskriften på en fiasko at udvikle et centraliseret IT-system med snævre svartider der kun skal bruges et par gange om året med så tilgengæld har 50.000 samtidige brugere. Den slags koster mange penge til test og en masse erfaring som nok ikke kan skaffes i danmark. Det er ikke en opgave for en hobbyprogrammer i 6 måneder :-)

50000 samtidige brugere er ikke nogen kæmpe opgave, man skal ikke kode med hovedet under armen, men så er det heller ikke værre, det er en opgave som det er ganske let at splitte op på flere servere. Er du klar over at du kalder hele den danske programmørstand inkompetente? Er du selv programmør? Eller blot noget som helst der ligner?

@Jacob

Jeg har været programmør i min barndom. Nu laver jeg database infrastruktur i en fortune-500 virksomhed. En af mine bi-beskæftigelser er at deltage i tilbagevende taskforces vedrørende webapplikationer som ikke skalerer. Jeg har forlængst passeret taskforce nr 50 så jeg har hørt den samme klagesang et par gange "vores applikation hænger når der kommer flere end 10 sessioner - der er vist en bug i databasen". Jeg indrømmer at de eneste systemer som jeg ser er de syge så jeg har et negativt perspektiv på arkitekter og udvikleres evne til at håndtere samtidighed. Det ville være meget friskt at kalde den samlede danske programmørstand inkompetente men mine erfaringer med massive oltp systemer indikerer at mange samtidige brugere kræver særlig omhu, kontinuerlig test og et meget erfarent udviklingsteam der samarbejder tæt med infrastruktteamet. Hvis du starter med en traditionel webarkitektur med loadbalancer, applicationserver, database server og synkrone transaktioner falder du fladt på maven. Jeg kender ikke Cowi's løsning men de er tilsyneladende ikke engang istand til at isolere problemet - det er en taskforce jeg er glad for at misse :-)
Min kommentar med hobbyprogrammører var mest møntet på et tidligere indlæg fra Peter F

Det glæder mig at du er frisk og har nogle gode ideer - har du afprøvet dem i praksis med 2-300 samtidige brugere?

Jeg har ikke 2-300 samtidige brugere, ikke at det burde være et problem for en enkelt server, med mindre man fx tæsker en database med et stort antal forespørgsler for hver sidevisning. Hvis man kan holde sin applikation på et fornuftigt antal forespørgsler og i øvrigt har hard- og soft-ware sat op så der er ordentligt hul igennem til databasen så burde selv en almindelig Apache server kunne klare nogle tusinde brugere, men skal vi derudover er det nok en ide at få de traditionelle webudviklingsværktøjer af banen.

En anden ting som jeg selv har arbejdet med er JavaScript, hvis man ved hvad man laver kan man let få ryddet nogle sidevisninger af vejen og lagt noget af serverens arbejde over hos klienten. Sådan en test her fx kunne jo let skrives som en enkelt side hvor eneste yderligere kommunikation med serveren som er nødvendig er svarene som sendes tilbage.

Det er ikke alm. sidevisninger der er problemet. Al test-materiale er readonly data og selvom der formentlig er en del tests for det adaptive system at vælge imellem, så er der næppe mere data end at det hele uproblematisk kan ram-caches ude på webserverne. Så der er ingen grund til at lave en masse krumspring i javascript for at minimere disse.

Der hvor filmen knækker er sandsynligvis submit af svar. Det involverer formentlig oprettelsen af en transaktion i databasen og det kan hurtigt komme til at udgøre en flaskehals hvis man f.eks. ikke er opmærksom på hvilket niveau der låses på.

Det er dog ikke noget man ikke burde opdage ret hurtigt ved en simpel stresstest af systemet. Noget der påvirker hele systemet med lange svar-tider, burde i det hele taget være nemt at opdage i en stresstest. De svære fejl er typisk dem hvor det kun går galt for 1/1000+ brugere.

Det er total vrøvl - når man kan give en leverandør 100 % af skylden for en så massiv fiasko som IT test skandalen.

Det er korrekt at IT leverandør ofte fejler, og at konsulent firmaer ofte mener de bedre forstår virkeligheden bedre en dem der er i den - i dette tilfælde skolelærere.

MEN den fejl jeg ser igen og igen er at det mellemlag som er mellem bruger og leverandøre er den primære årsag til at fejl ikke bliver rette, begrænset og at funktionalitet ikke bliver løbende tilpasset.

Dette lag betegnes ofte som DJØFerne (jeg er selv en af dem) og har ofte til opgave at organisere, kontrollere samt optimere det andre laver.

Problemet opstår ofte i at denne gruppe skal forsøge, at beskrive andres arbejde og ofte også koordinere det med politisk målsætninger - og derefter omsætte det til et nyt it system.

Dette mislykkes ofte når der er tale om komplekse og store systemmer fordi virkeligheden konstant ændre sig - og behov og muligheder for et it system er total anderledes 3-7 år efter man har lavet en krav spec. Der mangler en grundlægende forståelse i store organisationer, at IT udvikling ikke, er det samme som at skrive en lov paragraf - Det er mere at sammenligne med evolution af et levende væsen på speed i meget foranderlig omgivelser.

Det betyder at samarbejdet med leverandørerne og bruger skal faciliteres og plejes løbende, man skal fodre processen med korrekt næring igennem hele processen, ikke kun ved milestoens. Der skal prøves og testes muligheder og løsninger konstant for at se om de er levedygtige. Til sidst, men ikke mindst, SKAL man test at organismen er leverdygtig uden for laboratoriet

@Niels
Jeg har svært ved at forestille mig a COWI ikke er istand til og ikke har gennemført en simpel stresstest. Det er gået galt flere gange før så det bør stå lysende klart for selv den mest indskrænkede DJØFfer og en gruppetænkende projektgruppe at antallet af samtidige transaktioner er et særligt problem i denne type applikationer. Hvis de har lavet banale fejl i implementeringen e.g. databaselåsning eller andre synkroniseringspunkter bliver det normalt afsløret inden de første 100 brugere bliver aktive. Det som er interessant med massive transaktionsmængder er at enhver svaghed i applikationen bliver forstærket ala megafon når load stiger. Det er virkeligt en kunst at bygge en applikation som skalerer liniært med load og indsatte resourcer.

@Claus: Den uendelige, lineære skalering findes kun hos Harry Potter. Før eller siden vil alle ramme knæet i kurven, og så går det deruda'. Som min ven Cary Millsap altid siger: "Everything scales - sometimes, though, it scales in a way you don't want..." :-)

Mvh.

Mogens

@Mogens: Undskyld hvis jeg antyder at den perfekte skalering er mulig. Den uendelige skalering findes naturligvis kun i hjernen på sælgere og arkitekter under et hæftigt kokainrus. Den faktuelle skalering for en eksisterende applikation ophører ofte på et overraskende lavt niveau men med erfaring (kunst) og en masse knofedt kan et godt team få en humlebi op at flyve.