Sådan er det bare...

Hvis der er noget der pisser mig af ved IT-folk, er det hverken hvide sokker i sandaler eller sproget og forkortelserne.

Men den ortodokst religiøse attitude gør det.

Meget.

I middelalderen kunne præsten hvergang der skete noget uventet slå korsets tegn for sig og medlidende sige "Herrens veje er uransalige".

I IT-branchen lyder den tilsvarende abdikation "Sådan er det bare..."

Jeg vil gerne starte med at understrege at dette er IT-branchen generelt og ingen går fri af denne kritik.

I mainframe installationer sidder de stadig, 50 år efter arkitekten indså det var hans største fejl, og fedter med JCL-"kort" hver gang de skal køre et program.

I Windows-installationer spilder de, 30 år senere, stadig formuer på "Antivirus programmer" og er først nu ved at genopfinde kommandolinien.

UNIX-nørderne har efter 30 år stadig ikke kunnet enes om en standard funktion til at åbne en TCP forbindelse eller printe en fil.

Altsammen fordi "sådan er det bare..."

Grunden til at POLSAG endte som det endte ?

"Sådan er det bare..."

Grunden til at vandrørene sprang på stribe i København fordi en computer gik ned ?

"Sådan er det bare..."

Helt ærligt: Det er fandme ikke godt nok!

Jeg har efterhånden længe været fortaler for en IT-havarikommision, der skal kulegrave IT-katastroferne så vi kan undgå at lave de samme fejl igen og igen.

Der er nogen der opponerer imod det forslag, fordi det strider imod deres politiske/økonomiske overbevisning.

Det kan jeg til nød acceptere, ikke at jeg er enig med dem, men i det mindste har de et argument der baserer sig på en eller anden form for intellektuel indsats.

Men når IT-folk siger "Det ville ikke hjælpe fordi ..." og så kommer med en eller anden syg undskyldning der kan koges ned til "sådan er det bare"

Hallo!

Mener I seriøst, at I er ude af stand til at blive klogere og bedre til jeres fag ?

Vor Herre Bevares for en attitude!

phk

Kommentarer (54)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Finn Christensen

Jeg har efterhånden længe været fortaler for en IT-havarikommision, der skal kulegrave IT-katastroferne så vi kan undgå at lave de samme fejl igen og igen.

Der er nogen der opponerer imod det forslag, fordi det strider imod deres politiske/økonomiske overbevisning.

på nogle af de områder, som du forsøger at 'tugte' på plads. Problemet er ikke it eller teknikken dertil, men den gamle remse du jo så godt kender:

"8. generations maskiner (HW), 5. generations programmer (SW) og 2. generations mennesker."

Du beder om, at 'de ansvarlige' selv åbent og ærligt fortæller at de ikke magter den hurtige udvikling, da de hverken har fornøden uddannelse, forudsætninger, evner.. (you name it) til at holde samtlige bolde i luften eller sikre mod at projekterne ryger i grøften, eller undgå at vi får fatale datatab, eller at vitale sikkerhedsbrud sker samt utallige andre kommende ulykker medierne endnu har til gode at mæske sig i.

Vores folkevalgte (totalt uden it-evner) strør hellig itSovs på alt og alle, som de kan finde, og tror i fuldt alvor på, at det redder deres finansbudget og 2020-planen og/eller næste folketingsvalg..

Faget er et Klondyke, hvor hvem som helst har gulerødderne nede i noget, som måske kun 20-30% af dem faktisk kan overskue og magte.

I lægeverdenen kaldes det for 'kvaksalveri', og i jura kaldes det vist nok 'vinkelskriveri'.

  • 4
  • 1
Poul-Henning Kamp Blogger

Du beder om, at 'de ansvarlige' selv åbent og ærligt fortæller at de ikke magter den hurtige udvikling, [...]

Ja, præcis som man gjorde det med bygningsstabilitet, kloaker, stålkonstruktioner, betonblanding, dampkedler, tog, fly og biler...

Jeg accepterer simpelthen ikke den præmis, at vi ikke kan blive bedre til IT ved at lære af vores fejltagelser, når det "trick" nu har virket så godt i alle andre teknologiske områder.

I nogle af disse andre områder har branchen selv fået deres hus i orden, vores første "bygningsreglement" kom f.eks fra Ingeniørforeningerner.

I andre brancher, der ikke selv havde rygrad dertil, har politikere grebet ind og presset en læringsprocess ned over branchen.

  • 16
  • 0
Casper Bang

Antivirus programmer prøver at beskytte dig imod noget dit operativsystem burde være immunt over for til at begynde med.

Den er lidt let købt, eftersom Android viser samme svagheder. Hvad tror du ville ske, hvis Apple ikke checkede alle programmer for malware? Eller hvis mere end 0.01% brugte BSD?

  • 3
  • 12
Poul-Henning Kamp Blogger
  1. "Alle de andre gør det også" har aldrig været en undskyldning for inkompetence.

  2. Med stor markedsandel kommer stort ansvar.

  3. Ingen andre operativsystemer har mig bekendt lidt af "autorun.inf" idiotien.

Jeg indrømmer blankt at Windows er blevet bedre, men det har i runde træk taget 25 år før M$ overhovedet indså at der var et problem og forbedringerne er alt for sløve.

  • 18
  • 3
Svend Eriksen

Din brug af 'ortodoks' er jeg lidt ked af. Ortodoks betyder 'korrekt lære', og det forekommer mig, at du nærmere mener 'reaktionær', 'konservativ', 'dumstædig' eller 'kontrær'.
Jeg forstår godt at du bruger ordet, for det er egentlig en gængs brug af det, men det ærgrer mig, at dumstædige konservative religiøse folk har fået et patent på at være ortodokse.

Nå, men bortset fra mit nørdede semantikudbrud, så har du en rigtig god pointe, og den rører ved noget som et dybt menneskelig, og som jeg mener bygger på usikkerhed.

Hvis man har en 'sådan er det bare' attitude, så bygger det efter min opfattelse ofte på, at man vil lukke diskussionen hurtigst muligt. Det kan skyldes, at man selv er klar over at der er et problem, men at man er følelsesmæssigt investeret i problemet, og at der potentielt ligger et prestigetab forbundet ved at erkende problemet. Det kræver et stort menneske at erkende at man tager fejl. Og det i bund og grund noget meget almenmenneskeligt. :)

En løsning kunne være at frakoble de mennesker som er følelsesmæssigt engagerede i et projekt fra vurderingen, og måske styringen, af det selvsamme projekt.

  • 6
  • 0
Henrik Mikael Kristensen

dampkedler, tog, fly og biler...

Der er et meget stort og meget løst defineret område over IT, som hedder "brugere". Vi tvinger folk gennem en uddannelse før de får lov at føre tog, fly eller bil, og jeg ville nødigt stå ved siden af en dampkedel, hvis jeg ikke anede, hvad jeg lavede.

På helt modsat vis er IT brugere aldeles og gladeligt uvidende om de processer der foregår i en PC, og gør man noget forkert er det ikke "værre" end at genstarte, eller kalde på sysadmin, som ved lidt mere om det, mens man lige læner sig tilbage og tager en slurk kaffe.

Vi har vel alle prøvet at udvikle software, som bliver overhovedet ikke brugt som tiltænkt, fordi man aldrig afsatte en krone til træning eller "du kan vel ikke forlange at jeg skal læse manualen?".

En IT havarikommission skal ikke bare kigge på udviklingssiden, men også på brugersiden.

  • 2
  • 3
Poul-Henning Kamp Blogger

Der er et meget stort og meget løst defineret område over IT, som hedder "brugere".
[...]
En IT havarikommission skal ikke bare kigge på udviklingssiden, men også på brugersiden.

Forestil dig flg. citat fra læserbrev i Ingeniøren, årgang 1906:

Der er et meget stort og meget løst defineret område over IT, som hedder "beboere".
[...]
En bygningsnorm skal derfor ikke bare stille krav til selve bygningen, men også til beboerne.

Nej, vel ?

  • 14
  • 0
Henrik Mikael Kristensen

Nej, omvendt. Brugere sættes til at benytte systemer de kender måske 1-2% af, men der kræves et langt mere intimt kendskab til systemet, for at få det til at køre ordentligt.

Det bør være en del af udviklingsprocessen både at spørge om det er rimeligt at udsætte Fru Jensen for et komplekst system, og om systemet kan gøres simpelt nok at bruge for Fru Jensen. Benyt en hvilken som helst offentlig tjeneste, og så kan man se, at det ikke har været tilfældet.

  • 2
  • 0
Poul-Henning Kamp Blogger

Det bør være en del af udviklingsprocessen både at spørge om det er rimeligt at udsætte Fru Jensen for et komplekst system, [...]

Det har intet med en IT-havarikommission at gøre:

Det er ikke deres opgave at inde ud af om flyet kunne hvad luftselskabet havde brug for, eller troede det kunne da de købte det, det er deres opgave at finde ud af hvorfor det styrtede ned.

Ikke noget scope-creep her, tak!

  • 10
  • 0
Frithiof Andreas Jensen

Antivirus programmer prøver at beskytte dig imod noget dit operativsystem burde være immunt over for til at begynde med.


Hmm - Vi opfordres til at installere noget USA'nsk software som har "God Mode" adgang til hele butikken, netvärksadgang for "updates", som endda proxy'er http, news, ims , e.t.c. og som löbende läser og indekserer hele filsystemet for "vores egen sikkerheds skyld".

Man kan lave mange sjove ting med AV software hvis man indbygger en "back-channel". Man kan lave en database over hvilke filer som altid forekommer på en computer og som man ikke behöver at se så meget på og hvilke filer som er nye. Hash-koderne kan man bruge til at se hvilke filer der distribueres til andre computere. Forskellige former for "heuristics" f.eks. SVM-teknikker kan anvendes til at klassificere dokumenter efter deres indhold og man kan lede efter "lignende" computere som man derefter kan gruppere og klassificere.

  • 6
  • 0
Tine Andersen

Det er jeg uendeligt meget enig med PHK i. Min mand tror nu jorden bliver reddet, hvis alle går over til android. Og ja.

Kan vi ikke lige se at skifte bleen og kigge fremad- mod noget, der virker?!

(Mit ønske siden for længe siden, da jeg gerne ville have gimp og paradox til at virke sammen) Nogen af os ville gerne have billeder i databasen.

Mvh
Tine

  • 0
  • 0
Anders Wegge Keller

En bygningsnorm skal derfor ikke bare stille krav til selve bygningen, men også til beboerne.

Der er masser af implicitte krav til beboerne i bygningsnormerne. Som for eksempel ikke at fjerne bærende vægge, frigrave fundamentet osv.

Forskellen mellem brygninger og IT er, at det for bygningers vedkommende er ret selvindlysende for beboerne, at der er ting man ikke bør gøre.

Så selvom jeg også gerne så at vi fik nogle mere stabile og driftsikre systemer, så kommer vi ikke udenom at der er nogle forskelle mellem de to domæner, at man ikke bare kan overflytte praksis fra det ene til det andet.

(Edit) Hmm, der gik noget galt med quoten her. Det var nedenstående der skulle have været svare på.

Der er et meget stort og meget løst defineret område over IT, som hedder "beboere".
[...]
En bygningsnorm skal derfor ikke bare stille krav til selve bygningen, men også til beboerne.

  • 4
  • 0
Tommy Schouw

Det er lidt i tråd med debatten og alligevel hvad der kunne kaldes scope-creep.

Jeg tror vi kunne vinde rigtigt meget ved at få redefineret IT-udvikling som et håndværk med nogle robuste objektive normer for hvad der er god og skidt kode.

Det er min opfattelse at rigtigt mange ser deres kode som et kunstværk ikke en håndværksmæssig opgave der er blevet løst, dette betyder også at der er mange forskellige måder at løse en opgave på, og da det er kunst er det jo hævet over kritik, så længe det løser opgaven.

Dette er også en ting jeg savnede fra mine IT-studier (som nu ligger små 10 år tilbage i tiden), der var ingen fokus på selve koden. Hvis det virkede, så var det godt, og hvis det crashede skulle man bare give en god forklaring på hvad man troede problemet var. Eksaminator kunne finde på at hive en stump af ens kode frem og spørge ind til det, men det var altid med fokus på at sikre at man havde været med til at skrive koden, aldrig på om koden rent faktisk var af bare middelmådig kvalitet.

Idag sidder jeg stadig ikke med en følelse af at have et klart svar på hvad der er godt IT-håndværk. Jeg er klart bedre til at få øje på noget klamp, men alt for ofte ender jeg med at skulle genopfinde den dybe tallerken, fordi vi som it-branche ikke har formået at fastholde selv de grundlæggende håndværksmæssige kvaliteter.

Det er som om vi sætter en masse arkitekter og bygningsingeniører til at bygge alle vores huse. Bygge, ikke designe og senere lede og fordele arbejdet. Så i stedet for at have en masse dygtige håndværkere under kyndig ledelse, så har man en samling folk med nogle 2 ugers håndværkskurser i at være tømrer, murer, elektriker, vvs'er og maler.

Dette er muligvis nok til diverse hobbyprojekter, men når der skal bygges broer, skyskrabere og byens kloaknet, så bliver det pinligt tydeligt at de håndværksmæssige evner og erfaringer er pinligt fraværende.

En IT havarikommission vil muligvis komme frem til det samme, men spørgsmålet er om vi allerede nu kan gøre tingene bedre?

  • 9
  • 0
Poul-Henning Kamp Blogger

En IT havarikommission vil muligvis komme frem til det samme, men spørgsmålet er om vi allerede nu kan gøre tingene bedre?

Det er meget tydeligt at IT branchen ikke har rygraden til at se sine fejltagelser i øjnene af egen drift. Det ville naturligvis være velkomment hvis det forandrede sig.

Indtil da mener jeg Folketinget bør nedsætte en IT-havarikommission.

  • 11
  • 0
Kenn Nielsen

eller mister kontrollen med persondata for mere end 10 personer.

Over hvor lang tid ?
Jeg mener; for at undgå falkeøjne på projektet kan man jo sige at een person er konstateret kompromitteret hver anden uge, og skyde skylden på en ubetydelig, - men vanskeligt detekterbar bug.

Derfor bør det være nogle ret kontante, og rigide kriterier, som ligger til grund.

Samtidigt kunne det være rart med en passus om at havarikommisionen kan foretage overfladiske gennemsyn af egen drift. - Men det får de nok ikke tid til de første 10år...

K

  • 0
  • 4
Claus Stovgaard

Er meget enig med Tommy, i at vi skal have klarlagt hvad der er korrekt og godt håndværk.

I forhold til analogien. Hvis du f.eks. ser på lovgivningen i forbindelse med boliger, så må jeg som beboer ikke bare lave ændringer som jeg lyster. F.eks. skal jeg have en elektriker autorisation, hvis jeg ønsker at sætte nye stikkontakter op på en væg. Og på samme måde må jeg ikke bare ændre bærende elementer i væggen som jeg lyster. En pilot der skal flyve har også en autorisation. Jeg kan ikke bare gå ud og lege pilot.

Så på hvilken niveau skal vi ligge autorisationer i forbindelse med IT, for at tilkendegive at man har den fornødne viden?

I forbindelse med en IT-havarikommission, vil jeg tro at der også skal defineres hvad der er godt håndværk, når der et givet styk software skal vurderes.

Hvis man ser mange af flystyrtene er problemet ofte en sammenblanding af flere ting. Det kan f.eks. være i selve flykonstruktionen, svarende til en fejl i forbindelse med design af softwaren. En fejl i forbindelse med vedligehold med indførsel af nye rutiner fra producenten, svarende til manglende opdatering af software. En pilotfejl, svarende til en fejl af systemadministratoren. En driftfejl hvor mekanikere påpeger at et fly ikke er klar til drift, men bliver presset af en driftchef til at sætte flyet i drift. Så jeg synes der er alt mulig grund til en IT-havarikomission. Ikke kun i forbindelse med design af software, men også i forbindelse med drift (hacking), og kompetance af de rigtige folk.

  • 2
  • 1
Poul-Henning Kamp Blogger

Hvis man ser mange af flystyrtene er problemet ofte en sammenblanding af flere ting.

Det er forkert at kigge på moderne havari-rapporter.

Du skal kigge på de første havarirapporter for at få et parallelt indtryk. Dengang var det meget ofte totalt idiotiske fejl, som f.eks ikke at fylde brændstof nok på. Løse skruer osv. osv.

  • 9
  • 0
Nicolai Møller-Andersen

Det er ikke nødvendigvis IT folkene, som ikke vil lære. Ofte er det en kulturting. Ledelsen kan simpelthen ikke se mening i at evaluere i en uge. Det er meget vigtigere at "komme videre", "ikke dvæle ved fortidens fejltagelser", "fokusere på de positive ting", "nå næste deadline", "lave noget ny forretning". Derfor aflyser ledelsen evalueringen. Når man har oplevet det cirka 12-25 gange, så lærer man at trække på skuldrene og kode videre med hovedet under armen.

  • 15
  • 0
Tommy Schouw

Jeg har læst både på IHK(diplom) i Ballerup og DTU(Civil). IHK var marginalt mere fokuseret på de grundlæggende teknikker, mens jeg havde meget svært ved at finde noget på DTU der rustede en til at være en bedre IT-håndværker. Det eneste der var lidt i den retning var algoritme kurser. De havde dog et ganske snævert fokus på beregningsmæssig optimering.

Det er selvfølgelig også vigtigt, det dækker bare ikke over simple ting som unit-testing, dokumentation, design patterns, læsbarhed af færdig kode, maintainability og andre ting som sjovt nok er utroligt vigtige når ens kode skal ud og leve i den virkelige verden.

  • 3
  • 0
Heine Andersen
  • 0
  • 1
Eskild Nielsen

I den typiske rapport er der en anaylyse af årsagen til det der skete, samt en anbefaling af ændret praksis.

Jeg læste en gang en spændende bog der hed noget i retning af 'Locomotive Boiler Explosions'. Den gav et klart billede af at de tidligste ulykker ikke altid blev undersøgt af folk der vidste hvad de havde med at gøre.

Resultatet var forskellige livsfarlige forsøg, samt horrible anbefalinger.

Ca 1880 begyndte det saglige overblik at tage over, og anbefalingerne blev gradvist mere anvendelige i praksis.

Hvis vi får PHK-udvalget nedsat i 2015, så vil vi måske i 2025 få brugbart output fra de aktuelle sager

  • 0
  • 0
Christian Nobel

OK. Hvordan lærer vi så at lade være med at lave systemer, der kører ad helvede til og koster mange penge at vedligeholde?

Vil det så sige at f.eks. rejsekortet og NemID ikke bør udsættes for en havarikommission, fordi de pt. "fungerer"?

Jeg undrer mig ret meget over at Henrik skulle have et kæmpe hak i tuden over dette.

For pointen er da helt valid, fuldstændig som e-valg diskussionen (som det så heldigvis lykkedes at afværge, men det er da vist også første gang i historien det er sket), nemlig at der "oppefra" er dikteret nogle systemer, som allerede burde være aflivet før man overhovedet havde sagt magisk it-sovs.

Men desværre sidder der jo så "deroppe" så stærke kræfter, at når det endelig kommer "ned på tekniker niveau", så er det for sent, og teknikerne (som måske ikke alle er i en situation hvor de bare kan løfte langemanden) har ikke andet at gøre end at rette ind, selv om de måske ved at det de skal lave ikke er bæredygtigt (det være sig moralsk, projektøkonomisk, samfundsøkonomisk, retssikkerhedsmæssigt, nytteværdi, etc, etc.).

Så det ville da være rigtig rart hvis IT folkene havde styrken (og de blev respekteret, bla. for deres kompetance, hvilket jo vi har set har dårlige kår) til at sige - nej sådan er det ikke bare.

Og jeg tror faktisk at der er rigtig mange der inde i deres hjerter frygtelig gerne vil sige at sådan er det ikke bare, men hvis konsekvensen af den udtalelse er dagpenge, så kan det jo godt være at der er mange der ikke siger det.

  • 3
  • 0
Carsten Larsen

Hvis der er noget der pisser mig af ved IT-folk, er det hverken hvide sokker i sandaler eller sproget og forkortelserne.

Giver det overhoved mening at tale om IT-folk ? For alle ikke-teknikker, er IT jo principelt set jo bare branche.

Og til faglig sammenligning: Hvor mange fly ingeniører findes der ift. IT ingeniører ?

Ideen er god. Jeg har bare svært ved at se hvordan det skulle være muligt at sammensætte en uvildig og habil komite.

  • 1
  • 1
Morten Bøgh

Det var Nietzche (tysk filosof, midt 1800-tallet) som satte sparket ind mod ortodoks religion. Ikke med sin påstand om at 'Gud er død', det kan enhver jo bare hævde, men med sin påstand om at menneskets sande natur ligger i et levende og evigt konfliktfyldt samspil mellem den lette rus og den ædru analyse, mellem fornuft versus følelse, mellem den dionysiske galskab og den appolinske fornuft. Hvis man accepterer det billede, så er der ikke plads til ortodoks religion - som netop går på at der kun er én dimension i livet (fornuften). Fornuft har det med at stivne og stagnere hvis det mister modspillet med følelsen og galskaben, den rene fornuft har svært ved at tage beslutninger fordi mavefornemmelsen, følelsen, mangler. Det sidste synspunkt tilhører moderne psykologi, og ikke Nietzsche, men kan understrege at han nok havde ret.
Holdningen 'Sådan er det bare' er vel netop den manglende evne til at tage beslutninger - beslutninger som rækker ud over 'det man plejer'.

Det der lukker diskussionen, er dog oftest det valgte software-framework, mere end det er manglen på beruset galskab. Det er frameworket som - ortodokst - siger 'sådan er det bare'. Fx et eller andet Java / dotNet setup som fx betragter MQSeries som et data-objekt i stedet for at åbne op mod alle aspekter af dette produkt. Med det resultat at projektet i den anden ende af kommunikationen må vride sin MQSeries behandling til det yderste for at kunne kommunikere med det her 'sådan er det bare' projekt som har mistet flexibiliteten.

Og: Ud over at jeg er ekstremt enig med PHK, så forstår jeg ikke at hans galde skal gå ud over fx JCL. Det der låser os fast, er en for massiv brug af frameworks som skjuler basale ting såsom JCL og SQL bag en rigid kodegenerering. Hvis du kan din JCL, kan du opbygge vilkårlige netværk af batch-processer, og det kan da ind i mellem være nyttigt. Fx når du skal spille sammen med andre projekters rigide frameworks. Og hvis du kan din SQL- Jesus Christ, så kører det.

Ok, JCL (JobControlLanguage) er som sprog betragtet et af verdens mest tumpede. JCL er et af de første sprog som - for 50 år siden - hævede sig lidt over assembler, og det udspringer af en holdning og af en tid hvor edb var højtideligt, og passende kunne understøttes af sprog som fjernede sig maksimalt fra en normal og forståelig syntax. Det skulle ikke være for nemt. Ligesom Windows (dvs DOS) brug af \ i filnavne: man bør da vælge et virkeligt specielt tegn for at markere det høje niveau. Det ville være fint med et moderne sprog til afløsning for JCL, men da et sådant ikke findes, kan det være fornuftigt nok at nogen sætter sig ind i JCL. Med mindre IBM føler sig ramt af PHK's tordenkile, og straks laver et sådant moderne sprog.

  • 3
  • 0
Christian Nobel

.. men et helt andet problem.

Ja, men uagtet hvordan vi vender og drejer den, så er karrene forbundne.

Det politiske problem skal løses af vælgerne, med stemmeblyanter.

Undskyld jeg siger det, men er du ikke en kende naiv her.

Teoretisk set har du ret, men i den virkelige, centralmagts dominerede verden, så er det bare ikke så nemt - desværre.

Det er kun det teknologiske og håndværksmæssige problem en IT-havarikommision kan hjælpe os med at løse.

Ikke uenig, men det fordrer at den så også har frie hænder til at operere, løftet over politiske og pekuniære betragtninger, og dens faglighed bliver respekteret (jeg mener vi skal have digitale valg, fordi jeg, selv om jeg ikke ved en skid om emnet, synes det skal være sådan, og it-folk ved jo ikke en skid, blah, blah, blah ....... og andre citater fra Bramsen og Vestager et al.), samt der vitterlig handles efter hvad den finder frem til.

Jeg støtter så sandelig op om ideen, men jeg er bare skeptisk overfor at den bliver kvalt politisk og af embedsmandsvældet - det er lidt nemmere når der har været dødsfald involveret, så stiger respekten for teknikernes viden (broen der styrter sammen) markant - desværre.

  • 5
  • 0
Martin Bøgelund

På overfladen synes jeg ideen med en havarikommission for IT-"ulykker" er god.

Selve implementeringen af en sådan havarikommission har jeg bare svært ved at forestille mig i konkret form. Umiddelbart forekommer det mig som en størrelse der er en kende mere kompleks end de andre havarikommissioner der findes, bl.a. fordi IT-løsninger, der kunne komme i betragting til en undersøgelse, jo alle mere eller mindre er unikke prototyper under konstant forandring, uden nødvendigvis at komme i "audit".

... dvs. i modsætning til en bilmodel eller en flymodel der havarerer, der jo typisk er massefremstillede og derudover har været igennem en ensartet godkendelsesproces, og jævnligt skal til syn.

Så for at få mere kød på snakken, vil jeg gerne have, at I der har en idé om hvordan sådan en havarikommission skal tage sig ud, laver et udkast til et kommissiorium og ridser procedurerne for undersøgelserne op (analysemetode mv.)

Kan I det?

  • 0
  • 0
John Jensen

PHK.
Er det ikke lidt i samme stil som den med "sådan er det bare" ?
Den holder ikke du er nødt til at forholde dig til det hele vejen rundt.
Accepter at det ikke er sådan og erkend at det er nødvendigt med AV software, og at det samtidig overordnet er dit problem at holde dit udstyr fri for Vira.

Som IT-Pro burde du efterhånden være klar over at er det muligt at byggen mur, så er det også muligt at bryde den ned.
Intet system er sikkert (sådan er det bare), men som du dog skriver man skal accepterer at man kan begå fejl lære lære af dem.

Intet system er 100% sikkert, man kan kun erkende at der kan opstå problemer og kun ved den erkendelse kan man høste endnu en erfaring og komme videre og så endda med lidt mere erfaring end tidligere, og derved bedre rustet end tidligere.

  • 0
  • 0
Poul-Henning Kamp Blogger

Så for at få mere kød på snakken, vil jeg gerne have, at I der har en idé om hvordan sådan en havarikommission skal tage sig ud, laver et udkast til et kommissiorium og ridser procedurerne for undersøgelserne op (analysemetode mv.)

Det er meget simpelt at komme igang:

Offentlige IT-projekter over EU-udbudsgrænsen skal betale 10% af projektbudgettet til ITHK som også tilsendes kopier af udbudsmaterialet og kontrakter.

Hvis projektet overstiger en af 10/10/10 grænserne nævnt ovenfor, skal ITHK underrettes og den kan vælge at iværksætte en undersøgelse, hvis den vurderer det er formålstjenligt.

Når projektet er afsluttet underrettes ITHK med oplysninger om det faktiske resultat (tid, penge, funktionalitet osv).

ITHK fører statistik over disse offentlige IT-projekter og statistikken offentliggøres, så leverandør performance kan blive et objektivt kriterie for fremtidige udbud.

De 10% fastlægges af Folketinget, der også kan give ekstrabevillinger og dermed styre aktivitetsniveauet.

Den ansvarlige minister kan pålægge ITHK at gennemføre en nærmere undersøgelse af et givent IT-projekt, herunder private IT-projekter involveret i lovbrud (tab af persondata f.eks).

Ingen kan forhindre ITHK at undersøge et givent offentlig IT-projekt af egen drift.

Det er nok til at komme igang, vi kan finjustere efterfølgende om nødvendigt.

  • 8
  • 0
John Jensen

Den med "sådan er de bare" skal så holdes op mod de mange gange en bruger eller en IT kollega udbryder "jeg er ligeglad med hvordan det fungerer, det skal bare virke".

Hvis de gider lytte får så den enkle forklaring på et niveau som de kan forstå, lad være med at trykke på vedhæftede filer fra ukendte brugere eller som du ikke forventer det fra osv. Eller lad være med at trykke på det og det på Facebook.
Men nej der er den type, de er få men de fylder rigtig meget.

Det er altid en afvejning hvordan man takler den enkelte bruger, men selv den mest tålmodige IT medarbejder kan få nok, og det er når man møder denne type ignoranter (ignoranter fordi de ikke VIL lytte).

Men dit indlæg med "sådan er det jo bare" kan jeg da stort set være enig i, selvfølgelig skal man ikke være bange for at erkende sine mangler både over for sig selv og over for den der spørger, det er utrolig så flinke brugere kan være over for en når man erkender at "den kendte jeg ikke lige", kun derved lære man mere, og så skal man også have forskergenet i sig, altså interessen for at finde ud af og derved lære endnu mere og faktisk komme eventuelle fremtidige problemer i forkøbet.

Jeg har været IT-Pro gennem 30+ år, og de sidste 8 år af min karriere, var nok den bedste, her fik jeg brugt evner jeg ikke anede jeg havde, de sociale evner, jeg må erkende jeg er en social nørd :-)

Det var på en folkeskole, umiddelbart skulle man tro det var en tilbagegang fra at sidde i maskinrummet, rende rundt mellem krydsfelter, og IBM's gamle AS/400, eller sidde ved Unix og skrive en eller anden grep kommando.

Men nej det var det bedste job jeg har haft.
Her lærte jeg en del som jeg ikke lige vidste tidligere, men især den med at jeg kunne have 42 elever i et lille lokale og fange alles interesse.

Den taknemmelighed der kom fra personale og elever, var utrolig, netop fordi jeg er modsat dem du skriver om "sådan er det bare" typerne.
Jeg lyttede og lærte. Og ingen mistede respekten for mig hvis der var noget jeg ikke kunne her og nu, de vidste jeg kom tilbage med svaret senere (når jeg selv havde lært det)

  • 1
  • 0
Martin Bøgelund

Det er meget simpelt at komme igang:

Offentlige IT-projekter over EU-udbudsgrænsen skal betale 10% af projektbudgettet til ITHK som også tilsendes kopier af udbudsmaterialet og kontrakter.

Allerede her vil jeg mene vi kommer i problemer. Når vi er over EU-udbudsgrænsen, kommer vi ind i det minefelt der hedder "tekniske handelshindringer".

Du kommer med andre ord straks i en situation hvor du skal sikre, at det er til gavn for "alle", og ikke bare statskassen, med en ITHK.

Og at du straks lægger en 10% prisforhøjelse på alle store IT-projekter, vil bestemt også rende på modstand. Men OK, finasieringen kan vi se på ved lejlighed...

Så skal vi også have ITHK lagt ind under et ministerium. Både Økonomi- og Indenrigsministeriet, og Ervhervs- og Vækstministeriet kunne være gode bud, men humlen er ikke så meget det konkrete ministerie. Humlen er nok mere at du kommer til at tildele det ansvarlige ministerie en magt over området, som du så fratager et andet ministerie som måske sender en opgave i udbud.
Og nej, magtspil mellem ministerier er ikke noget man kan ignorere sig ud af, eller slippe for ved at kalde DJØF'ere og politikere for idioter...
Det skal håndteres, og det bliver svært fordi IT er mange ting for mange ministerier. Her kan dine 10% af prisen hurtigt blive ædt op af bureaukrati, som vi jo alle mener skal være til stede pga offentlighedsloven...

Og hvis ITHK skal involveres i sager med tab af persondata, bliver du næsten også nødt til at skrue på Datatilsynets beføjelser, ja eventuelt helt nedlægge det for at dets opgaver kan overgå til ITHK - eller alternativt afgrænse ITHK's område, så det ikke kolliderer med Datatilsynets. Og vælger du det sidste, får du endnu sværere ved at få en ITHK der ikke fremstår som en teknisk handelshindring.

Jeg kan stadig se det positive i en ITHK på det abstrakte plan. Men på grund af en masse djævelske detaljer, så ligger den altså ikke lige til højrebenet, som andre havarikommissioner gør.

  • 3
  • 0
Martin Juhl Jørgensen

Der findes også Statens IT-projektråd der i følge hjemmesiden står for:

Ledelsesrådgivning med fokus på tidlig håndtering af risici i it-projekter

Det ser ud til at de ikke kigger på havarerede systemer -- kun havarerede projekter, i projektfasen.

Hvordan man får plads til Statens IT-projektråd, Datatilsynet og en IT-havarikommission er et godt spørgsmål.

Når det er sagt så mangler vi også at finde ud af hvorfor det næsten gik galt ved nærulykker (som forresten er ukendte for andre i IT branchen -- aktindsigt er svær at spørge om når man ikke ved at der har været noget galt).

  • 0
  • 0
Jesper Lund Stocholm Blogger

Jeg må indrømme, at selvom tanken om en IT Havarikommission er besnærende, så tror jeg heller ikke på den - af bla. de grunde, som nævnes her i de sidste kommentarer. Derudover synes jeg at "10/10/10"-tanken er grebet ud af luften og reelt synes jeg heller ikke, at en overskridelse på 10% i et projekt er noget problem i sig selv.

Til gengæld tror jeg på mere åbenhed. Jeg forstår ikke, hvorfor man ikke blot kræver, at senest ved projektafslutning - eller hvert år, for projekter, der varer længere tid - så offentliggøres produceret kildekode samt designdokumenter, referater fra møder etc fra alle projekter i den offentlige sektor.

Det virker på mig som en langt billigere måde end en havarikommission og vil skabe langt bedre mulighed for at kigge kunder og leverandører i kortene.

  • 1
  • 2
Søren Løvborg

Hvordan skulle ITHK blive en teknisk handelshindring? Det er køber der betaler de 10 %, og det gør de uanset hvem der vinder udbuddet. Man kunne jo evt. skrive ITHK-reglerne ind i udbuddet, omend det ville være lidt redundant; at overholde lokal lovgivning er vel givet.

Jeg kan heller ikke se det store overlap med Datatilsynet i sager om læk af private oplysninger.

Datatilsynet er en tilsynsmyndighed, der kontrollerer hvorvidt loven overholdes, og som har politianmeldelse som eneste sanktionsmulighed. ITHK's opgave ville være at undersøge hvorfor loven ikke blev overholdt, noget der helt uden for Datatilsynets virksomhed. ITHK har slet ingen sanktionsmuligheder, da det det udelukkende er dens opgave at udrede årsager til "havarierne".

  • 0
  • 0
Per Lauge Buresø Holst

I princippet har vi jo allerede set en eller flere havarikommissioner alt efter hvordan man ser på det:
* Bonnerup rapporten udkom i 2001, og den er der så ikke nogen, der har rettet sig efter.
* Polsag blev gennemgået af Rigsrevisionen, men dem er der vel heller ikke nogen, der retter sig efter denne gang.

Det er derfor min tanke, at man er nødt til at påkræve IT-revisionspligt af samtlige projekter til 10 mio. kr. og derover for at komme salget af Snake Oil til livs. Det ville så gå fint hånd i hånd med ITHK, der ville samle op - dels på kvaliteten af revisionen, dels på nye tiltag, der er påkrævet opmærksomhed.

I dagens Danmark kan man jo ikke åbne en pølsevogn uden at Levnedsmiddelkontrollen dukker op og foretager Smileyordning tjek. Ingen hussalg uden en tilstandsrapport. Ingen børsnoteret virksomhed uden revisionspligt. Men IT - det kan naboens knægt, chefens nevø, og alle de andre.

Certifikater - de er jo ikke mere værd, end som milepæl fra dengang de blev stemplet. Ligesom et kørekort ikke forhindrer folk i at udføre tumpede ting på kørebanen - og i øvrigt heller ikke sikrer, at de folk, der fører et køretøj rent faktisk har et certifikat.

Det er i øvrigt værd at læse Dijkstras "The Humble Programmer" fra 1972. Der er ikke sket meget siden dengang.

  • 1
  • 0
Log ind eller Opret konto for at kommentere