2021: Spættens År

For lidt tid siden holdt jeg et foredrag på Driving IT Århus, men da jeg ved at en stor del af mine læsere aldrig kunne drømme om at komme så langt ud i provinsen, tænkte jeg at det kunne være på sin plads at gentage hovedpointerne her.

Gerald Weinberger, sagde engang i min tidlige barndom: "Hvis vi byggede huse på samme måde som vi skriver programmer,ville den første spætte der kom forbi udslette civilizationen."

Præcis hvornår han sagde det er lidt uklart, det tidligste citat man har fundet er i 1975. I 1977 inkluderer Arthur Bloch det i hans lille bog "Murphy's Law and Other Reasons Why Things Go Wrong!", som min gode ven Helge havde købt i London og som jeg skyndte mig at fotokopiere. I 1987 blev det indskevet i BSD's fortune(1) fil.

Det er med andre ord en påstand der har haft god resonans med folk.

2021 var så året spætten dukkede op.

Listen over virksomheder der er blevet angrebet af ransomware vokser dag for dag og i stedet for at bruge en masse energi på at finde ud af om det er en Leuconotopicus albolarvatus eller en Dendrocopos hyperythrus eller måske et helt tredje medlem af Picinae, er der folk og særligt politikere der er begyndt at lede efter nældens rod og hvis der nogen i branchen forventer at den her shit-storm blæser over uden forandringer, er særligt de for inkompetente til deres job.

Præsident Biden har allerede fulgt min anbefaling og nedsat en IT-Havarikommission.

I Danmark er 129 job lovregulerede, fra dyrehandler til certificerede statikere[1], mens der er totalt fri skydning i det muntre køkken indenfor IT.

Vandhanerne og afløbet i selvsamme muntre køkken har en lovreguleret "Fagligt ansvarlig inden for gas-, vand- og afløbsinstallationer (afløb i bygninger og over jord)(vvs-installatør)" naturligvis taget ansvaret for.

Den pointe har efter sigende god pædagogisk rækkevidde hos politikere: Der blev stillet større krav til dem der installerede vandhanerne hos Colonial Pipeline, end til dem der lavede det IT system som kontrollerer op imod halvdelen af energiforsyningen til det Østlige USA.

Nu er det op til os, som branche og som professionelle, at beslutte om vi vil have indflydelse på den lovregulering der helt sikkert er på vej, eller om vi med korslagte arme, som sædvanlig, opfatter os selv som højt hævet over mudderkasteriet i den politiske arena.

/phk

[1] Dem der regner ud om bygninger og bygværker kan holde til at stå ude om natten.

Kommentarer (72)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Morten Fordsmand

I udvalgte brancher (finans, energi, etc.) omkring kontrollen med vores IT systemers robusthed. Lige som revisorer har arbejdet med systemrevision næsten så længe som jeg husker.

Om det så virker godt nok er nok et helt andet spørgsmål, i hvert fald er de utallige synlige brud på it-sikkerhed ikke beroligende.

Om der er brug for en autorisation er derimod nok ikke en god ide, da der allerede findes utrolig mange akronymer, der skulle underbygge at folk kan holde styr på tingene.

  • 0
  • 0
#2 Klavs Klavsen

Jeg ville da forvente/håbe at det der kom - ville mere i stil med et bygningsreglement, der løbende bliver fornyet? Det ville IMHO være den eneste rigtige måde at gøre det på.. at forsøge at kvantificere "hvad der virker" - og simpelthen kræve det i "relevante software byggerier"

og så skal der være nogen i stil med Statens byggeforsknings Institut (SBI) - der undersøger og rådgiver om hvad der bør putttes i BR.. (kunne meget vel være en form for havarikommission - eller skulle tage input fra en sådan kommission).

  • 3
  • 0
#3 Klavs Klavsen

Der er en ganske glimrende IT revision - jeg ihvertfald selv har skullet prøve at bestå.. De er ikke helt skæve :)

Meget få firmaer bliver dog IT revideret - og det er desværre ikke "perfekt".. Der er mange ting de ikke kigger på, og krav der mest er af papirmæssig karakter og ikke giver reel sikkerhed.

  • 2
  • 0
#4 Klavs Klavsen

Kunne være et simpelt krav i et sådant BR - samt en specifik metode det skal bevises at det ER på plads..

Så man er tvunget til at checke alle sine docker images, VMs etc. for software versioner - og kunne afrapportere versioner der anvendes ? og så med en stik prøve kontrol blandt de listede systemer - og en nmap scanning + k8s/docker-image liste - til at sammenholde at de afrapporteret - også stemte overens med de fundne systemer ?

Lyder som en forholdsvis standardiseret test en IT-revisor kunne foretage - på baggrund af et sådant krav.

  • 2
  • 0
#5 Torben Mogensen Blogger

Nogle af de beskyttede erhverv (f.eks. aktuar og læge) kræver en særlig videregående uddannelse, mens andre (f.eks. dørmand i virksomheder med alkoholbevilling) "blot" kræver certificering og nogen gange ren straffeattest. Hvad havde du (PHK) tænkt dig som krav til softwareudviklere, testere eller deres ledere?

  • 10
  • 0
#6 Povl H. Pedersen

Der er masser af regulering. Både af finansielle systemer, persondataloven og GDPR m.m.

GDPR sikrer at data ikke kommer til 3die mand uden databehandleraftaler, og at de ikke ændres/mistes.

Så ingen persondata cryptolockes eller exfiltreres såfremt [GDPR] loven er overholdt.

At virkeligheden så viser noget andet er en anden sag, men lovgrundlaget er på plads.

Og ved statslige udbud var CIS-20 på et tidspunkt en referenceramme man kunne plukke krav fra. Nu er CIS-20 så afløst af CIS-18 i en virkelige verden.

Nu har jeg selv kæmpet med compliance, og der er mange krav der kun eksisterer for deres egen og bureaukratiets skyld.

Og generelt i compliance er der mange fluffy krav, da man laver politikker der skal holde i mange år. Så de nævner IKKE at man kun må bruge kryptering xyz eller man SKAL slå RC4 fra. Så det er op til læseren at fortolke sit compliance niveau.

Bygningsreglementet gælder kun nybyggeri. Softwarereglement skal også gælde gamle systemer. Og stille krav til end-of-life produkter. Og hvad der er nok her svinger nok meget ! Netværksmæssig isolation - Men det kan man heller ikke altid 100%. Så kun udgående trafik, egress filtering (ingen bred Internetadgang) etc.

  • 2
  • 0
#7 Ditlev Petersen

Vi kunne også lave lidt mindre. Altså lave tingene i et rimeligt tempo. Så vi har tid til at lave dem ordentligt i stedet for at "hente" noget, vi ikke kan gennemskue og så bare slette kode, til det kan køre.

Groft sagt men alligevel. Så kvalitet og sikkerhed var noget, der ganske naturligt var med, når en kunde bestiller et system. For så vil leverandørerne på en eller anden måde være nødt til at dokumentere, at de har styr på tingene (og har folk, der kan det p..).

I dag har jeg indtryk af, at manglen på udviklere er så stor, at tingene af og til bliver jasket igennem (Rejsekort, Info om Letbanen og meget andet). Og at industrien råber på udviklere med kortest mulige uddannelse, helst direkte fra børnehaven (I ved hvad jeg mener - håber jeg).

  • 8
  • 0
#8 Jakob Tolstrup Hansen

Hvorvidt bygninger kan holde til at stå ude om natten er bygningsfysik og traditionelt arkitektarbejde.

Statikere regner på om bygninger står nogenlunde stille når det blæser, ikke synker (for meget) i jorden og ikke falder (ret meget) sammen under jordskælv, brand (de første ½-2 timer) og tidens tand (ihvertfald ikke inden for 50-120 år).

  • 7
  • 0
#9 Nis Schmidt

Vandhanerne og afløbet i selvsamme muntre køkken har en lovreguleret "Fagligt ansvarlig inden for gas-, vand- og afløbsinstallationer (afløb i bygninger og over jord)(vvs-installatør)" naturligvis taget ansvaret for.

Lovregulering har hidtil ikke afholdt folk fra at opleve badeværelser, hvor afløbet ikke er det laveste punkt på gulvet :(

Allerede før min frankofile udstationering underholdt en af min kolleger med den lange historie om sit badeværelsegulv og så sendt som 2020 ramte en renovering min bonusdatter og hendes daværende kæreste i deres ny-erhvervede/renoverede hus i Nærum.

Lovbrud og sjusk forekommer! PHK tror f.eks. efter eget udsagn (i denne blog) på, at videnskabelige (klima-) modeller er optimalt implementeret. I 2016 gav en dansk professor udtryk (på ing.dk) for at 100% optagede CPUer var 'ensbetydende' med "optimal" implementering.

Hvordan mon freebsd vil klare et kodeeftersyn? Hidtil har det ikke vist at noget har ændret sig (væsentligt) i BSD siden 1990erne.

Statisk optimering virker ikke, hvis bineries kører på anden hardware end den, der var udviklet til/på. Værre endnu, hvis der kører anden software samtidig med "den statisk optimerede" kode.

  • 5
  • 5
#12 Palle Simonsen

De fleste med en uddannelse indenfor Computer Science eller tilsvarende har lært, at udvikling af SW ikke er en eksakt videnskab som f.eks. megen anden ingeniørkunst, hvor statikere og andre kan benytte sig af nogenlunde deterministiske modeller. Derfor er man nødt til at anvende udviklingsmetoder der minimerer risikoen for fejl såsom testdrevet udvikling etc. SW engineering, som feltet hedder, udvikler sig hele tiden og vi får bedre metoder og bedre værktøjer - men det er ikke eksakt ingeniørkunst.

Hvis man har min alder har man dels prøvet kvalitetssikringssystemer og sikkerhedscertiferingser der ikke garanterede kvalitet eller sikkerhed - kun procedurer og ensartethed og man har prøvet faglige certiferinger der belønnede udenadslærer men ikke kunnen.

Så, hvad er det for en lovgivning og/eller authorisationsregime som skal kunne garanterer, at man hvis man følger disse, får bedre / billigere / hurtigere osv. SW udvikling / Færre sikkerhedsproblemer?

  • 7
  • 0
#13 Ole Kaas
  • 0
  • 4
#15 Poul-Henning Kamp Blogger

Om der er brug for en autorisation er derimod nok ikke en god ide, da der allerede findes utrolig mange akronymer, der skulle underbygge at folk kan holde styr på tingene.

En statsautorisation medfører som hovedregel A) et krav om at du er ansvarlig, i juridisk forstand, for det arbejde du udfører og B) et krav om at du har en ansvarsforsikring der dækker de skader du forvolder.

Det kan absolut ikke sammenlignes med fire bogstaver der alene siger at du har betalt et stort firma for et stykke vægdekoration.

  • 18
  • 0
#16 Poul-Henning Kamp Blogger

Hvad havde du (PHK) tænkt dig som krav til softwareudviklere, testere eller deres ledere?

At dem der beslutter hvad der er "godt nok" står på mål for deres beslutning med et juridisk ansvar og en ansvarsforsikring, på samme vis som el-, gas-, vand-, kloak-, køle- osv. installatører.

Der bør også være en ordning på linie med de statsanerkendte statistikere, således at IT-systemer "af høj konsekvensklasse" bliver gennemgået med tættekam for at sikre at de kan holde til at blive koblet på internettet.

  • 15
  • 0
#17 Poul-Henning Kamp Blogger

De fleste med en uddannelse indenfor Computer Science eller tilsvarende har lært, at udvikling af SW ikke er en eksakt videnskab som f.eks. megen anden ingeniørkunst

Den påstand er helt ude i "ikke engang forkert" territoriet...

Grunden til at ingeniører regner så meget som det gør, er præcist fordi det du kalder "ingeniørkunst" heller ikke er en exakt videnskab.

Det eneste magiske ved IT er branchens umodenhed og aversion imod at påtage sig noget der bare minder om en form for ansvar for konsekvenserne af deres handlinger.

  • 27
  • 1
#18 Poul-Henning Kamp Blogger

Så, hvad er det for en lovgivning og/eller authorisationsregime som skal kunne garanterer, at man hvis man følger disse, får bedre / billigere / hurtigere osv. SW udvikling / Færre sikkerhedsproblemer?

Problemet er primært at SW udvikling er alt for billigt, fordi der ikke er skyggen af ansvar for dem der gør det.

Om noget er løsningen at skrive langt mindre men langt mere gennemtænkt software.

  • 18
  • 0
#20 Palle Simonsen

Grunden til at ingeniører regner så meget som det gør, er præcist fordi det du kalder "ingeniørkunst" heller ikke er en exakt videnskab.

Forkert PHK - et kredsløb eller f.eks. en reguleringsopgave kan beskrives fyldetsgørende med en matematisk model, hvilket gør det deterministisk til en grad at man kan beregne og bevise. Dette er kun teoretisk muligt for SW - aka Petri Net, Lamda Calculus etc. og man kan stadigvæk ikke bevise korrekthed på samme deterministiske måde som f.eks. regulering (se Halting Problem).

Og når vi nu er i fakta afdelingen så har alle IT virksomheder, som jeg kender til, en ansvarsforsikring. Feks. en rådgiverforsikring der fækker sålænge man rådgiver indenfor de af forsikringen dækkede områder.

  • 4
  • 13
#21 Christian Nobel

Det står vel i tilstandsrapporten

Du kan være rimeligt sikker på at negativt fald på et badeværelsesgulv ikke bliver fanget af vennen-der-er-blevet-begunstiget-til-at-skrive-en-uhyrlig-regning for et stykke arbejde der som regel er lige til at lukke op skide i, ikke bliver fanget.

Men er der ikke gelænder på en trappe, så er bygningen åbenbart i fare for at kollapse.

  • 5
  • 1
#22 Christian Nobel

mindre men langt mere gennemtænkt software.

Men i det spil hjælper det jo så ikke at der kommer et nyt og åh-så-værd-at-hype sprog på banen nærmest hvert år.

Se bare placeholderen her, hvor tit der skrives om et nyt og fantastisk sprog.

Måske det allerbedste ville være at slå bremsen i, bruge tiden på at tænke sig om, og så benytte de (vel)kendte værktøjer man har, i stedet for hele tiden at proppe flere og flere (ikke gennemprøvede) værktøjer og bizarre frameworks i værktøjskassen.

  • 5
  • 0
#24 Poul-Henning Kamp Blogger

Forkert PHK - et kredsløb eller f.eks. en reguleringsopgave kan beskrives fyldetsgørende med en matematisk model, hvilket gør det deterministisk til en grad at man kan beregne og bevise. Dette er kun teoretisk muligt for SW

Ja, der er trivielle og rutinemæssige ingeniørproblemer og der er dybt abstrakte intelektuelle CS problemer, men hvorfor sammenligner du dog dem ?

Lad os sammenlign æbler med æbler:

Der bygges typehuse i tusindvis og det er med rette en sensation hvis et af dem falder sammen.

Der laves også IT installationer i tusindvis og det er nærmest en senstation hvis en af dem ikke bliver ramt af malware i en eller anden form.

Kig f.eks lidt højere oppe på siten, der finder du en virksomhed der har vurderet at det er effektivt at reklamere med en PC der ikke er blevet angrebet.

Vi behøver ikke at vide yderligere om hverken P, NP eller Halting Problem for at bygge bedre IT, det er ikke rocket science, det eneste der er til hinder er den fundamentale markedsfejl at IT folk ikke bliver tvunget til at levere kvalitet.

  • 22
  • 1
#27 Ditlev Petersen

Forkert PHK - et kredsløb eller f.eks. en reguleringsopgave kan beskrives fyldetsgørende med en matematisk model, hvilket gør det deterministisk til en grad at man kan beregne og bevise.

Men det gælder vel ikke for alle ingeniør-opgaver? Når man er ude i noget nyt, er der næppe den store erfaring at trække på. F.eks. var den italienske bro, der faldt ned for et par år siden, god nok - sådan rent statisk. Men der har nok ikke været nogen modeller for, hvordan sådan noget skulle vedligeholdes eller om det overhovedet var forsvarligt.

Man kan også med meget hårdt arbejde bevise, at en algoritme holder eller at noget sw overholder specifikationen. Men det er meget tidskrævende. Og man kan som bekendt ikke dokuemntere, at specifikationen er fornuftig.

  • 1
  • 0
#28 Poul-Henning Kamp Blogger

Imo er der tale om direkte bedrageri når vi f.eks. taler Njals tårn.

Jeg har mødt folk fra mange andre brancher der omtaler IT-branchen som det rene bedrageri, så jeg synes sammenligningen er glimrende ?

De fleste større IT-systemer bliver overdraget til kunden selvom leverandøren er fuldt bekendt med mangler der er langt værre end dem der hidtil er dokumenteret for Njals Tårn.

Ikke at det på nogen måde undskylder Njals Tårn, tværtimod, det er sådan set præcis derfor sammenligningen er så god.

  • 11
  • 1
#30 Poul-Henning Kamp Blogger

Man kan også med meget hårdt arbejde bevise, at en algoritme holder eller at noget sw overholder specifikationen.

Men hvor tit er det nu også lige det er nødvendigt at gøre det, for at levere et program til bogføring ?

Bogføring som vi udfører den idag, blev opfundet i 1300 tallet og adskiller sig ikke på nogen måde derfra, hverken med hensyn til matematiske operationer, procedurer eller revisionsmuligheder.

Reminder: Colonial Pipeline angrebet ramte deres bogføringssystem.

  • 13
  • 0
#31 Christian Nobel

Der bygges typehuse i tusindvis og det er med rette en sensation hvis et af dem falder sammen.

Der laves også IT installationer i tusindvis og det er nærmest en senstation hvis en af dem ikke bliver ramt af malware i en eller anden form.

Men hvis nu de tusindevis af typehuse allesammen blev funderet med samme beton, fra et og kun et firma, som havde egenskab der gjorde at den kunne skifte tilstandsform til kviksand bare ved at prikke til den med en skruetrækker, så ville du nok se en hel del flere typehuse falde sammen.

  • 1
  • 1
#34 Poul-Henning Kamp Blogger

Men hvis nu de tusindevis af typehuse allesammen blev funderet med samme beton, fra et og kun et firma, som havde egenskab der gjorde at den kunne skifte tilstandsform til kviksand bare ved at prikke til den med en skruetrækker, så ville du nok se en hel del flere typehuse falde sammen.

Korrekt, så spørg dig selv hvorfor det ikke sker ?

Skal vi starte med at der stilles krav til cementen, stenene, vandet, sandet, blandeanlægget, lastvognen, udgravningen, udstøbningen, armeringen, vejret og arbejdets kvalitet.

Eller skal vi fokusere på at alle involverede er juridisk ansvarlige for deres handlinger?

Burde der ikke, på samme vis som med bygningsreglementet, stærkstrømsloven og alle de andre branchers regulering, være et lovkrav til operativsystemer om at de er uden bagdøre og at leverandøren er ansvarlig for alle direkte og indirekte skader hvis dette forbud ikke overholdes ?

  • 14
  • 0
#36 Poul-Henning Kamp Blogger

Og gjorde det så det?

Ramte det ikke nærmere i et af det underliggende operativsystems utallige usikkerhed, parret med en generel mangel på sikkerhedsforståelse?

Hvis dit typehus falder sammen om ørene på dig, hvor meget fokuserer du så på om det var fundamentet, væggene eller tagkonstruktionen der svigtede først ?

Hvis typehusleverandøren brugte en for dårlig underleverandør, må de handle det af bagefter, det er typehusleverandøren, som sådan, der har ansvaret overfor køberen af huset.

  • 7
  • 0
#39 Christian Nobel

Hvis dit typehus falder sammen om ørene på dig, hvor meget fokuserer du så på om det var fundamentet, væggene eller tagkonstruktionen der svigtede først ?

Jeg fokuserer nok primært på at komme ud.

Hvis typehusleverandøren brugte en for dårlig underleverandør, må de handle det af bagefter, det er typehusleverandøren, som sådan, der har ansvaret overfor køberen af huset.

Fuldstændig korrekt, men det du er ude i er at det er tagdækkerens (som har leveret et perfekt arbejde) skyld at huset bryder sammen, og at han skal have certificering, og hvad ved jeg, for at kunne tage højde for at fundamentet er lavet forkert.

  • 0
  • 4
#40 Poul-Henning Kamp Blogger

Fuldstændig korrekt, men det du er ude i er at det er tagdækkerens (som har leveret et perfekt arbejde) skyld at huset bryder sammen, og at han skal have certificering, og hvad ved jeg, for at kunne tage højde for at fundamentet er lavet forkert.

Nej, jeg er ude i at både ham der laver fundamentet, væggene, elinstallationen, vandet, gassen, tagkonstruktionen og tagbelægningen skal have en autorisation så kunderne kan have tiltro til at de ved hvad de laver og sikkerhed for at de har en forsikring der betaler hvis det viser sig at de ikke gjorde.

  • 8
  • 0
#41 Christian Nobel

Nej, jeg er ude i at både ham der laver fundamentet, væggene, elinstallationen, vandet, gassen, tagkonstruktionen og tagbelægningen skal have en autorisation så kunderne kan have tiltro til at de ved hvad de laver og sikkerhed for at de har en forsikring der betaler hvis det viser sig at de ikke gjorde.

Så vi er altså ude i at du mener at alle der flytter den mindste bit skal have en autorisation?

Hvordan har du tænkt dig det skal udmøntes i praksis?

Og hvem skal definere hvad der er rigtigt eller forkert?

I min primitive verden kunne jeg jo sagtens sige at man ikke kunne få en autorisation, hvis man baserede sin udvikling på et OS fra et bestemt firma, men sådan spiller klaveret jo ikke.

Og hvad nytter det hvis jeg laver et program, som isoleret set er 100% i orden, hvis det efterfølgende indhylles i en verden som ikke er sikker.

Jeg kan sagtens forstå hvor det gerne er du vil hen, men at sammenligne det med byggeri mener jeg bare er en utæt skrutrækker.

  • 4
  • 1
#42 Poul-Henning Kamp Blogger

Så vi er altså ude i at du mener at alle der flytter den mindste bit skal have en autorisation?

Igen: Kig på byggebranchen: El-installatøren har en autorisation som alle hans medarbejdere arbejder under. Det er hans ansvar at de gør arbejdet korrekt og forsvarligt.

Hvordan har du tænkt dig det skal udmøntes i praksis?

I praksis sker det gennem lovgivning, det er nærmest rutinearbejde for dem, jvf. de 129 erhverv der allerede er reguleret.

Og hvem skal definere hvad der er rigtigt eller forkert?

De fleste af de tekniske normer vi har her i landet startede som frivillige arbejder i de forskellige ingeniør-foreninger og de blev senere ophævet til lov, fordi de var lavet fornuftigt.

Den dør står muligvis stadig åben for IT branchen, hvis vi skynder os og faktisk tager opgaven seriøst.

  • 9
  • 2
#43 Nis Schmidt

@28:

Jeg har mødt folk fra mange andre brancher der omtaler IT-branchen som det rene bedrageri, så jeg synes sammenligningen er glimrende ?

Tilbage i firserne sagde vores software (produkt) manager, at man "når som helst" kunne få en dommer til at fastslå, at de var bugs i software.

Mit job var at vurdere (teste) om kunderne havde ret og yde dem den dermed forbundne service (patch eller næste version). Senere kom jeg selv til at udvikle patches. Husker særlig et tilfælde, hvor jeg havde reserveret bytes i stedet for (som jeg troede) words; systemet "gik ned" på få sekunder, da vi tændte klienterne samtidig med serveren. Kunne dog hurtigt rette "fejlen" via en bagdør (og debugger), da jeg rebootede serveren. Resten af "det italienske onsite" job forløb forbløffende gnidningsløst, jeg behøvede knap at hviske, hvis jeg så et problem: så blev det rettet - eller midlerne til at gøre det skaffet;)

@13:

Det står vel i tilstandsrapporten - og så har man jo overtaget klampet med åbne øjne. Ellers kan man tage fat i sin ejerskifteforsikring.

I begge tilfælde var der tale om nyrenoverende badeværelsegulve (og "arbejdet" var udført mens beboerne var på job). Så ingen af dem havde "overtaget noget klamp"!

  • 3
  • 0
#44 Jakob Tolstrup Hansen

Vrøvl, i byggeriet er mester ansvarlig og uddannet til det han laver (jævnfør titlen mester) Men man skærper reglerne for ansvarlighed indenfor afløb, drikkevand og strøm via personlige certificeringer (med prøver), og for nylig er man begyndt at aftvinge den ansvarlige for brand og konstruktionssikkerhed at de også kan bestå en prøve (tidligere en fagfælle bedømmelse iht. standsforeningen).

Det gælder på et overordnet niveau, det er altså den der planlægger og tester systemet der skal have en passende uddannelse, og ikke dig der bare skruer plader op, hvor essentielt det end er.

At en udførende fagmand skal have en certificering der kan forsvinde, så det ikke kun er økonomien der har hånden på kogepladen gør rigtigt ondt, især når man er afhængig af andres arbejde.

  • 6
  • 0
#45 Sven Waskönig

Et af problemerne i branchen er stadig, at rigtig mange stadig betragter IT-løsninger som noget, der kan laves af semi-professionelle nørder og man betragter den selvlærte IT-mand, hvis faglige viden er begrænset til det, han har fået via Youtube, som "professionel nok", selvom vedkommende hverken kan fremvise uddannelse eller kursusbeviser.

F.eks. oplevede jeg en mellemleder i et større dansk selskab udtale, at man faktisk havde brug for en masse programmører til at udvikle apps, men i stedet for at starte med at få fat i de nyuddannede, der i det mindste har en relevant uddannelse, ville man satse på at få fat i "en af dem, der har nørdet med det i sin fritid". Så man vælger hellere en hobby-programmør, end en, der har valgt det som sin levevej... Det er sikker også billigere, i hvert fald på kort sigt.

Jeg tror, at rigtig mange IT-afdelinger rundt omkring er godt og grundigt underbemandende og forhold til, hvad man burde bruge af tid på at få løst tingene ordentligt. Når arkitekter, ingeniører og tekniske tegnere støder på et problem i forbindelse med et byggeri, så tænker de sig godt om, snakker om det og tager en kvalificeret beslutning. I IT-branchen er man vant til, at når noget går galt, kan man bare genstarte serveren - groft sagt.

Det bliver ikke godt nok, før man investerer de ressourcer, der skal til: der skal være folk nok, de skal vide nok og de skal have tid nok.

Men det er let for alle andre end IT-folk, herunder lederne, at tro, at IT bare er plug-and-play, for sådan er det hjemme i privaten. Vi, der sidder i maskinrummet og har skruet løsningerne sammen, ved godt, hvor de svage punkter er. Og er man professionel nok, så ved man, hvornår man ved for lidt.

Indtil nu har det været sådan, at når et højhus vælter, så kommer det på forsiden af adskillige medier. Men hvis et større firmas IT svigter, kommer det kun på forsiden af Version2 og Computerworld - og måske Børsen. I alle andre medier, skal man lige klikke sig lidt længere ind.

Det ændrer sig først den dag, hvor firmaer nok bliver ramt på deres IT. Om det så sker i år - måske. Jeg er bange for, at holdningerne til IT og IT-folk er ret sejlivede.

  • 8
  • 0
#46 Ole Kaas

Det står vel i tilstandsrapporten

Du kan være rimeligt sikker på at negativt fald på et badeværelsesgulv ikke bliver fanget af vennen-der-er-blevet-begunstiget-til-at-skrive-en-uhyrlig-regning for et stykke arbejde der som regel er lige til at lukke op skide i, ikke bliver fanget.

Men er der ikke gelænder på en trappe, så er bygningen åbenbart i fare for at kollapse.

Så må du jo anmelde sjusket til din ejerskifteforsikring. Så må de afgøre om det skal have konsekvenser for den der udførte ejerskifteforsikringen.

Det burde ihvertfald være sådan - jeg har endnu ikke været så langt, at få en skade afvist og dermed skulle have fat i min retshjælpsforsikring for at gå efter ejerskifteforsikringsselskab eller efter tilstandsrapportens ophav for mangelfuld udførelse.

Jeg er enig i at tilstandrapporterne har et blakket ry - men det skyldes nok er der er ret få konsekvenser for dem der laver dem når rapporterne er mangelfulde og forkerte.

  • 2
  • 1
#47 Christian Nobel

Så må du jo anmelde sjusket til din ejerskifteforsikring. Så må de afgøre om det skal have konsekvenser for den der udførte ejerskifteforsikringen.

Meget muligt, men det løser ikke noget problem.

Det der skal til er at der ikke laves gulve med negativt fald, og der ikke laves usikkert software - og begge dele kræver et ændret mindset, og at der tænkes, før man går i gang!

Og i det spil er ordninger, hvor der er nogen der har et ansvar, som Jakob beskriver, den rigtige vej at gå - desværre går det så stadigvæk galt mange steder.

Nu skal det så iøvrigt bemærkes at det negative fald som regel skal tilskrives murerarbejde, hvor der ikke er nogen der direkte har hånden på kogepladen.

  • 4
  • 0
#48 Jorgen Hansen

Certificering og standarder kan være udmærket, men misbrugs ofte til at beskytte monopoler ved at gøre konkurrenternes adgangsbillet til markedet urimelig dyr. Hvad hjælper autorisation for gas, vand, kloak og el når ingen myndighed godkender arbejdet, det er blot privilegier fra tiden med lav. Eller tænk blot på sagaen om jordforbindelsen i en dansk stikkontakt. Vi skal tænke os gevaldigt om før vi vedtager regulerende lovgivning for IT og udskifter ansvaret for sikkerhed fra cand polyt til cand polit segmentet.

  • 2
  • 0
#49 Poul-Henning Kamp Blogger

Certificering og standarder kan være udmærket, men misbrugs ofte til at beskytte monopoler ved at gøre konkurrenternes adgangsbillet til markedet urimelig dyr.

Når staten udsteder autorisationer er det netop guleroden: Hvis du opfylder flg krav får du lov til at sælge til et konkurrencebeskyttet marked.

Det siger sig selv at staten skal holde skarpt øje med prisdannelsen på disse markeder og det gør de også.

  • 3
  • 2
#50 Poul-Henning Kamp Blogger

Hvad hjælper autorisation for gas, vand, kloak og el når ingen myndighed godkender arbejdet, det er blot privilegier fra tiden med lav.

Du har helt misforstået hvordan ting virker: Bare fordi du slipper afsted med det i første omgang (= hvordan IT branchen virker) slipper gas-, vand-, kloak- og el-installatørene ikke af med deres ansvar.

Hvis du køber et nybygget hus og det senere opdages at elinstallationen ikke lever op til kravene på det tidspunkt den blev udført, har sælger pligt til at udbedre dette og der er i princippet ingen forældelsesfrist.

  • 9
  • 1
#51 Jorgen Hansen

Store komplicerede IT systemer er som store anlægsarbejder, od uden at kende detaljerne i "Niels Bohr Huset" på Jagtvej i København, er jeg sikker på at gas, vand og el folkene står i kø ved håndvasken, og bygherrer må op med adskillige hundrede millioner ekstra. At staten holder øje med monopoler er der mange eksempler på ikke virker.

  • 6
  • 0
#52 Ivan Skytte Jørgensen

I 1975 blev det er krav at nye bolig installationer skulle beskyttes af et HFI. Eksisterende boliger skulle ikke udstyres med HFI medmindre der blev lavet en større ændring i elinstallationen. Staten sendet ikke tusindvis af elektrikere ud for at skifte eksisterende installationer. Senere er kravene ændret i 1993, 2006 og 2008 så sikkerheden er gradvist blevet hævet.

Jeg synes at flere indlæg i denne debat totalt ignorerer at der er tonsvis af software, som kører og ikke opfylder moderne krav til sikkerhed, kvalitet, auditering, ... samt at vi ikke har kapaciteten til at rette op på alt inden for et årti. Vi bliver nødt til at gradvist forbedre dem.

  • 7
  • 0
#53 Benjamin Kristensen

Men hvis nu de tusindevis af typehuse allesammen blev funderet med samme beton, fra et og kun et firma, som havde egenskab der gjorde at den kunne skifte tilstandsform til kviksand bare ved at prikke til den med en skruetrækker, så ville du nok se en hel del flere typehuse falde sammen.

Sjovt du siger det, jeg snakkede med en murer for ikke så længe siden som nævnte noget om at de havde bygget nogle typehuse (tror det var under 20) som allesammen nu havde problemer fordi det mørtel der var brugt var dårligt fra fabrikanten, og nu var det uklart hvor ansvaret lå, og hvodan de skulle få rettet op på det. Jeg kan ikke huske mere specifikt lige hvordan og hvorledes, det er nogle måneder siden, men det sker åbenbart

  • 1
  • 0
#55 Michael Cederberg

Der er ingen tvivl om at vi har brug for at hæve kvaliteten herunder sikkerheden.

Problemet er hvordan man gør det uden at banke omkostninger op. Hvordan sikrer vi at regler ikke bliver idiotiske. Der er fx ingen tvivl om at man må stille højere krav til et system der håndterer dybt private informationer i forhold til så meget andet. Hvis man stiller samme krav til alt så kommer vi ingen vegne.

Læg oveni at folk har en tendens til at gå efter nemt målbare krav. Tag fx. statisk kodeanalyse. Jeg har aldrig set det fange en eneste seriøs fejl (men det sker sikkert). Jeg har set det fange nogle få mindre kritiske fejl. Alligevel bruger mange det som metrik for kodekvalitet selvom det intet siger om hvorvidt koden gør som den skal, om den nemt kan udvides, om det er modularliseret fornuftigt, om der er truffet fornuftige teknologivalg, etc.

Vi har også en smoke-and-mirrors IT-sikkerhedsbranche som typisk finder de mest latterlige fejl som man selv kan finde blot med en smule omhyggelighed og viden. Alligevel anser mange IT-sikkerhedsbranchens reviews som indikation på at der ingen problemer er.

Alle IT-folk skal forstå IT sikkerhed. Alle IT folk skal forstå IT kvalitet. Alle der køber IT skal stille krav om ovenstående. Hvis man forventer at generaliserede kvalitetskrav vil løse problemerne så tager man fejl. Men det giver sikkert en rar følelse i maven.

  • 2
  • 0
#57 Michael Cederberg

Hvem har sagt at omkostningerne ikke kan eller må stige ?

Jeg tror såmænd ikke der sker noget ved at software bliver 10-20% dyrere. Det vil betyde at der kommer til at mangle endnu flere IT folk på kort sigt men det overlever verden såmænd nok også.

Men jeg tænkte mere på at hvis alt software ender med at koste 3-4 gange så meget så bliver der mange steder hvor det ikke giver mening. Hvor vi kommer til at "mangle" automatisering af forretningsfunktioner fordi automatisering bliver for dyrt. Hvis software design og udvikling ender med at drukne i dokumentation (i stil med NASA eller Airbus), så vil det ødelægge agiliteten for teams fordi de alt skal være store. Måske slå små software virksomheder ihjel.

Hvor mange virksomheder med 5 ansatte finder i medicinalbranchen som ikke blot er underleverandør men rent faktisk designer og producerer farmaceutiske produkter? Jeg gætter på ingen.

  • 5
  • 0
#59 Chris Bagge

Men jeg tænkte mere på at hvis alt software ender med at koste 3-4 gange så meget så bliver der mange steder hvor det ikke giver mening.

Hvis man sørger for at softwaren bliver lavet (nogenlunde) rigtigt første gang så kan der spares rigtigt meget. Fejludbedring koster rigtigt mange ressourcer, ikke bare hos leverandøren, men især hos kunden. Samtidigt kunde det også være at der kom en hvis ædruelighed i alle kravene til hvad softwaren skulle kunne. Tænk på hvor mget funktionalitet der stoppes ind i software og som aldrig bliver brugt.

  • 4
  • 0
#61 Michael Cederberg

Fejludbedring koster rigtigt mange ressourcer, ikke bare hos leverandøren, men især hos kunden.

Men det er ikke det vi snakker om. Selvfølgeligt skal software laves ordentligt.

Men du kunne nemt skulle til at udfylde rapporter i ISO87654321 format der viser at du har fulgt XYZ og PQR procedurer. Du kan få test procedurer trukket ned over hovedet som ingen mening giver i din situation fordi de er designet til en anden type software. Alle der har prøvet at lave software i en stor virksomhed ved hvor meget ekstra bureaukrati der kan være. Prøv så at forestille dig procedurer udstukket af staten eller forsikringsselskaber hvor der er store penge involveret. Det kan blive forfærdeligt. Alt sammen lavet i den bedste mening.

Samtidigt kunde det også være at der kom en hvis ædruelighed i alle kravene til hvad softwaren skulle kunne. Tænk på hvor mget funktionalitet der stoppes ind i software og som aldrig bliver brugt.

Den slags er meget forskelligt fra sted til sted. Der er lige så mange steder der lider af at første version også er sidste version og så sker der ikke mere … brugerne må leve med de mangler der er.

  • 4
  • 0
#62 Torben Mogensen Blogger

Men jeg tænkte mere på at hvis alt software ender med at koste 3-4 gange så meget så bliver der mange steder hvor det ikke giver mening. Hvor vi kommer til at "mangle" automatisering af forretningsfunktioner fordi automatisering bliver for dyrt.

For tiden bliver alt for meget fuldautomatiseret, hvilket øger kompleksitet og risiko for fejl. Mange fuldautomatiserede processer kunne med fordel erstattes af supportsystemer, der håndterer de enkle, men tidskrævende, dele af opgaverne, men overlader de mere komplekse dele til mennesker (dog med hjælpefunktioner, der understøtter beslutningstagen).

  • 3
  • 0
#63 Michael Cederberg

For tiden bliver alt for meget fuldautomatiseret, hvilket øger kompleksitet og risiko for fejl.

Det er et meget bredt statement. Min oplevelse er at der er mange processer der kræver menneskelig indblanding i dag som ikke behøver det. De kunne med fordel fuldautomatiseres. I praksis kan man ikke sige noget generelt om det, for det afviger fra myndighed til myndighed, fra virksomhed til virksomhed, fra forretningsprocess til forretningsprocess. Derfor kan det først vurderes når man kigger på de enkelte forretningsprocesser.

  • 0
  • 0
#64 Morten Pedersen

Det er sjovt at følge tråden, og se hvor meget SW folkene slår sig i tøjret :-) Som system ingeniør gennem mere end 10 år, for produkter med både SW, elektronik og mekanik, kan jeg bare konstatere, at der er ret omfattende krav til test af f.eks. strømforsyninger for at man må sælge et produkt, hvorimod SW er fri leg. Jeg tror en af grundene er, at vores reptilhjerner har det klart bedst med at forholde sig til ting man kan se og føle på. Der er derfor lange diskussioner om hvorvidt en given spændskive skal være en splitskive eller fjederskiver, hvor alle har en holdning og QA gerne blander sig, men hvis en SW mand synes at en given SW komponent skal skrives om fra Java til Haskell så hæver det ikke et øjenbryn.

Jeg er helt enig med PHK : Enhver samfundskritisk branche bliver før eller siden underlagt en form for regulering hvis man ikke selv kan få styr på skidtet (og 2021 ser indtil videre ikke god ud i så henseende)

  • 6
  • 0
#65 Frederik Just

Det her er jo en hel fantastisk god debat. Og mere moden og sober end tidligere når der har været diskuteret havarikommission indenfor IT.

Der er primært tre argumenter her:

  1. Jeg laver klyt og klamp og det vil jeg blive ved med. Uden ansvar.

  2. Det er jo fuldstændig uoverskueligt og dyrt.

  3. Jeg vil ikke hænge på regningen for Amanda eller Rejsekortet pga. mit beskedne bidrag.

Ad 1. Beklager. Tiden rinder ud.

Ad 2. Ja, det har du ret i. Men det går ikke særlig godt som det går. Spætten er kommet. Og noget bliver nødt til at ske.

Ad 3. Ja, bingo! Det er sådan set også hele ideen. Der er ikke nogen der skal hænge på noget i en IT-havarikommission. Men der skal læres formalistisk og med begyndende fremtidigt ansvar. Du kan lave alle de fejl du vil - gratis - bare de ikke står på denne liste og som vi fra tidligere havarier ved kan undgåes.

  • 2
  • 1
#66 Poul-Henning Kamp Blogger

For tiden bliver alt for meget fuldautomatiseret, hvilket øger kompleksitet og risiko for fejl.

Personligt synes jeg det største problem er at man har automatiseret 99.99% af tilfældene og glemt den sidste 0.01%.

Minoritetsbeskyttelse er et fundamentalt princip i vores kulturkreds: De døve skal også kunne låne bøger på biblioteket, kørestolsbrugere skal også kunne se ballet og komme på toilettet og - på godt og undt, -de racistiske og rabiate skal også have ytringsfrihed.

Men når sagsbehandling bliver automatiseret "glemmer" man ofte mindretalsbeskyttelsen, "for det er ikke værd at bruge penge på".

De 0.01% har ikke en jordisk chance overfor "new public management" hverken i det private eller offentlige, med mindre de tilfældigvis kender nogen er kan lave en shitstorm på sociale-medier som $nogen bliver nødt til at gøre noget ved.

  • 5
  • 0
#67 Martin Sørensen

Som system ingeniør gennem mere end 10 år, for produkter med både SW, elektronik og mekanik, kan jeg bare konstatere, at der er ret omfattende krav til test af f.eks. strømforsyninger for at man må sælge et produkt, hvorimod SW er fri leg.

Hvis en strømforsyning indeholder software der kan påvirke driften, så bør det være omfattet af de samme krav som HW (kravene bør gælde produktet som helhed og en SW komponent skal ses på lige fod med en HW komponent). Men den SW som f.eks. laver diagnostics og management er jo ikke kritisk på samme måde. Hvis der går noget galt her, så burde det ikke kunne føre til en sikkerhedskritisk hændelse.

Der er da også mange brancher som har omfattende krav til SW, f.eks. inden for bankverdenen, medicinalindustri, luftfart/transport osv.

Der burde også være skrappe SW krav inden for forsyningssikkerhed og kommunikation, og selv om jeg kan forestille mig at et atomkraftværk også har skrappe krav til styrings-SW, så er der nok ikke samme fokus på den SW som kan påvirke eldistribution f.eks.

Som så meget andet, så er det typisk først når der er sket tilstrækkeligt mange alvorlige hændelser at folk indser at man er nødt til at stramme op. Det er jo sjovere som politiker at bruge penge på nye veje, broer, parker, kunst osv., dvs. noget man kan pege på og som skatteyderne rent faktisk kan se frem for SW-sikkerhed som for de fleste folk er ret abstrakt (bare det virker så er de fleste ligeglade).

  • 1
  • 0
#68 Jørn Wildt
  • 0
  • 0
#70 Michael Cederberg

Det er sjovt at følge tråden, og se hvor meget SW folkene slår sig i tøjret :-) Som system ingeniør gennem mere end 10 år, for produkter med både SW, elektronik og mekanik, kan jeg bare konstatere, at der er ret omfattende krav til test af f.eks. strømforsyninger for at man må sælge et produkt, hvorimod SW er fri leg

Nu er det altid svært med den slags generaliserede statements. Jeg tror såmænd de fleste software folk godt kan se ideen med at hæve kvaliteten og forbedre sikkerheden. Spørgsmålet er hvordan man når dertil.

Problemet opstår hvis man stiller meget rigide krav. Det er ikke anderledes for software end for andre ting. I byggebranchen har man forskellig slags beton med forskellig styrke og andre attributter. Der er regler for hvor forskellig slags beton må bruges. Hvis der kun var en slags beton så ville det hæve prisen på byggeri meget kraftigt.

Spørgsmålet med både SW og elektronik er hvordan man laver krav der giver mening. Hvis man stiller (nogenlunde) samme krav til alt så bliver det igen meget dyrt. Et godt eksempel her på er komponenter og SW til fly. Hvis kravene til min switch i lejligheden var de samme som en til et fly, så ville den koste 100 gange så meget. Uden at der nødvendigvis var nogen grund til det. Jeg kan roligt sige at jeg i min tid i SW branchen har oplevet situationer hvor man forsøgte at påtvinge alle samme krav til design, programmering, test, deployment og ops uanset om det var en applikation med 5 brugere eller en med 50 mio. Uanset om risikoen for virksomheden var 10 kr. eller 10 mia. kr.

Så i stedet for at rende rundt og sige at de andre er dumme, dovne eller ligeglade så skulle I hellere komme med konkrete forslag til hvordan en regulering kunne se ud. Så kan vi have en debat om hvad der giver mening, hvad det koster og hvad konsekvenserne er.

(Ovenstående er allerede blevet langt. Jeg har skøjtet hen over en række finere detaljer. Lev med det.)

Personligt synes jeg det største problem er at man har automatiseret 99.99% af tilfældene og glemt den sidste 0.01%.

Vi har alle forskelligt udsyn til verden. Jeg tænkte på arbejdsprocesser ... ikke personer. Man kommer ikke udenom at de langsomste knallerter på havnen vil have udfordringer i en stadig mere boglig og teknologisk verden. Opgaven er i mine øjne at hjælpe dem uden at stoppe den teknologiske udvikling. Jeg kunne godt forestille mig et udvidet borgerservice på kommunen hvor man kunne dukke op hvis der var ting man havde svært ved. Så længe det kun er 1% af befolkningen der dukker op vil der stadigvæk være gevinster for samfundet ved automatisering.

  • 2
  • 0
#71 Poul-Henning Kamp Blogger

Spørgsmålet er hvordan man når dertil.

Det er meget simpelt: Ved at sikre at dem der tager beslutningerne også betaler for konsekvenserne af beslutningerne.

Idag slipper SW-branchen af sted med en masse kortsigtede beslutninger, fordi de ved de ikke kommer til at betale for konsekvenserne selv, eller måske endda ligefrem ser konsekvenserne som en fremtidig forretningsmulighed.

Se f.eks bare alle de skoddimser der kobles på nettet, hvor der ikke er skyggen af mulighed for softwareopdatering, langt mindre nogen der har tænkt sig at udsende patches.

(Dan Geer, som tænkte langt forud for os andre på dette punkt, har foreslået at net-tilkoblede produkter skal have en "self-disable" mekanisme, således at de automatisk kobler sig selv af nettet to år efter softwaren blev lagt på.)

  • 2
  • 0
#72 Kristian Rastrup

Jeg kunne godt forestille mig et udvidet borgerservice på kommunen hvor man kunne dukke op hvis der var ting man havde svært ved. Så længe det kun er 1% af befolkningen der dukker op vil der stadigvæk være gevinster for samfundet ved automatisering.

En udfordring ved kommunens brugere er at de for langt hovedparten af sagerne alle tilhører som du siger "de langsomste knallerter på havnen".

Der er et udpræget sammenfald mellem dem, der modtager kontanthjælp og enlige uuddannede mødre, alkoholikere, hjemløse, hashvrag og dybt psykisk syge.

Jvf. Ole Tanges indlæg: https://www.version2.dk/blog/generalproeve-paa-fogedretssag-1093336

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