Kristian Mandrup

'Bad bots' udgør nu omkring 38 pct. af internettets trafik

Hvis du er imod en kommunistisk "Ny Verdensorden" (NWO/OWN) bliver du i dag betegnet som:

  • "Alt Right"
  • White Nationalist
  • hate crimer
  • "Russian bot"
  • of nu "bad bot"!?

Clown World ?

26. april 2019 kl. 12:14
Overvæld af hvide mænd kan føre til uforsætlig diskrimination i AI-systemer

Endnu et eksempel på "Clown World"

"Everything is racist, everything is sexist, everything is homophobic and you have to point it all out!"

Civilization died, not with a BANG, but with a whimper... Walking on egg shells.

White man - anything you say or do can and will be used against you. You are the ENEMY of the Cultural Marxists, hellbent on a Communist NWO as spelled out in "Imagine" by Beatles.

18. april 2019 kl. 07:05
Dansk center vil skabe værktøjer til fejlfri programmering

Typisk, konventionel programmering i dag er stadig meget lig med hvordan man i "gamle dage" selv lodded kredsløb sammen manuelt med dertil hørende fejl.

I dag køber man oftest færdige chips der er gennemtestet og knytter så de enkelte komponenter sammen til en færdig løsning.

Samme fremgangsmåde bør man benytte til software. Undgå så vidt muligt boilerplate kodning. En kilde til fejl uanset hvad!

Alternativt, lav et høj-niveau sprog i stil med f.eks Eve eller AppML, hvor man beskriver sin domeæne model og workflows og så har en underliggende engine der genererer al koden med dertilhørende tests (full test coverage) direkte fra den abstrakte model. Dertil kan føres lidt ekstra custom kode om nødvendigt (max 5%).

Hvis man endelig vil gøre det på lav kode niveau, så brug et sprog med indbygget statisk type og flow analyse som f.eks OCaml, ML og lignende (moderne variante f.eks F#, ReasonML, ELM osv).

For disse sprog er der normalt, at hvis programmet compiler er det også fejlfrit. No runtime errors. Undgå sprog med null pointer (aka Billion Dollar mistake). Benyt typestærke sprog uden null pointer.

Undgå at bruge statements (imperativ programmering) og kod det hele med expressions.

Case solved.

18. april 2019 kl. 07:00
Programmering i skolen deler eksperter: Skal der kode på skemaet?

Vi er hastigt på vej til at kodning er som Assembler. I nær fremtid vil det meste "programmering" være via visuelle netværks diagrammer, med noder der knyttes sammen, potentielt udført gennem tale instruktioner, via VR/AR mv.

Vi vil snart kunne beskrive de fleste systemer på et langt højere abstraktionsniveau end "kode". I stedet vil en "intelligent backend" skrive og knytte al koden sammen. Der vil så være nogle få der udvikler bedre "code generators", som der i dag er ganske få der designer nye computer chips.

Kodning bør derfor ikke komme på skemaet, men derimod er udviklingsprocessen mere interessant at få en forståelse af.

Dvs. forståelse af problem -> løsning, generel "ingeniørforståelse", bruger krav, forskellige typer af tests mv.

16. februar 2018 kl. 14:34
ITU-professor: Dårlig ledelse bærer en stor del af ansvaret for EFI-katastrofen

Enig med Rosenberg's kommentar ;) Problemet er netop at ingen tager ansvar fordi alt er skudt til siden mht eksterne konsulenter, leverandører osv.

Der er stort set ingen dybe IT kompetencer internt kun generelle "projekt ledere", "business eksperter" osv. Dermed når det går galt kan man altid sige, vi vidste ikke bedre - der var leverandørernes/konsulenterne der har ansvaret.

Problemet er ikke "ledelsen", der er selve den interne organisatoriske struktur og projekt samt udbudsmodellerne. Det er stadigvæk for det meste super gammeldags fastpris projekter, vandfaldsmodel, udbud, valg af leverandører (ofte endda vurderet og udpeget af konsulenthus).

Kunden kan ofte først teste når modulerne bliver endeligt leveret og opdager derfor alt for sent at de ikke stemmer overens med de oprindelige krav (eller nye krav som er tilkommet siden). Kravene og systemopbygningen er ofte ikke designet til fleksibelitet og videreudvikling fremadrettet. F.ex kunne beslutningstagerne (jurister) i EFI sagen ikke se at SKAT skulle have ejerskab over koden. De troede formentligt at det bare var 0'er og 1'er "i stabevis", ikke kildekode som kunne udbydes til andre leverandører så man kunne undgå vendor lockin.

Verden er alt for dynamisk til sådanne projekter "skåret i sten". Tid til forandring!

12. maj 2017 kl. 15:27
ITU-professor: Dårlig ledelse bærer en stor del af ansvaret for EFI-katastrofen

Jeg var en af IT arkitekterne på EFI i ca. 6 måneder, indtil det gik i politisk/juridisk hårdknude. På det tidspunkt var løbet for længst kørt og alle skibene på vej til at synke. Hovedproblemet er ALT for STORE projekter, som det offentlige, uden særlig IT kompetence slet ikke kan styre. Kravspecs på +30k sider. Come on!

Desuden kørte man stadig klassisk vandfaldsmodel + GANT diagrammer med millimeterpræcision. Når først nogle enkelte trin blev forsinket sank hele flåden af skibe sat i søen... Alt for mange dependencies, selv med en service (SOA) tilgang.

Det offentlige burde have en eller flere centrale professionelle IT projekt organisationer med ca. 500-1.000 IT eksperter der styrer mini projekter i små teams, med genbrug af micro services og UI komponenter på tværs af systemer.

IT bliver stadig betragtet som en utility funktion, noget der kører nede i kælderen på et par servere og kan administreres og styres eksternt. Ikke som en kritisk del af kerneforretningen. Sålænge det er tilfældet vil det altid gå galt.

10. maj 2017 kl. 11:19
Milliardballade om KMD: Var det dårlige krav eller en dårlig leverandør?

Statistik viser at risikoen stiger eksponentielt med projektstørrelse. Projekter bør i stedet deles op som mini apps og micro services samt komponenter og udbydes separat hvor mindre niche leverandører kan være med. Det er en alt for old school vandfaldsmodel tankegang der benyttes. Tanken er at et stor projekt skal spare penge og drift mv men istedet bliver det altid langt dyrere både på kort og langt sigt...

23. januar 2017 kl. 11:06
Kim Normann: Fjern alle it-projekter fra staten og læg dem i et privat selskab

Enhver bør vide, at kompleksitet og risiko stiger eksponentielt!

Problemet er, at det offentlige ofte tror de kan "spare penge" (og mere prestige!) ved at lave store IT projekter. Men det går (næsten) altid galt, da man ender med projekter ingen kan overskue og med storleverandører der udnytter deres monopol/kartel situation...

Løsningen er, at dele projekterne op i langt mindre dele (komponenter) der udvikles separat og hvor mindre leverandører kan byde med og dermed skabe konkurrence og "dynamik".

Man burde i det offentlige gå over til Open Source i langt større stil, lave samarbejde med universiteter og lade alle "byde ind" i langt mere åbne systemplatforme. Offentligt IT for "hele danmark", ikke kun for KMD mfl.

Løsningen er ikke yderligere privat monopolisering, det minder mig om USAs sygehusvæsen og "Obama care" der er et skrækeksempel på hvordan det går når man privatiserer og det helt bliver bund korrupt og langt dyrere!

29. november 2016 kl. 11:28
For dyrt, for sent og for lidt: To ud af tre ERP-projekter skuffer fælt

ERP er da helt forældet... det var dengang man købte dyre, tunge, klodsede standardsystemer fra de store, dyre systemleverandører... Det er helt godnat stadig at gå den vej.

Travel light, go agile...

25. november 2016 kl. 11:29
Skat køber EFI-erstatning for 400 mio. med agil udvikling til Oracle-platform

SKAT mv. er lovgivning, dvs. regler knyttet til andre regler i et komplekst netværk. Det er meget svært at programmere og vedligeholde ved klassisk imperativ logik.

I stedet burde SKAT gå andre veje og se på alternative muligheder, fx ved at bruge en moderne Rule Engine.

https://en.wikipedia.org/wiki/Business_rules_engine

Desuden er det synd at se at de IGEN udbyder til en storleverandør med standardsystem og gammeldags system design som Java og Weblogic. Hvorfor ikke bryde det op i en række mindre systemer der udbydes til mindre leverandører. DET er agilt! Det ser ud til at SKAT er stuck i 00erne og ikke er kommet meget videre.

14. november 2016 kl. 11:42
Småt er godt - så hvorfor skriver vi klasser på 20.000 linjer?

En klasse bør sjældent være mere end hvad der kan vises på et skærmbillede med standard font. Brug af code collapse er en farlig ting og giver netop anledning til at presse alt for meget funktionalitet ind der ikke hører hjemme. Beginner mistake! En funktion bør sjældent være mere end 2-3 linjer, oftest one liners og sjældent tage argumenter, i så fald højst 1 argument... Coding is an art!

10. oktober 2016 kl. 11:10
Selvkørende biler - søndagsbilister i myldretiden?

Jeg ser desvære alt for mange udtale sig om Machine learning som tror de forstår det men ikke har baggrunden til at forstå det. Traditionel ML til driver assistance var programmeret med de begrænsninger det giver. Men den eneste måde at nå helt i mål er ved brug af Deep learning, lære udelukkende udfra erfaring - evt fra en blanding af menneske- og maskinkørsel ude i virkeligheden. Ja, det vil måske nok være mere søndagskørsel men kun fordi det er langt mere sikkert. I sidste ende vil vi være langt mere dømmende i fht fejlftihef overfor maskiner end vi er for mennesker.

12. september 2016 kl. 11:58
DSB i kæmpeudbud: Vil bruge 186 millioner kr. på app-udvikling

Enig i de fleste kommentarer her. Der er brug for nytænkning helt fra 0. Der ville præcis nok være en langt bedre Business case helt at droppe billetbetaling og finansiere det på anden vis. Det ville givet give øget mobilitet, mindre stress, mere glæde, bedre turisme... Med besparelser på alt den infrastruktur, legacy + mobile apps mm., kontrollører mfl. ville det nok gå lige op, eller koste minimalt der ku hentes andre steder... Det er helt til grin at vi kører samme komplicerede zone system som i 60erne. Det offentlige vil bare hænge fast i fortiden og hele tiden vokse sig større, dyrere og mere ineffektiv. Ja, de offentlige IT projekter burde aldrig tillades at koste mere end 5-10 millioner.

26. august 2016 kl. 16:56
Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

@Rolf Præcis! Problematikken omkring prototyper angriber jeg som et punkt i næste artikel der giver bud på bedre løsningsmodeller ;)

I øvrigt er det offentlige igang med en omstilling over til Agile Development og mere agile projektmodeller generelt. Denne artikel beskrev forholdene i ca. 2008.

14. juli 2016 kl. 19:18
Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

Generelt er det et stort problem, at Staten alt for ofte bruger (store og dyre) konsulentfirmaer og leverandører, der har en interesse i at gøre projekterne så dyre som mulige i (blind?) tro på at de vil hjælpe dem sikkert i mål!

Samme strukturelle problem har jeg set i bl.a Council of Europe, som teknisk projektleder "indefra". Der er en kraftig tendens til "kammerateri" i forholdet mellem kunde og leverandør og deraf "vennetjenester". Det er helt almindeligt at man spiser frokost sammen, eller andre sociale arrangementer...

Jeg har desuden selv arbejdet for (dyre) konsulentbureauer som pre-sales/teknisk konsulent. I den rolle er der selvklart en personlig (bonus) interesse i at sælge mest muligt til kunden. Derfor sælges de de dyre Enterprise pakkeløsninger uanset om det reelt er det kunden har brug for. Kunderne (herunder offentlige organisationer) forstår sjældent hvad de har brug for og køber derfor oftest hele "katten i sækken" for at være på den sikre side.

14. juli 2016 kl. 19:14
Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

@Henrik Der er flere måder at benytte Open Source. Det kan give stærkt øget transparens, hvor hele IT danmark løbende kan følge med, f.eks hvis det offentlige vælger at offentligøre de enkelte moduler/systemer der udvikles i offentlig tilgængelige repositories. En anden model er bare at benytte visse Open Source løsninger i en ellers lukket udviklingsmodel. Det sparer kun lidt penge til licenser og evt. udviklingsomkostninger.

PS: Senest har Bulgarien meldt ud at de vil kræve at offentlig IT bliver open source:

http://www.techweekeurope.co.uk/projects/public-sector/bulgaria-open-source-public-sector-194723

@Henrik Helt enig. Vi bør klart se på hvordan de gør i Estland og England og lære af deres erfaringer.

@Henrik Jeg har svært ved at se at flere Jurister skulle hjælpe. Vi var også i tæt kontakt med SKATs Jurister under hele EFI forløbet. Det gik helt galt på et tidspunkt, hvor Juristerne (uden at rådføre sig med IT afdelingen), skrev under på, at vi ikke fik koden som en del af løsningen. Juristerne kunne ikke se hvad vi dog skulle bruge koden til. Denne beslutning betød endnu en gang et "black box" system med vendor lock-in.

14. juli 2016 kl. 17:44
Version2’s læsere: Hvor er de kompetente it-folk bag offentlige it-projekter?

@Anne

Man kan ikke få fat i de dygtige IT folk fordi det offentlige stadig kun betragter IT som utility/drift. IT afdelingen er oftest placeret i kælderen i skyggen, med ekstremt dårlige arbejdsvilkår, mens jurister mfl. sidder bekvemt og soler sig på de øvre etager. Desuden betales IT folk ikke på markedsvilkår. I dag er IT udviklingsafdelingen typisk bare endnu en afdeling i den offentlige institution ligesom drift. De bør totalt adskilles.

Løsningen er nok at etablere en fælles offentlig IT udviklingsorganisation med seriøse IT kompetencer (ca. 100 millioner om året, ca. 150-200 personer), og kun lade de lokale IT afdelinger om intern drift/support.

Ethvert større IT projekt bør gå gennem denne fælles IT udviklingsorganisation, hvor man har de nødvendige midler, kompetencer, erfaring, processer, forbindelse og værktøjer mv. (unix, open source udviklings- og testværktøjer mv.)

Problemet i det nuværende system, er bla. at de IT ansvarlige kun har standard office software (Windows, IE, MS Office) og er stærkt begrænset af almen security politik hvorfor outsourcing reelt er den eneste mulighed!

7. juli 2016 kl. 13:33
Version2’s læsere: Hvor er de kompetente it-folk bag offentlige it-projekter?

Når man har inkompetente IT ledere bliver prisen skruet helt i vejret. Eksempelvis kostede en Web Service mindst 100.000kr, uanset om det reelt var en one-liner: (find person med et givent person ID). Denne linje pakket ind via standard annotations (security, transaction, logging mv.). Prisen reflekterede kun at "Web Service" lød smart/fancy og derfor var let at sælge til ublu priser. Sådan er det hele vejen!

Council of Europe: Jeg var med til at "opgradere" et egetudviklet legacy CMS system til et endnu værre standard CMS system med over 20 år på bagen, tæt på pensionsalderen, udviklet på gammel 90er teknologi (med "garanti" om support/opgraderinger). Typisk legacy system, næsten umuligt at tilpasse og de brugte derfor dyre konsulenter til 10.000kr om dagen for at tilpasse systemet i én uendelighed (kravspecs konstant ændret!). Efter 3 år stod man i stampe! Brugerne jeg konsulterede med ville hellere kvitte deres job end at bruge det "nye og bedre" system!!

7. juli 2016 kl. 13:00
Version2’s læsere: Hvor er de kompetente it-folk bag offentlige it-projekter?

Der bliver givet alt for mange penge til disse projekter og så vokser de sig unødigt dyre/komplekse. Nedsæt de bevilgede beløb drastisk så man må tænke i nye baner for at komme i mål (se på startups).

Flere store private virksomheder har nu endelig indset dette faktum og opretter interne "startup" afdelinger, som f.eks i Danske Bank. Ellers bliver de let udkonkurreret (disrupted!) af nye små spillere...

Problemet i det offentlige er, at der IKKE er konkurrence.

7. juli 2016 kl. 12:54
Version2’s læsere: Hvor er de kompetente it-folk bag offentlige it-projekter?

Der er ingen dygtige IT folk der ønsker at arbejde i det offentlige. Kulturen virker som et effektivt filter på IT folk med initiativ/dygtighed. De fleste der bliver i længere tid (mere end 6-12 måneder) er folk uden ambitioner, der bare vil have et "job" og kan finde sig i uendeligt bureaukrati, forældede arbejdsgange, teknologi mv.

Ja, hvis man vil gøre noget ved det må man tage fat om roden og starte forfra fra bunden. Det er set gjort effektivt andre steder som f.eks i Estonia og endda i England.

7. juli 2016 kl. 12:49