Uddannelsen der ikke findes

Godt så: Datalogerne vil ikke have noget med virkelighedens computere at gøre. Hvem skal vi så ansætte til at stoppe software katastroferne ?

Når politiet forsøger at feje en mulig besparelse på 100 mio ind under gulvtæppet, er det fordi de er bange for deres computere.

De er rædselslagne for at en eller anden fornuftig ændring vil få hele skidtet til at brase sammen.

Til sammenligning er de ikke bange for at Storebæltsbroen styrter sammen, selvom man skifter asfaltleverandør ved næste udskiftning af slidlaget.

Hvad er forskellen ?

I fysik lærer man om newtons love med friktionsløse trisser, punktformige lodder og vægtløse snore og alt foregår i et vacuum.

En civilingeniør lærer at trisser har friktion og drejningsmoment, at lodderne har ting som "Elastisitets Modulus" (hvad det så end er) og de har tommelfingerregler for luftmodstand og andre quasi-kaotiske forhold.

Derfor kan vi bygge broer der holder, huse der kan stå ude om natten og kloaknet og vandforsyning der ikke blandes blot fordi nogen graver et hul til en rosenbusk i samme bydel.

Men i IT branchen vælter hele dankort systemet på grund af "en uvedkommende software-opdatering", eller fordi nogen sætter et forkert stik i en switch. Rejsekortet bliver stadig ikke til noget, tinglysningssystemet er fejldimensioneret og listen fortsætter i samme deprimerende stil i det uendelige...

"Prøv at slukke og tænde, det kan være det hjælper..."

Hvor HERRE bevares!

I Datalogi lærer man om algoritmer på abstrakte modeller af computere og selvom der rundt om kring i krogene sidder folk og forsker i de meget interessante problemstillinger abstrakte modeller af virkelige computere stiller os over for, er det stadig friktionsløse trisser, punktformige lodder osv.

Men hvor er den parallele disciplin, hvor computere har endeligt lager, diske har dårlige sektorer og alt andet ikke er lige ?

Hvor er uddannelsen, hvor man lærer at indarbejde en sikkerhedsfaktor i IT systemer, istedet for "hvis vi er heldige går det nok '" så Folketingets hjemmeside ikke går ned hver gang en politiker siger noget dumt '

Hvor er uddannelsen, der uddanner fagfolk der kan stille sig op imod politikere, bureaukrater og andre fantaster og få skåret ambitionerne og drømmene ned til noget vi faktisk kan magte ?

Vi mangler simpelthen en praktiker uddannelse som "Software Ingeniør" på Master level, en uddannelse hvor man lære at bygge robuste IT systemer så de kan løse opgaven, vedligeholdes, opgraderes og sammenkobles.

I mangel deraf, ansætter vi i stedet dataloger og forventer at deres teoretiske "blyant #2" lærdom har noget at gøre med "8-core, 4 socket, 3 level-cache, POSIX under VMware og SAN over iSCSI" maskiner.

phk

PS: nej, jeg mener ikke at ITUs kursus i "Avanceret Software Engineering" kommer i nærheden af hvad vi har brug for. Faktisk har en gennemgang af kurset kun gjort det endnu mere klar for mig, i hvor stort omfang vi fægter i blinde og forlader os på forskellige former for WooDoo.

Kommentarer (74)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Torben Mogensen Blogger

Godt så: Datalogerne vil ikke have noget med virkelighedens computere at gøre. Hvem skal vi så ansætte til at stoppe software katastroferne ?

Dels er det (som diskussionen efter dit tidligere indlæg viste) en [i]non sequitur[/i], og dels er det de færreste softwarekatastofer, der skyldes manglende hensyn til maskinnære detaljer i kodningen.

Og når vi nu taler om dit tidligere indlæg, så burde din artikel ikke have heddet "You are all doing it wrong" men "I have been doing it wrong until recently because I didn't bother to check the relevant literature".

  • 0
  • 0
#4 Peter Makholm Blogger

Hvor er uddannelsen, der uddanner fagfolk der kan stille sig op imod politikere, bureaukrater og andre fantaster og få skåret ambitionerne og drømmene ned til noget vi faktisk kan magte?

Hvilke uddanelser mener du opfylder dette på de trafik-, energi-, social-, og sundhedspolitiske områder?

Mig bekendt ingen, så hvorfor specifikt inden for IT?

  • 0
  • 0
#5 Thomas Kjeldsen

http://tinyurl.com/2ezxd5x

Men som Torben også er inde på: Softwarekatastrofer er ofte store forandringsprojekter hvis succes afhænger af at de mennesker der skal bruge det nye system både forstår det og bryder sig om det. Den kyndige udvikler der er helt oppe at ringe over en teknisk optimering er altså kun en lille (ubetydelig) brik i spillet. Farver, pædagogiske evner, formidling, adfærdsstudier, you name it - der er brug for mange kompetencer for at få et større forandringsprojekt til at lykkes.

  • 0
  • 0
#6 Poul-Henning Kamp Blogger

@Torben:

[...]det de færreste softwarekatastofer, der skyldes manglende hensyn til maskinnære detaljer i kodningen.

Det er et utroligt snævert syn at lægge for dagen Torben: De fleste IT katastrofer skyldes en helt unødvendig virkelighedsfjern tilgang til hvilke problemstillinger computere kan og ikke kan løse og hvad en sådan løsning kræver.

@Carsten:

To ud af de tre kurser ligner umiddelbart datalogi i forklædning. Det tredje, hvis det rammer plet, vil udgøre alt for lidt af den samlede uddannelse.

@Peter:

Hvilke uddanelser mener du opfylder dette på de trafik-, energi-, social-, og sundhedspolitiske områder?

Civilingeniør, ditto, Samfundsøkonom, ditto.

Men når det kommer til IT kan ministeren stille sig op og påstå at kommunesammenlægningen vil spare milliarder, selvom ingen ved deres fulde fem tror at det vil spare en krone.

Bagefter checker man ikke om han havde ret.

@Thomas:

At kalde den digitale tinglysning "et forandringsprojekt" er bare en elendig undskyldning, betalingen for storebæltsbroen var en lige så "gennemgribende" forandring af vores måde at køre bil på.

I dag burde et digitaliseringsprojekt som tinglysning, kirkebøger eller patientjournaler være et rutinemæssigt job, på samme måde som det er at bygge Fehmernforbindelsen.

Poul-Henning

  • 0
  • 0
#7 Peter Makholm Blogger

@Peter:

[quote]Hvilke uddanelser mener du opfylder dette på de trafik-, energi-, social-, og sundhedspolitiske områder?

Civilingeniør, ditto, Samfundsøkonom, ditto.[/quote]Det er ikke den opfattelse jeg få af at følge debatten på ing.dk... Der lyder de (og du) lige så frustreret over tilstanden på ingeniørenes fagområder. Skal man frem skal man være DJØF'er ser ing.dk holdningen ud til at være.

  • 0
  • 0
#8 Carsten Sonne

To ud af de tre kurser ligner umiddelbart datalogi i forklædning. Det tredje, hvis det rammer plet, vil udgøre alt for lidt af den samlede uddannelse.

Det er tre forskellige retninger hvor der indgår 20+ forskellige kurser.

Der er fuldstændig valgfrihed i kurserne på overbygningen. Hvis du vil have en bestemt titel, jf. overstående 3 retninger, er der dog begrænsninger. Men det er kun relevant ift. titlen. Master titlen afgøres udelukkende af ECTS point.

Det eneste der er kritisk ift. valg er kurser, består i at skabe en profil el. specialisering som er interessant for en arbejdsgiver. Ofte er man tvunget til at fokusere for at skabe en sammenhængende profil. Der er overraskende få virksomheder, som er interesseret i en der kan lidt af hver, men ikke er rigtig god til noget af det.

  • 0
  • 0
#9 Poul-Henning Kamp Blogger

Skal man frem skal man være DJØF'er ser ing.dk holdningen ud til at være.

Det er så en lidt anden og mere overordnet problemstilling, men vi er trods alt ikke nået til at det er DJØF'erne der bestemmer hvor tyk betonen skal være i vores broer...

Poul-Henning

  • 0
  • 0
#10 Jesper Rude Selknæs

"I fysik lærer man om newtons love med friktionsløse trisser, punktformige lodder og vægtløse snore og alt foregår i et vacuum."

bare lige for en god ordens skyld vil jeg da lige nævne at på det gode gmale fysik11 kursus på KU, lærte at altså at trisser osv. har friktion. Læs evt. Jens Martin Knudsen et al "Elements of Newtonian Mechanics" men jeg forstår at literatursøgning ikke er PHK's store force.

  • 0
  • 0
#11 Michael Diaz

Hvad med Softwareingeniør på Aalborg Universitet?

Næsten hver eneste gang PHK har lavet et indlæg om hvordan uddannelser er for idioter, har jeg adspurgt af interesse hvad PHK selv egentlig er uddannet som, men aldrig har jeg fået svar. Må man få svaret nu? :-)

  • 0
  • 0
#12 Torben Mogensen Blogger

I dag burde et digitaliseringsprojekt som tinglysning, kirkebøger eller patientjournaler være et rutinemæssigt job, på samme måde som det er at bygge Fehmernforbindelsen.

En væsentlig forskel er, at en Fehmernforbindelse har en ret enkel kravspecifikation: Der skal kunne flyttes X antal tog, lastbiler, biler osv. i timen henover forbindelsen, [i]downtime[/i] (grundet vejr m.m.) skal være under Y dage om året og den skal kunne holde i Z antal år.

Softwareprojekter fejler ofte, fordi der ikke har været en god kravspecifikation: Noget er udeladt, noget er overspecificeret eller noget er decideret forkert. Desuden ændres kravene ofte midt i forløbet, fordi man lige skal tilføje noget, man har glemt eller fordi det juridiske grundlag ændres.

Hverken digital tinglysning, ditto patientjournaler eller kirkebøger fejlede, fordi de ikke kunne skalere til store datamængder. De fejlede, fordi der ikke var enighed om, hvilke opgaver, de skulle løse, hvilket resulterede i en mangelfuld specifikation og et mangelfuldt produkt.

Det er straks noget andet med f.eks. Ericssons AXE-N projekt (http://sv.wikipedia.org/wiki/AXE-N), hvor problemerne ifølge nogle kilder blandt andet skyldtes, at man ikke kunne eliminere fragmentering og [i]space leaks[/i] i forbindelse med lageradministration i objektorienteret C++ kode. Løsningen her var ikke nørkleri med lagerhierarki osv, men at skrotte C++ og omskrive systemet fra bunden i et sprog med automatisk lageradministration (og uden brug af objektorienteret programmering).

  • 0
  • 0
#13 Anonym

PHK skrev:

Det er så en lidt anden og mere overordnet problemstilling, men vi er trods alt ikke nået til at det er DJØF'erne der bestemmer hvor tyk betonen skal være i vores broer...

Det er ikke langt fra, når man f.eks. ser på "nem"-konstruktionen. Beslutningerne er jo truffet længe inden fornuften og den rationalle tænkning får en chance.

Men samtidig er der omvendt også problemer som datalogerne (teknikerne blandt datalogierne/ingeniørerne) fejler alvorligt på.

F.eks. er det katastrofalt så ringe systemer i dag er omkring interoperabilitet og sikkerhed. Interoeprabiltiet er noget med fastlåsning omkring en måde at gøre tingene på - sikkerhed er låst i noger forældet Identifikations- og overvågningstænkning nærmest blot fordi det er nemmest for den som designer systemet.

Imellem disse 2 forsvinder samfundets dynamik og fornyelsesevne. DJØFerne vil styre, teknikerne designer det frie valg ud af processerne ved et fastlåse omkring stive systemstrukturer. Skal man være hård kan man sige at begge dele lider fra forskellige perspektiver af at de ikke forstår (eller er tilstrækkeligt ydmyge overfor) samfund men ser det som henholdsvis en økonometrisk og en teknisk optimeringsproces.

En væsentlig del af problemet er at det kræver megen erfaring at rumme viden på højt nuveau indenfor flere vidensdomæner - specielt hvis de er meget forskellige af natur. Derefter at syntetisere dette til viden som kan bruges til at accellerere indlæring er en svær process som tager megen tid - tid som vi ikke har fordi verden ændrer sig hurtigt.

  • 0
  • 0
#14 Carsten Sonne

...hvad PHK selv egentlig er uddannet som...

Jeg læste en artikel om PHK i Prosa for mange år siden. Jeg mindes han er såkaldt ufaglært. Det er ikke uddannelsen der er det afgørende, selv om det er dejlig nemt at putte folk i kasser.

  • 0
  • 0
#15 Poul-Henning Kamp Blogger

Softwareprojekter fejler ofte, fordi der ikke har været en god kravspecifikation: Noget er udeladt, noget er overspecificeret eller noget er decideret forkert. Desuden ændres kravene ofte midt i forløbet, fordi man lige skal tilføje noget, man har glemt eller fordi det juridiske grundlag ændres.

Nej, de fejler ikke af alle de årsager, de fejler fordi der ikke er fagfolk der siger nej til alle disse tåbeligheder.

Sådan som du beskriver det, var det også med projekter indenfor civilingeniørområdet engang, indtil fagfolkene tog sig sammen og trak en streg i sandet.

Det meste berømte eksempel er det elendige skib Wasa, der på rigtig mange måder minder om hvordan vi laver store IT projekter i Danmark.

Hvis et enigt folketing var kommet, halvvejs igennem bygningen af Storebæltsbroen, og havde bedt om at få tilføjet et jernbanespor mere, er der ingen der ville have sagt "Det kan vi nok godt fuske sammen" eller lovet at det nok kun ville forsinke projektet en lille smule, eller at man kunne betale det over vedligeholdelseskontrakten.

Men det sker gang på gang indenfor IT projekter.

Hvis situationen skal blive bedre inden for IT, skal vi have en faglig indsats, for at styrke kvaliteten af det arbejde faget leverer og en derfra afledt moralsk højde til at bede politikere og andre tåber om at hoppe i havet når de kommer med den slags.

F.eks har man i konstruktionsbranchen noget der hedder "sikkerhedsklasser" for bygninger, således at f.eks idrætshaller bygges mere solidt end carporte.

Når det så går galt og en cykelarena falder sammen i Ballerup, undersøger man hvorfor, går tilbage til normerne og kvalitetsarbejdet og forsøger at forhindre at det går galt næste gang.

Den slags normarbejde, for forventningerne til og udførelsen af IT systemer findes der ikke skyggen af i dagens Danmark og kun meget få eksempler på world-wide.

Burde der f.eks ikke været et krav om at en væsentlig offentlig hjemmeside som Folketinget.dk kan holde til at borgerne bruger den ?

Og helt sikkert er det, at der er ingen af de danske uddannelsessteder, mindst af alt de datalogiske, der leverer noget der blot ligner den slags faglighed.

Men ude i samfundet, tror folk stadig at det er det dataloger kan levere.

Kald det "manglende forventningsafstemning" hvis i vil, men det løser ikke problemet...

Poul-Henning

PS: Min uddannelse er 26 års erfaring med at være piloten der ror lokomotivet i land når IT projekter er eller er ved at kuldsejle.

  • 0
  • 0
#18 James Avery

Godt så: Datalogerne vil ikke have noget med virkelighedens computere at gøre.

Kære Poul-Henning: hvor, hvor, HVOR læste du dette i den foregående debat? Hvad jeg kunne læse ud af den var, at du kom med en masse uunderbyggede og vagt definerede påstulater, hvorefter du ignorerede al dokumentation for, at du havde faret med halv vind -- eller sagt på en anden måde, at du tog helt og aldeles fejl.

Datalogerne vil bestemt have noget med virkelighedens computere at gøre i alle deres inkarnationer, hvilket også afspejles i forskningen. At starte din næste blog, som du gør, fejlrepræsenterer debatten tenderende det uærlige. Det er ikke klædeligt!

  • 0
  • 0
#19 Poul-Henning Kamp Blogger

Jeg tror det blev bedst formuleret af Jesper:

Traditionelt har datalogiundervisningen foretrukket emner der er "tidsløse" i den forstand at det er uafhængigt af hvad der rent faktisk sker i praksis - men stadigt holder mange år efter. [...] Når så en datalog bliver "færdig" med sin overvejende teoretiske uddannelse, ja så er vedkommende nødt til at sætte sig ind i visse praktiske detaljer.

Datalogi er en teoretisk uddannelse, som første bliver praktisk anvendelige efter nogen "dekompression" i den virkelige verden. Det vil du finde mange IT chefer der vil skrive under på, helt uden at blinke.

Men når du skal bruge en bygningsingeniør, tager du ikke en fysiker og dekomprimerer ham, mens hans første fem ti huse skatter sammen om ørene på ham.

Mit argument er, at der er mangler en akademisk disciplin og systematisk tilgang til denne "dekompression", en faglig indsats der gennem forskning og erfaringsindsamling befrier os for lave de samme bommerter igen og igen og igen.

Poul-Henning

  • 0
  • 0
#20 James Avery

Datalogi er en teoretisk uddannelse, som første bliver praktisk anvendelige efter nogen "dekompression" i den virkelige verden. Det vil du finde mange IT chefer der vil skrive under på, helt uden at blinke.

Datalogi er i dag mange ting. Efterhånden betyder det meget lidt, at der står Cand. Scient. Dat. på et CV -- man er nødt til at se på, hvad konkret, man har lavet. Det kan være en meget praktisk uddannelse, meget teoretisk, eller midt imellem. Jeg er dog enig i, at vi ikke opfylder mange af de behov, du har beskrevet.

Mit argument er, at der er mangler en akademisk disciplin og systematisk tilgang til denne "dekompression", en faglig indsats der gennem forskning og erfaringsindsamling befrier os for lave de samme bommerter igen og igen og igen.

Det er jeg bestemt enig i (også i det meste af dit indlæg fra 16:09). Klokken er lidt i tre i Hong Kong, hvor jeg sidder, så jeg vil vente med et fornuftigt indspark til i morgen. :)

  • 0
  • 0
#21 Troels Liebe Bentsen

Nu er du ikke den først der har skreget efter mere ingeniør tilgang til IT, allerede tilbage i 70'er blev de først tiltag til "Software Engineering" taget og det har kostet den ene software katastrofe efter den anden lige siden.

Problemet er at langt de flest større IT projektet er uhyggeligt mere komplekse en fx. at bygge en bro, hvis formål og funktion har været kendt viden siden en gang før romerriget. Som Torben så fint sige kender vi X, Y, Z på forhånd og vi er rimeligt sikker på at de ikke lige skifter.

På et typisk IT projekt er vi desværre ikke lige så heldige at vi kender funktion og formål og vi bliver desværre nød til at spørge slutbrugeren om hvad det er de godt vil ha, hvilket de sjældent er i stand til at formulere på nogen som helst fornuftig eller målbar måde.

Du har dog ret i at mange af de teknisk krav ikke burde komme som den helt store overraskelse. Fx. er det helt i hampen at man ikke indtænker opgradering, vedligeholdes og sammenkobling til andre systemer ind før man går i gang.

Problemet er bare at de teknisk krav for et typisk IT projekt fylder omkring 5% af projektet, hvilket "Software Engineering" og brobygningsmetaforen også dækker fint. De resterende 95% er bare ikke lige så nemme at få styr på og her har det gang på gang ført til den ene fiasko efter den anden.

De projekter som du selv har lavet er nok langt fra typiske og her er det nok omvendt, så 95% af projektet er tekniske krav du selv har defineret. At jeg så gerne ville have at der var flere PHK'er til at lave de 5%, så vi i det mindste ikke skulle høre på at det forsinkede fiasko projektet heller ikke levede op til de tekniske krav når det langt om længe var blevet kodet færdigt, år forsinket.

I staten er dette dog ikke det eneste problem, "Software Engineering" tanken og den udtømmende kravspecifikation er faktisk det værktøj man har brugt de sidste 10-15år. Ydermere er det også typisk er en Cand.Polit uden nogen IT bagrund der skrive den kæmpe kravspecifikationen og en Cand.Jur fra "Dyrt konsulent hus" til at gøre den ulæselig før opgaven ryger i udbud.

Til det skal så også lægges at man fra politisk hold kun kan finde ud af at lave projekter med et minimum af 7-8 nuller i udbudsprisen, hvilket hurtigt udelukker virksomheder hvor faglighed og ikke fakturerebare timer er i højsædet.

Når "datalogerne" hos "Stor tung bureaukratiske IT virksomhed" så går i gang, bliver system valgene taget på basis af hvad der binder kunden mest muligt til fremtidige konsulenter timer for "udvidet funktionalitet" som nok burde have stået i den oprindelige kravspecifikationen. Det hele ender med at projektet går over budget, bliver forsinket og ikke kan løse havdelen af den opgave det var sat i verden for.

Altså:

  • Kæmpe og dyrt projekt
  • Kæmpe kravspecifikationen
  • Styret af Cand.Polit og Cand.Jur
  • Kodet af "Stor tung bureaukratiske IT virksomhed" = Fiasko

Den logiske slutning burde derfor være at man prøvede noget andet, men det er alligevel stadig opskriften på lagt de flest af statens IT projekter.

  • 0
  • 0
#22 Poul-Henning Kamp Blogger

To kommentarer:

Jeg har været sandsynligvis været hjælpeløs nøgleperson på en større IT-fiasko end de fleste af jer, vi taler om ca. $50M, dengang en dollar faktisk var noget værd.

Ydermere er det også typisk er en Cand.Polit uden nogen IT bagrund der skrive den kæmpe kravspecifikationen og en Cand.Jur fra "Dyrt konsulent hus" til at gøre den ulæselig før opgaven ryger i udbud.

Og her er det så du glemmer:

... Og IT folk der ikke siger fra over for dette makværk.

For der er jo altid nogen idioter der er villige til at påtage sig opgaven, ikke ?

Sammenlign med MetroRingen, hvor tre ud af fire prækvalificerede entrepenører sagde fra, fordi de mente at udbudsmaterialet var en opskrift på en fiasko.

Hvorfor sker det aldrig i IT ?

Poul-Henning

  • 0
  • 0
#23 Carsten Sonne

IT er stadig et ungt fag og en ung videnskab. Det er 300-400 år siden at Galileo og Newton knækkede magien bag trissernes magiske bevægelser. Til sammenligning er det under 100 år siden at Neumann knækkede magien bag computeren bit-flytteri.

I dag hærsker stadig store uenigheder om fundamentale problemstilling i kunsten bag softwareudvikling. Meget få ting er nået til et stadie, hvor det betragtes som anerkendt viden i de bredere videnskabelige kredse. De få "tidsløse" elementer, der er afdækket, finder vej til studier som datalogi.

IT (datalogi) skal modnes både som videnskab og fag. Det er der intet andet end tiden, som kan gøre. Det mener jeg på trods af jeg normal ikke er tilhænger af at lade tiden være den afgørende faktor.

  • 0
  • 0
#24 Poul-Henning Kamp Blogger

Carsten,

Det ikke 300-400 år for Newtons love at blive brugt, de kom i brug indenfor ganske få år, indenfor f.eks skibs-, slots- og kirke-bygning. Det var f.eks Newtons 3. lov der endelig gav en forståelse af hvad stræbepiller gjorde godt for og hvordan de skulle laves. Et lidt mindre solidt argument kan fremføres for at det var Newtons anden lov der langt om længe fik vendt tendensen til tungere og tungere britiske skibe.

Til sammenligning er "The Mythical Man-Month" 35 år gammel i år, men der er stadig, hvert år, IT projekter der kører af sporet fordi man enten ikke ved hvad der står i den, eller tror sig hævet over den slags trivielle problemer.

Burde vi ikke på nuværende tidspunkt have en generation af Software Engineers der havde lært den lektie ?

Eller burde vi i det mindste ikke begynde at uddanne dem ?

At ting tager tid, kan vi ikke blive enige om, men det kommer til at tage unødvendig meget længere tid, hvis vi ikke engang prøver...

Poul-Henning

  • 0
  • 0
#25 Carsten Sonne

Poul-Henning,

Selvfølgelig skal vi prøve. Det er bare svært at skyde på individet. Når man ikke har nogen konkret anerkendt viden at holde en argumentation op på, men blot kan referere til diverse forfattere, IT guruer ol., er det meget svært. Argumenterne kan næsten altid skydes ned med henvisning til andre forfattere og IT guruer med en anden overbevisning.

Tilbage er blot at sige nej, ud fra egen forudsætning og overbevisning. Præcis som du fremføre. Vi ved bare alle, at ikke altid er lige nemt. Specielt ikke når der er sociale relationer og/eller penge involverede.

Mvh

  • 0
  • 0
#26 Troels Liebe Bentsen

Til sammenligning er "The Mythical Man-Month" 35 år gammel i år, men der er stadig, hvert år, IT projekter der kører af sporet fordi man enten ikke ved hvad der står i den, eller tror sig hævet over den slags trivielle problemer.

Nu er jeg selv også stor fan af "The Mythical Man-Month" som jeg faldt over i forbindelse med mit special, og jeg syntes også det er synd den ikke var en del af min grunduddannelse, men problemet er nok bare for den grå masse, at man skal have været på et software projekt for at kunne se hvor relevante alle pointerne stadig er. Hvilet for de flest studerende først er tilfældet når de en gang er færdige med at studere.

... Og IT folk der ikke siger fra over for dette makværk.

For der er jo altid nogen idioter der er villige til at påtage sig opgaven, ikke ?

Jeg tror du vil bliver overrasket over hvor får IT folk der typisk er involveret i beslutningsprocessen, i modsætning til entrepenører opgaver tror gud og hver mand at de er i IT eksperter hvis de har taget det store PC kørekort. Det er trods alt de færreste der kaster sig over en storebæltsbro hvis deres kvalifikationer er makroøkonomisk teori eller kontraktret.

Det du i virkeligheden snakker om er fagligstolthed og faglighed eller nærmere mangle på samme, og ja du har ret i at det er en mangel vare i IT branchen. Men jeg tror ikke du kan give datalogerne skylden for det, specielt set i lyset af hvor få der faktisk kommer igennem uddannelsen.

Men min pointe fra før, var nu at jeg ikke tror på det hjælper noget som helst at kigge på hvordan man gør det ingeniørs verdenen, IT != Brobygning, jeg ser i højere grad IT som et håndværk hvor faglighed kommer gennem erfaring og mesterlære. For mit eget vedkommende har det været open source projekter og de forskellige jobs jeg har haft de sidste 10 år, du kan have ret i at man måske burde have flere praktiske kurser hvor man fik nogen gamle rotter som dig til at dele deres erfaring, så nyuddannede IT folk ikke var helt blanke når de forlader studiet.

  • 0
  • 0
#27 Peter Favrholdt

Er det ikke tit alle de andre aspekter (end den primære funktion) som får projekterne til at fejle?

Som f.eks. * Svartider? * At systemet skal kunne vedligeholdes/opgraderes? * At systemet er distribueret og at de enkelte komponenter er indbyrdes afhængige? * Kamp om ressourcer (cpu, memory, io)?

I den virkelige verden er sådanne krav overladt til "trial and error". Vi bygger systemerne og så tester vi at det (forhåbentligt) er godt nok.

Min tese er at nuværende højniveau sprog er udviklet til at løse første-års-opgaver i datalogi. Og at de er uegnede til at implementere systemer i den virkelige verden. Vi gør det så bare alligevel - men det er en kunstart (der kræver erfaring og håndelag). Og rigtig mange aspekter bliver der taget hånd om "mellem linierne" (ikke at det hjælper at programmere i maskinkode - det gør det blot værre).

Jeg prøver lige at forklare det lidt mere:

Normalt løser vi store opgaver ved at bryde dem ned i mindre opgaver der løses hver for sig. Og senere sættes mindre dele sammen til et større system. Det fungerer vældig fint f.eks. når vi udvikler elektronik (eller bygger et hus eller en storebæltsbro). Der findes udførlige datablade på hver komponent, der sættes sammen til en større helhed ud fra disse datablade. Og overholder delkomponenten sin specifikation - og har system ingeniøren gjort sit arbejde rigtigt - så virker det samlede system som det skal.

Med software derimod... her sætter vi delkomponenter sammen og kigger kun på "interfaces" og dokumentationen af den primære funktion som komponenten løser (API'et).

Når vi så har sat det sammen - så sker der noget uventet. De enkelte komponenter kommunikerer nemlig pludselig uden om deres interfaces: i den indbyrdes kamp for ressourcer (cpu, memory, io osv). Eller antagelsen om at en anden komponent er "klar" holder ikke.

Jeg mangler stadig at se et "programmeringssprog" hvor delkomponenters ressource-krav er "first-class". Så kunne compileren tjekke at tidskrav/svartider er overholdt - mens vi skriver koden - og allerede inden programmet køres.

Men det kræver altså at tid er noget helt andet end "underlige sideeffekter vi først ser på når programmet er bygget".

Prøv f.eks. at skrive "man 3 sleep" på en Linux-maskine.

Det bliver hurtigt meget kompliceret at lave et simpelt program der blot skriver hvad klokken er hvert sekund (og prøv så at lave det så worstcase jitter er mindre end 1 mikrosekund).

PS: jeg ved godt at der er noget der hedder en PLC. PPS: sproget "Ada" har faktisk primitiver der handler om tid: wait og wait_until. Men C/C++ og Java, her er det overladt til funktions-biblioteker.

  • 0
  • 0
#28 Haktan Bulut

Jeg kunne ikke rigtig se pointen med din intifada mod dataloger andet end at Varnish-hesten skulle piskes lidt, men nu er debatten da drejet over i en retning, som trods alt har noget substans.

Du kan godt påstå, at dataloger er dårlig klædt på fra skolen til at håndtere en virkelighed omkring IT, hvor alle kan have holdning - også på svært faglige områder - og hvor viden og beslutningskompetence sjældent er samlet. Se bare debatten omkring billing, hvor folk kan udtale sig om hvor svært det at bygge sådan noget på trods af at de med garanti aldrig været i nærheden af en linje billingkode eller programmering.

Det er det et stykke tid siden, at jeg blev færdig på DIKU, men dengang kunne man tage et kursus i systemudvikling med Hasse Clausen, som klædte en lidt på i forhold til hvordan systemudvikling kunne ende i virkeligheden. Pensum indeholdte artiklen "Fire perspektiver på systemudvikling", og specielt perspektivet systemudvikling som politisk proces må siges at være ret rammende for de fleste IT-projekter. Det er fejlagtig at tro, at mer maskinnært uddannelse eller anvendelsen af "kommercielle" programmeringssprog/db vil klæde datalogerne bedre i forhold til de fleste IT-projekter i virkeligheden - det er sjældent at man får fornøjelsen af, at kunne skrive en http-accelerator i vacuum.

Hvis man skulle gøre noget, skulle man have tilbyde kurser i forhandling, konflikthåndtering og mediation på datalogi-studiet for studerende som har ledelsesmæssige ambitioner. Spørgsmålet bliver hurtigt, hvordan man fordele de 5 år man har til at putte viden i studerendes hoveder.

Personligt har jeg været meget tilfreds med fordelingen og særligt den tidsløse del i det (blyant #2), da alt anden som regel var afrundingsfejl deraf.

Jeg er ked af at sige det, men den utopiske verden hvor alle programmører er udstyret ubegrænset mængde "gå-hjem-du-er-fyret"-kort findes ikke.

  • 0
  • 0
#29 Anonym

En væsentlig forskel mellem en bro og et it-system er levetiden og hvor dybt den griber ind i processers dynamik.

Man kan både bygge en bro forkert og man kan bygge en forkert bro rigtigt - "processrigtighed".

Problemet med megen IT er at man prøver at bygger den forkerte løsning rigtigt - "løsningsrigtighed".

Det løser IKKE problemet at bygge løsning rigtigt uden at se på om det er den rigtige løsning - som jeg synes denne diskussion meget drejer sig om.

En bro bygges for lang tid og stor holdbarhed. Samtidig er den meget interoperabel så længe det ikke drejer sig om at udvidde kapaciteten eller anlægge en type transport, broen ikke var designet til.

Bygninger antages at blive liggende længe - des større desto mere. Og der ligger en forståelse af at beslutninger er ikke-reversible inden for rimelighedens grænser. Man "lægger rammer" for samfundet og det tilgås ofte med stor varsomhed med planlove, høringer og krav i hele processen.

Vi har gode it-løsninger som følger lignende principper, men det er sjældent at hele løsninger tilgås på en måde som blot ligner.

Et it-systemforældes (antagelig) hurtigt og er ofte designet med et forhastet fokus på at tilvejebringe funktionalitet uden f.eks. at tilsikre fleksibilitet og understøtte kontinuert tilpasning og forandring. Alle andre end it-folk antager at man nemt kan lave ændringer - "det gør man hele tiden så hvorfor bekymre sig !?"

Udviklingen går vanvittigt hurtigt. Vi har diskuteret Fehmern, Storebælt og Øresunds broer siden før TCP/IP blev påbegyndt. Men jeg vil da uden at blinke påstå at TCP/IPs betydning for samfundets infrastruktur er størrelsesordener større for det danske samfund end samtlige broer tilstammen - både hvad angår risiko og værdiskabelse.

Tilsvarende tilgås kritiske beslutninger i nutiden nærmest hovedløst - fordi man kun ser på umiddelbar funktionalitet og til nød "pålidelighed", men glemmer kritiske aspekter interoperabilitet, fleksibilitet og navnlig at undgå single-points-of-failure - specielt sidstnævnte betragtes som en feature i ministerierne.

Ser man på de mest kritiske infrsatruktur-aspekter som identitet og kommunikation bliver situationen katastrofalt ringe fordi det tilgås som en quickfix der skal give resultater indenfor en regeringsperiode. Man bygger ikke (rammer for) samfund.

Pointen er dobbelt.

En ting er om man udvikler pålidelige systemer med færre fejl og større resistens mod utilsigtede aspekter (såsom at brugerne ikke gør som planlagt).

En anden er at man tilgår specielt infrastrukturdigitalisering som om det er ønskeligt at al digital trafik skal ind over Rådhuspladsen for at stå i kø til id-check og stripsearches.

Hvis man beslutter det sidste først, så kan man spilde nok så mange ressourcer på at lave systemer "pålidelige" og uddanne nok så meget i at "lære af fejl" - de bliver aldrig pålidelige eller fejlfri.

Det svarer til at bygge en Størrebæltsbro mellem Rådshuspladsen og Husum Torv samtidig med at man lukker alle andre indfaldsveje til København og Århus. Broen kan blive nok så flot og "holdbar", men det er stadig fejl på fejl på fejl.

Kan man gøre de enkelte steps i processen bedre? Ja - indiskutabelt fordi det er relativt dårligt i dag, men det er stadig en afvejning af pris versus formålnødvendighed. Typisk glemmer man at regne opgraderingsomkostninger med.

Men som Peter Favrholdt også siger, så er systemet mere (men ofte også meget mindre) end summen af komponenterne.

Broen til Rådhuspladsen kan være bygger med alle de rigtige komponenter på den helt rigtige måde - men det er stadigt ikke en løsning på et problem, men en måde at tvinge samfundet til at tilpasse sig en magtbeslutning. Og det danske samfund lider under de mange Rådhusbroer som bygges af forkerte årsager.

Valg af bro over Storebælt har en vis men overskuelige indflydelse på trafikken i Esbjerg, men i den digitale verden har "Rådshudspladsbeslutninger" dramatisk og kritisk indflydelse på alle andre processer.

Vi behøver kun at pege på Tinglysning for at konstatere at man bygger selv rigtige broer forkert. Men det bliver først rigtigt kritisk når man bygger forkerte broer forkert og lukker for alle alternativruter som det f.eks. sker med eDag3

Kan man kritisere "dataloger" for det?

Ja - det mere kritisk del af infrastruktur, desto højere krav må man stille. Og hvor er det faglige oprør?

Det største problem er ikke om "dataloger" kan forhandle, men om de kan indgå i at validere løsningen i et samfundsperspektiv - fordi det kan DJØFerne heller ikke.

Ministeriet for Bygning af Broer til Rådshuspladsen - i Daglig tale Finansminsteriet - har brug for hjælp. Og det primære behov er IKKE at bygge bedre broer, men af at validere om en bro løser eller forværrer de reelle problemer.

  • 0
  • 0
#30 NA NA

Nej, de fejler ikke af alle de årsager, de fejler fordi der ikke er fagfolk der siger nej til alle disse tåbeligheder.

Poul-Henning - nu nævner du selv Tinglysningsprojektet og der sagde en stor del af de teknisk ansvarlige op hos CSC - det er en nærliggende tanke at det var deres måde at sige nej på.

Da du ikke fremkommer med et eneste eksempel på et IT projekt der er fejlet på grund af datalogers manglende maskinnære fokus så har jeg to forslag til hvem vi skal ansætte:

  1. Dygtigere ledelse som rent faktisk lytter til hvad datalogerne siger.
  2. Dygtigere version 2 bloggere.
  • 0
  • 0
#31 Jesper Louis Andersen

Datalogi er en teoretisk uddannelse, som første bliver praktisk anvendelige efter nogen "dekompression" i den virkelige verden. Det vil du finde mange IT chefer der vil skrive under på, helt uden at blinke.

Det store spørgsmål er at om du kan gøre det hurtigere. Du har 5 år til at give folk viden (og med den nuværende regering, så er det 5 år sharp). Der skal dermed vælges hvad det er man sætter sin tid af til. Datalogiuddannelsen har valgt en model hvor man først giver en bred basis efterfulgt at et mere specialiserende forløb - startende fra den teoretiske side.

En alternativ model er at starte mere praktisk og så efterhånden bygge teori på. Faren ved den model er, at du kan ende med at al udvikling foregår i Java eller C. Og det er mindst ligeså skadeligt som dekompressionen. Lidt mere generelt, så skal man undgå en enkeltværktøjsmentalitet på den type uddannelser.

Personligt tror jeg at den datalogiske model er den stærkeste. Nuvel, der skal foregå en "dekompression", men min påstand er at den foregår meget hurtigt. Hvis du som leder sætter en nyudannet, grøn, datalog til at stå i spidsen for et projekt, uden at koble en gammel ræv på det, så er du, som leder beset, naiv. Datalogen har muligvis, muligvis ikke, den faglige basis for at gøre projektet til en success - men vedkommende har givetvis ikke de politiske og diplomatiske færdigheder til at drive et projekt i en større virksomhed. Langt de fleste projekter kuldsejler ikke af tekniske årsager - men af at man ikke forholder sig realistisk til hvor lang tid software tager at udvikle. Jeg mener ikke du kan læse dig til dette. Der kræves en vis mængde erfaring i praksis, og det er modulo uddannelse fra ITU, DTU, DIKU, DAIMI, etc.

En meget stor fordel ved den nuværende model som DIKU praktiserer er at en HCI-uddannet, der koncentrerer sig om at optage mennesker foran skærmen og studere deres opførsel i forbindelse med anvendelsen af programmer -- han eller hun ved også noget om at skrive oversættere. Vedkommende kender muligvis ikke detaljerne i SSA-PRE eller closure conversion, men alligvel nok til at vide hvorledes man skriver en ikke-optimerende oversætter for et mindre sprog. Og den bredde gælder begge veje. En overvejende oversætterhaj har ofte (og nu obligatorisk) et par fag om HCI. Og HCI er en væsentlig disciplin hvis programmet skal anvendes af ikke-teknikere.

Mit bud er at en stor del af den "dekompression" du nævner handler om rutine og erfaringsdannelse. Og det er jeg ikke sikker på du kan lave en uddannelse som dækker.

Og så kan man passende overveje om du kan komme ind fra gaden og sige "I know bridge building", få dig et job og så lige designe en bro over til Amager. Eller "I know pharmaceuticals" og så lige designe en pille til gigtsmerter. Der accepteres simpelthen for meget i IT-verdenen lige nu, og det er formentlig en effekt af at faget er ungt.

(Sidebemærkning: Brobygning er en elendig sammenligning. Som enhver Civ4-fanatiker vil vide kan man bygge broer når man har researchet "Construction" i tech-træet, og den tech ligger meget tidligt. Historisk set passer det meget godt med virkeligheden hvor grækerne gladeligt byggede menneskeskabte broer. De har haft en sjat år til at forbedre deres brobygningsfærdigheder. Det samme gælder kloaknet, vandforsyning og så videre. Og samtidig betyder det at det underliggende regelsæt er forholdsvist simpelt.)

  • 0
  • 0
#32 Henrik Kramselund Jereminsen Blogger

Sikke mange gode indlæg omkring uddannelser.

Jeg er selv datalog fra DIKU og jeg har haft fornøjelsen af at snakke dette emne med PHK flere år i træk på TheCamp - vi har ihvertfald flere gange berørt det.

Jeg er meget enig med Jesper Louis, det er en stærk metode at undervise i "tidsløse" teknologier og jeg tror det er gennemgående fra Universitetsuddannelser. Man lærer at lære, og ved at man kan meget lidt.

Når man så lærer skal man vide hvad man kan og stole på det. Det kommer således i dekompressionsfasen og jeg tror egentlig at den uddannelse jeg fik har været med til at styrke min udvikling i den rigtige retning, som så har skiftet efterfølgende.

Jeg tror sagtens man kan lære at udvikle store projekter uden at være datalog, men det skader ikke - og det er nødvendigt at vedligeholde sin viden uanset hvilken uddannelse man har.

Der er eksempelvis et antal bøger som er både klassikere som man bør læse, nogle af dem måske endda for at UNDGÅ at falde i de fælder, og Mythical Man Month er jeg ked af først at have købt efter DIKU.

Når alt det så er sagt er der for mange projekter der ender på enkeltpersoner som tror de kan overskue det hele - og selvom disse er åbne for kritik er det svært for andre at kunne lave det komplette "sanity check".

Eksempelvis vil man formentlig lave kontrolberegninger på brobyggerierne og der er bedre modeller for det end jeg umiddelbart kender til for softwareprojekter, eller for den sags skyld infrastrukturprojekter.

Hvordan måler jeg om et foreslået projekt med routere, firewalls, loadbalancere, switche, WAN, VPN, applikationsservere m.v. er solidt og robust - og værre endnu, når kundens første antagelse om krav til kapacitet ikke holder. (og så har vi ikke engang snakket om økonomien i et sådant projekt som yderligere sætter grænser)

  • 0
  • 0
#33 Rene Nejsum

Da storebæltsbroen blev bygget er jeg forholdsvis overbevist om at ingen halvejs inde i projektet kom og sagde "Vi har fået en fantastisk idé: hvis vi sætter et loop på det yderste spor har salgsafdelingen regnet ud at vi kan tage kr 4.000 ved bommen. Desuden vil det se fantastisk ud. I er jo kun nogle få hundrede meter ude med asfalten, så der skal ikke laves noget om. Kan I ikke lige bygge et sådan loop på? vi kan jo altid tage det ned, hvis det ikke bliver en success."

Nej, det er meget nemmere at bygge broer :-)

/rene

  • 0
  • 0
#34 Deleted User

Jeg er på 5 semester som datamatiker. Her på uddannelsen har vi om system design, system udvikling, IT i organisationer og system udviklingsmetoder (1). Vi bliver uddannet til at lave store systemer i projektgrupper som kan smides på arbejdsmarkedet. Lærer man ikke dette på datalogistudiet? Altså udviklingsmetoder og system design? Jeg vil sige at dette er væsentlig for at lave gode systemer? Lige umiddelbart vil jeg sige at dataloger ikke lære dette da en datalog vel bliver udannet til at forske, og ikke at bygge?! Bagefter mit "datamatiker grundforløb" tager jeg en overbygning i softwareudvikling (2), på ca 2 år. Jeg vil da våge og påstå at jeg med mine alt i alt 5 år er rimlig godt rustet til at lave gode, store og robuste systemer. Nok bedre end datalogen? Der hvor datamatikeren falder lidt af på den er nok algoritmedesign (selvom vi også lærer om dette på uddannelsen) og algoritmekompleksitet. Dog er vores computermodeller endeligt store :)

Jeg er ikke ude på at kritisere nogen her, men jeg synes lige jeg vil nævne datamatikeruddannelsen, nu hvor alle andre IT-uddannelser er blevet nævnt i denne diskussion.

(1) - http://www.akademiaarhus.dk/videreg%C3%A5ende+uddannelser/it+og+teknik/d... (2) - http://www.akademiaarhus.dk/videreg%C3%A5ende+uddannelser/it+og+teknik/p...

  • 0
  • 0
#35 Anonym

En betragtning som mange glemmer er at uddannelse ikke er nok i sig selv - det er kun en måde at accellere læring.

Det er ikke normalt at nogen går direkte fra en skole ud i virkeligheden og kan indgå direkte i praktisk problemløsning.

Omvendt er det heller ikke normalt at opbygge en høj grad af abstraktionsevne på et komplekst fagområde uden mange års skolegang.

  • 0
  • 0
#36 Carsten Sonne

Software engineering handler i høj grad om teknik og tekniske kompetancer. Men det handler også om at kunne gennemskue konsekvenserne for softwaren når den slippes løs i det domæne som den skal virke i. Lang mere væsentligt er det at kunne gennemskue konsekvensen for softwaren når domænet, kravene og skabelsesproccessen ændre sig.

Det er selvsagt ikke en software ingeniørs fornemste opgave at være leder. Men det er hans opgave at kunne gennemskue den indflydelse på softwaren som forskellige omstændigheder kan have. Det er også hans opgave at gøre relevante personer opmærksomme på disse konsekvenser.

Det kan ikke undskyldes med at omstændighederne ikke er tekniske. Softwaren er teknisk og dens virke påvirkes i en altafgørende betydning af den verden der findes rundt om softwaren.

  • 0
  • 0
#37 Anonym

Det omvendte er langt mere vigtigt - dvs. den indvirkning teknologidesign har på den omliggede verden og de samfundsprocesser den har indflydelse på.

Det er præcis der man fejler. På samfundsplan er teknologidesign ikke en optimeringsøvelse, men en øvelse i at understøtte kontinuert forandring og tilpasning i en foranderlig verden.

Når man fjerner frihedsgrader - specielt i infrastrukturen, så skader man samfundets evne til at forny sig. Den offentlige sektor og infrastrukturens kartelsamarbejder vælter med den slags fejl og fejlene har aldrig været større end hvad man er i færd med at påtvinge samfundet i øjeblikket.

Om der er softwarefejl i de systemer betyder mindre - den store skade sker hvis de virker osm de er designet til - at fastlåse samfundsprocesser omkring centale knudepunkter & magtinteresser.

  • 0
  • 0
#39 Anonym

Det må så være de software ingeniører, som vælger at blive politikkers, arbejde.

Det er præcis den måde DJØF-laget frasiger sig ansvaret for den meget stærke magt de udøver via it-design.

Sammenlign f.eks. den omfattende politiske indblanding i borernes miljøpåvirkning kontra det nærmest totale fravær af politisk styring af f.eks. digitaliseringsstrategien på trods af at sidstnævnte har flere størrelsesordener større indflydelse på samfundet.

Når det kommer til it, så køres politikerne rundt i manegen af specielt embedssystemet og intereessernes lobbyisme. De kan gå op i detaljer som hvorvidt de sidste x procent af hustande har internetadgang og hyle op om "it-anafalbetisme, men at man - ved at fratage borgerne indflydelse - gør borgerne it-mæssigt inkompente og den offentlige sektors effektivitet systematisk falder, forbigås i tavshed.

Den direkte relevants er at PHK taler om uddannelse til design med inddragelse af forståelse af lowlevel tekniske aspekter, mens de langt mere omfattende samfundsøkonomiske, magtkoncentrations, og teknisk sårbarhedsskabende og innnovationsbegrænsende aspekter varetages langt ringere end low-level tekniske aspekter.

Hvem har f.eks. i Tinglysningsprojektet taget stilling til hvordan man gradvist kan udskifte hash-mekanismer fordi collision i hashmekanismen udgør en stigende trussel for at en angriber simpelthen kan manipulere indholdet af en indgået aftale med tilbagevirkende kraft !?

Tinglysninger er langtløbende rettigheder og forpligtelser, men ingen sikkerhedsmekanisme kan i dag forventes at have en levetid som blot tilnærmelsesvis lever op hertil.

Min pointe er ikke kritik af Tinglysningsprojektet, men at uddannelsessiden er langt bagud i forhold til nutidens udfordringer.

  • 0
  • 0
#41 Lars Bjerregaard

Lad mig sige det på en anden måde: Jeg finder dagligt det kollosale skisme mellem etableret viden, og virkelighedens praksis ekstrem. Jeg vil argumentere for, at problemet bunder i, ikke så meget at vi ikke ved hvordan tingene skal gøres, men at IT branchen stadig er præget af en bizar "gold-digger" mentalitet, som om at dotcom-bølgen aldrig brast. Jeg observerer hver dag:

  • Ekstremt kortsynethed
  • Grådighed
  • Går-den-så-går-den
  • Vi lukker øjnene og så sker der nok ikke noget slemt.

Når man ikke følger praksis for hvordan fejl undgås, og så forventer at ingen fejl opstår, så er man sgu selv ude om det. Når man kan ignorere Mythical Man Month, og tro at man ikke kommer til at lide under de beskrevne følgevirkninger, hvilket syndrom lider man så af? Hvad end navnet er, så har vi (branchen) det. Sørgerligt men sandt.

Et af de største chok jeg har modtaget var, at komme ud som nyuddannet, nogenlunde godt klædt på, for så at finde den ekstreme grad min tilegnede kundskab blev ignoreret i praksis. Jeg var sgu lige ved at blive fyret et par gange for at bjæffe op om det, indtil jeg lærte bare at holde min kæft- for det meste....

  • 0
  • 0
#42 Carsten Sonne

Når man kan ignorere Mythical Man Month, og tro at man ikke kommer til at lide under de beskrevne følgevirkninger, hvilket syndrom lider man så af?

Som jeg ser det, handler det om modenheden. Teserne i "Mythical Man Month", er tilsyneladende ikke rigtig anerkendte. Hvis man betrageter IT uddannelserne over en bred kam, er det forbasende forskelligt hvad der betragtes etableret viden. Det gennemsyre ikke kun uddannelserne men hele samfundet.

Efterhånden som man bevæger sig fra de rå bits og højere op i abstraktionsniveau, med toppen som det Stephan beskriver, så bliver den anerkendte viden mindre og mindre. Hvad der foregår i toppen af videnspyramiden, kan sammenlignes med lægevidenskaben i 1200 tallet.

Grundforskning og grundviden kommer altid fra den akademiske verden. Herefter spredes den langsomt igennem uddannelse ud til befolkningen. Sådan har det altid været.

IT branchen er umoden i ekstrem grad, sammenlignet med etablerede brancher som f.eks. byggeriet. Samfundsdebatten og profilen af certificeringer i modenhen bevidner dette til fulde.

  • 0
  • 0
#43 Morten Bøgh

Der er kommet en mere nutidig afløser for bogen 'The Mythical Man-Month'. Den hedder 'Software Project Secrets: Why Software Fail', fra 2005. Anbefales. 'The Mythical Man-Month' stammer fra en tid hvor 'mongolian horde' princippet for software-udvikling havde en vis ræson: Det var dengang det at skrive mange kodelinier krævede mange programmør-timer. Hvilket så medførte at store projekter sandede til i interne kommunikationsproblemer mellem alle aktørerne, etc.

Men i 2005 er problemet grundlæggende et andet: Hvis en opgave kræver ekstremt mange kodelinier, må det skyldes at automatiseringsgraden i det valgte sprog eller værktøj er for lille. Find et andet værktøj, eller skriv et selv. Brug scripting-sprog eller vælg det rigtige ERP system, automatiser rutinearbejde. Software udvikling burde være en meget mere dynamisk proces i dag end for 35 år siden, hvor 'The Mythical Man-Month' udkom. Men er det?

Bogen 'Software Project Secrets: Why Software Fail' er et angreb på software-engineering synspunkterne: at software-udvikling skal tage lære af brobygning. Nej: software er 'soft' og formbart, ændringer sent i projektforløbet er acceptable (hvis man kan overskue dem). Og hvis 1 km software koster 1 million kroner, koster 10 km software fra samme skuffe formentlig ikke over 1,5 million kroner. At lave mere af det samme koster stort set ingenting i software-udvikling. I modsætning til vejbygning. Så hvis man vil lave software skal man netop ikke tage ved lære af vej- og broingeniørerne - deres tankegang er alt for lidt dynamisk.

Et andet paradox fra bogen: Når den perfekte kravspecifikation er skrevet, er systemet færdigt. Programmering er ikke andet end ekstremt detaljeret specifikation af hvad systemet skal kunne - udtrykt i et sprog som egner sig til en sådan beskrivelse, nemlig et velvalgt programmeringssprog. (Hvis programmering drejer sig om noget andet, fx om at håndtere begrænsninger i hardwaren, så er der noget galt med abstraktionsniveauet i sproget eller værktøjet). Dvs drømmen om den perfekte kravspecifikation som oplæg til edb-udviklingen er absurd. Den gode kravspecifikation er som et manuskript, det færdige system er som den mange-faceterede film der skabes gennem det videre arbejde. I modsætning til brobygning, hvor man normalt har specificeret alle detaljer i bro og byggeproces inden den første wire skydes over kløften.

Hvad skal datalogistudiet bruge disse provokationer til? Bogen er nok bedre til diagnosticere sygdommen: Why Software Fail, end til at ordinere en kur. Men svaret er vel som i alle brancher: Man skal kunne sit fag, og have forståelse for det specielle ved netop dette fag. Hvad enten det er VVS eller datalogi. Men man skal ikke tro at datalogi er en slags VVS-arbejde: Vælg komponenter. Forbind dem. Trykprøv det hele. Færdigt arbejde. Datalogi er programmeringssprog og databaser.

  • 0
  • 0
#44 Poul-Henning Kamp Blogger

Morten,

Det er en interessant bog, men jeg synes den har en tendens til at beskrive en drømmeverden og stride lidt for meget imod erfaringen.

Og den erstatter på ingen måde The Mythical Man-Month, der indholder et antal observationer der er 100% tidsløse, vedrørende selve opgavens natur.

Tag f.eks spørgsmålet om hvor megen indsats der skal bruges på hhv. "program", "program produkt" og "system program produkt" (Jeg plejer at forsætte rækken med "standardiseret system program produkt")

Lars:

Det er ikke urimeligt at mene at systemkonstruktion som disciplin blev bombet 20år (and counting) tilbage af dot-com bølgens influx af "det kan jeg klampe sammen i 4 linier PERL" amatører.

Carsten:

Jeg er enig med sammenligningen med lægevidenskaben i 1200 tallet, men ikke I at fremskridt alene kommer fra akademia, tværtimod var det i stort omfang industriens folk der så behovet for normer og standardiserede metoder.

Poul-Henning

  • 0
  • 0
#45 Morten Bøgh

Edb drejer sig om at løse konkrete problemer, og ikke altid om at lave 'standardiserede system program produkter'. Tilsvarende skal løsningen på et konkret problem ikke altid findes ved at søge blandt 'standardiserede system program produkter' på markedet. Man kan også bare løse det: programmere en løsning. The Mythical Man-Month handler om skabelsen, programmeringen af mainframe operativ-systemet OS/360 - en titanisk opgave. I dag har vi nok de operativsyster vi fortjener, vi har de sprog vi har brug for, og især har vi de database-systemer som kan strukturere vores løsninger. Det burde være meget nemmere og billigere at lave edb i dag end for 35 år siden. Men er det?

Det er rigtigt at struktur, arkitektur og enhver form for tværgående hensyn er vigtigt når man udvikler edb. Parodien er firmaet som kører sin administration via 337 forskellige regneark, udviklet hen ad vejen.

Det er også rigtigt, at hvis der findes et 'standardisteret system program produkt' som rammer området rigtigt godt, så bør man bruge det generelt.

Det er også rigtigt, at hvis man kan ane konturerne af et 'standardiseret system program produkt' på et nyt område, så bør man gå efter guldet og udvikle det.

Alligevel: At der i de forløbne 35 år er sket store fremskridt med sprog, med scripting, med operativsystemer og især med databaser, burde give en fornuftig niche for ren skræddersyet edb. Især databaser: at SQL har fjernet en utrolig masse rutinemæssig algoritmekonstruktion vedrørende data-access fra vore programmer - det burde gøre det overkommeligt at programmere 'resten'. Ikke 'nemt', men 'overkommeligt'. Databasebegrebet har også givet et godt bud på hvordan firmaets edb-side skal hænge sammen - nemlig datamæssigt.

Så her har vi en Frode-Fredegod drømmeverden befolket af dataloger der programmerer ovenpå en velstruktureret database. Jeg synes ikke det lyder så tosset.

  • 0
  • 0
#46 Carsten Sonne

Fremskridtet opstå i samspillet mellem forskellige institutioner.

Den traditionelle universitetsverden driver grundforskningen. Forskning som ingen ved om kan bruges til noget konkret. Målet er blot at frembringe viden. Ingen andre end universisterene har den mulighed.

De erhvervsrettede universiteter, som DTU f.eks., driver hovedsageligt erhvervsrettet forskning. Det skal være et konkret anvendelsesformål med forskningen, i modsætning til grundforskning.

Virksomhederne driver innovationen. De bruger bl.a. viden fra den akademiske verden til at udvikle nye produkter. Standarder og normer opstår på initiativ fra brancheorganisationer eller fra myndigheder.

Det er den måde viden og fremskridt heraf, typisk fremkommer.

Inden for IT er det, efter min overbevisning, helt nede på grundforskningsnivaeu, at viden mangler. Før grundviden er på plads kan den erhvervsrettede viden, innovationen og standarderne ikke falde på plads.

Nuvel, IT (datalogi) er nået langt de sidste 35 år. Men hvis man sammenligner IT med andre langt mere etablerede videnskaber og fag, så er IT dog stadig kun i sine spæde barndom.

  • 0
  • 0
#47 Jesper S. Møller

... andre gør ikke.

Hvis man kigger på "softwarefolk" rent generelt så er det sgu' bare ikke de typer, der havner i beslutningstagernes rolle.

Jeg fandt en enkelt oversigt over folketingsmedlemmer med uddannelse, og selvom den er nogle år gammel er det tydeligvis ikke IT baggrundene, der er fremherskende; Men scient.pol'er, jurister, etc. er der spandevis af. Og alle mulige andre typer: http://forsiden.3f.dk/assets/pdf/SD88925.PDF

Næ, jeg tror ikke rigtig IT folk gider/orker "magten" til at gå forrest og sige "you're doing it wrong" til den politiske ledelse.

(Vi blev vel "IT-folk" fordi vi var relativt bedre til at få maskiner til at makke ret)

  • 0
  • 0
#49 Jesper S. Møller

Idag er OS/360 peanuts, f.eks i forhold til Skat's ny "supersystem".

... hvilket er forstemmende, og skyldes at integrationsopgaver er sværere end de burde være. Det med at opfinde fornuftige, platformsuafhængig integrationsmetoder er overladt til virksomheder, der fokuserer på lock-in, eller "industrikonsortier/standardgrupper", der fokuserer på at udvikle for svage metoder, så de enkeltvis kan konkurrere på unikke features.

Der mangler en brik dér, så man slipper lettere end med WSRP, SAML, SOAP, m.v. blot for at integrere UI og services på tværs af leverandører, systemer, etc. Med andre ord, en integrationsløsning for år 2010, som er lige så sømløs og nem at forklare som Unix pipes var i 1973, og gerne lige så langtidsholdbar, og som kan skalere fra embedded til "internet scale". I sandhed en "pipe dream" :-)

  • 0
  • 0
#50 Anonym

Næ, jeg tror ikke rigtig IT folk gider/orker "magten" til at gå forrest og sige "you're doing it wrong" til den politiske ledelse.

(Vi blev vel "IT-folk" fordi vi var relativt bedre til at få maskiner til at makke ret)

Og dermed accepterer man at blive misbrugt til at få mennesker til at makke ret. Teknologidesign fastlåser samfundsprocesser medmindre de eksplicit er designet til ikke at gøre det.

Carsten Sonne Larsen skrev:

Virksomhederne driver innovationen. De bruger bl.a. viden fra den akademiske verden til at udvikle nye produkter. Standarder og normer opstår på initiativ fra brancheorganisationer eller fra myndigheder.

Det er den måde viden og fremskridt heraf, typisk fremkommer.

Det må jeg erklære mig uenig i. Det er en udbredt myte. Nej, kunderne driver innovationen - når de siger nej og vælger noget andet presses organisationer til at tage sig sammen. Standarder og normer tjener i stadigt højere grad som kartelstrukturer til at forhindre kunderne i at vælge fra. Det er derfor at de kun designes så de er åbne indenfor standarden, men ikke overfor konkurrence som fornyer ved at udvide og ændre.

Inden for IT er det, efter min overbevisning, helt nede på grundforskningsnivaeu, at viden mangler. Før grundviden er på plads kan den erhvervsrettede viden, innovationen og standarderne ikke falde på plads.

Helt enig - og det er langt værre end de fleste antager.

IT-infrastruktur udgør lovrammerne for det digitale samfund - selve det digitale markeds rammebetingelser. Og når man ikke designer bevidst efter det, så skader man markedsdannelsen. Det gør så totalt galt i den offentlige sektor som hverken i teknologidesigne eller øknomistyring evner at tilpasse processerne til behovene.

  • 0
  • 0
#52 Donald Axel

Jeg må ikke svare på PHK's vegne men kan ikke dy mig: Jeg hører ikke PHK sige at uddannelserne er værdiløse, tværtimod er den fundamentale fysiske forståelse (punktformige lodder) et udmærket begyndelsespunkt.

Man kunne forestille sig en uddannelse, der arbejder med IT-maskineriets interne kommunikation; det findes på RUC hvor der bliver benyttet litteratur på linie med flg.: Computer Systems Design and Architecture (2nd Edition) [Hardcover] Vincent P. Heuring (Author), Harry F. Jordan (Author):

Af beskrivelsen på Amazon fremgår det, at det ikke er for begyndere.

TO THE STUDENT We assume that you have had experience with computers as an end-user, and that you have written programs in some high level language such as Pascal, C, or Fortran. We also assume that you have had exposure to digital logic circuits. [...]

Så det der ikke findes, er en uddannelse, der forudsætter at folk har grundlæggende kendskab til computerteknik. Og der er meget få studerende med kendskab til elementær computerteknik, men de findes, og de bliver skræmt væk fra offentlige institutioner fordi chefniveauet er så lavt.

  • 0
  • 0
#53 Anonym

Enig. Min fremstilling antager at forbrugerne ikke er en del af vidensværdikæden.

Og det er er hovedproblemet - både i den private sektor, men navnlig i den offentlige sektor som behandler borgerne som ressoucer der skal optimeres fremfor selve motoren for effektivisering (både produktivitet og kvalitet).

Koblet til IT går det helt galt fordi IT er værktøjet til at skalere flytning af magt fra efterspørgsel til udbydersiden, fra person til system, fra behov til interesse.

Det er mere komplekst fordi udbydersiden ikke længere blot er en enkelt leverandør som klassisk økonomi antager, men et helt system dybt integreret med infrastrukturen og en meget stærk koncentration og samtidig intenst slagsmål om magten i gatekeeperfunktionerne.

"dataloger" som tror at deres primære problem er at lave pålidelige systemer overser de langt større problemer omkring det at lave systemer som er åbne for valg runtime, dvs. som kan opgraderes kontinuert via individuelle kunders FORSKELLIGE valg mellem FORSKELLIGE løsninger i alle led.

"Pålidelige" tekniske systemer som blokerer for innovation/konkurrence og dikterer magten er utroværdige og reelt stærkt upålidelige. Des flere forskellige processer, de skal understøtte, desto værre. Skaden med NemId, DokumentBoks og f.eks. Facebook er mange størrelsesordener større end problemerne med Borger.dk og EPJ som igen er størrelsesordener værre end Tinglysning (som forhåbentligt kun var overgangsproblemer).

  • 0
  • 0
#54 Anonym

"dataloger" som tror at deres primære problem er at lave pålidelige systemer overser de langt større problemer omkring det at lave systemer som er åbne for valg runtime, dvs. som kan opgraderes kontinuert via individuelle kunders FORSKELLIGE valg mellem FORSKELLIGE løsninger i alle led.

Rettelse - det er både/og for jeg er helt enig i PHKs grundliggende pointe. Vi skal både have mere pålidelige it-systemer og systemer som fungerer mere pålideligt.

Personligt ser jeg blot at den relative fordeling af indsaten allerede er 1000:1 i favør af det som PHK taler om, mens det bredere arkitekturdesign forudsigeligt og programmeret fejler næsten totalt.

  • 0
  • 0
#55 Slet Mig nu

Dataloger har vel opgaven: at bidrage med viden og deres erfaring inden for deres område, for derved at de givne forretningsmæssige krav bliver implementeret på bedst og billigst mulige måde. På fuldstændige samme vilkår som projektlederen, tekstskriveren, testeren, sikkerhedsspecialisten, ... Vi kan være fuldstændige enige om, at hvis man bygger extensibility, flexability, ... ind i sine protokoller, standarder, ... så har man nok bygget bedre for fremtiden, men i sidste ende handler det om forretningsmæssige krav.

Hvis man ønsker, at dataloger skal være den rebelske person som nedlægger arbejdet, fører kampagner, udstiller kollegaer i medier for derved at ændre et projekt som vi alle ved vil fejle eller i bedste fald levere noget skidt - vel, så skal vi vel til at importere kulturen fra de tidligere øst-lande. Alternativt, begynder man at indse, at hvis man vil have projektet til at levere et godt resultat, så skal man have den nødvendige kompetence på alle pladser, ikke blot den lille gruppe af dataloger. Det hjælper ikke det store.

Den oprindelige samligning med brobygning og at civilingeniører spiller stopklodsen i de sammenhænge - tja, er det også dem som har forvane at vælge lidt tunnel, lidt hængebro og andet godt som et kompromis? eller kommer de først ind når Folketinget har talt?

  • 0
  • 0
#56 Torben Mogensen Blogger

Jeg er på 5 semester som datamatiker. Her på uddannelsen har vi om system design, system udvikling, IT i organisationer og system udviklingsmetoder (1). Vi bliver uddannet til at lave store systemer i projektgrupper som kan smides på arbejdsmarkedet. Lærer man ikke dette på datalogistudiet? Altså udviklingsmetoder og system design?

Jo da:

http://sis.ku.dk/kurser/viskursus.aspx?knr=111455 (obligatorisk)

http://sis.ku.dk/kurser/viskursus.aspx?knr=114147 (valgfrit, men obligatorisk på applikationsudviklingslinjen).

Dertil kommer en række valgfri kurser på kandidatuddannelsen.

  • 0
  • 0
#57 Henrik Secher Jarlskov

Jeg vil lige starte med at sige, som datalog, at jeg godt forstår spørgsmålet omkring dataloger virkelig er klædt på til "virkeligheden" når de kommer ud fra studiet - som det er tilfældet med så mange andre uddannelser... Der er sikkert heller ikke mange her der reelt bryder sig om at finde ud af at man skal behandles af en lægestuderende på hans første forsøg på en rigtig patient eller en helt nyuddannet kørelærer.

At der er kommet meget fokus på "fejlslagne" IT-systemer synes jeg er godt, da det er et område vi skal blive bedre til - men debatten er også drejet lidt over i at det kun er på IT-område at dette problem eksisterer og at i bygge- og anlægsbranchen finder man ikke den slags ting... Skal jeg lige minde om Metro-projektet i København - både i forhold til deadlines og i forhold til budget? ..

Det sker skam også i andre brancher - men lad mig vende tilbage til IT-systemerne.

Ift. problemerne med offentlige IT-projekter er min holdning at det er kompleksiteten i forretningsprocesserne og slutbrugergrupperne, der gør det til en hyppig kampplads for fiaskoer. Der er ingen tvivl om at udvikling af programmer kan gøres godt eller skidt, men grundlæggende set er det ikke raketvidenskab. Det er sjældent man løber ind i store algoritmiske udfordringer hvor det kræver mange dages gennemtænkning og design ved tavlet for at få en fungerende løsning designet. Derimod er det ingen let sag at ramme de ofte store og spredte brugergrupper, der er tale om. Tag f.eks. et EPJ-system, som skal kunne forståes og bruges af læger, sygeplejesker, ergoterapeuter, fysioterapeuter, sekretærer, receptionister og mange andre og samtidig erstatte en del af deres daglige forretningsproces for at systemet giver den effektivisering det forudsættes.

Når man går igang med en implementeringsproces i et stort og omfattende system (som de fleste offentlige systemer er) nedsætter man grupper af projektledere og udvalgte fra brugergruppen, der skal afklare behov og forretningsprocesser, som så bliver grundlaget for en kravspecifikation ... og allerede her går det normalt galt! Man kan under ingen omstændigheder tage alle der bliver berørt af IT systemet med i processen og dem, der bliver udvalgt er ofte dygtige, men kan på ingen måde forudse eller gennemskue alle deres kollegaers arbejdsområder.

Når man f.eks. implementer et stort ERP-system, som SAP eller Oracle, løber man ikke ind i problemer med de overordnede forretningsprocesser, men mere de små skjulte og ikke beskrevede forretningsprocesser, som den daglige forretning alligevel er afhængig af - men ingen lige tænker over.

Den slags giver forsinkelser og tager tid fra den fase, som oftest kommer til sidst i implementeringen af et stort IT-projekt pga. vores alle sammen elskede vandfaldsmodel, nemlig test-fasen. Det bliver så der man kapper en tå og ender med at skære en fod eller to væk... Resultatet er naturligvis at forretningen ikke når at bekræfte at IT systemet ikke er godt nok til at dække deres daglige forretningsprocesser i en tilpas grad eller er decideret ustabilt i yderområderne. Specielt når IT-systemet oftest er implementeret af folk, som er dygtige til teknik og programmering, men ikke har forretningsforståelsen og dermed et godt sammenhængende billede af de kritiske processer.

Jeg oplever sjældent at det er tekniske problemer, som f.eks. implementering af en protokol eller manglende bufferhåndtering, der giver de største upfordringer - men derimod manglende forretningsforståelse og brugerinvolvering.

Hvis man skulle have alle interessenter med i det så omtalte Storebæltbro-projekt ville projektet jo aldrig være færdigt. 200.000 billister skulle komme med deres input og deltage i efterfølgende test... Derimod har man baseret sig på at der indenfor trafik er en fælles basis man kan bygge videre på - nemlig at folk kan køre bil og læse skilte. Det betyder at brugerne af Storebæltbroen allerede første gang de "benytter systemet" kan klare sig uden en 1200-siders manuel og et fem-dages kursus.

Dette udgangspunkt har man sjældent med et IT-system, da forudsætninger omkring forståelse af IT og brug af IT er meget forskellige i brugergrupperne, der bliver berørt af systemet.

Måske skulle man i stedet for at give datalogerne "udslusning" i virkeligheden fokusere dem lidt i at lære at forstå og kommunikere mere med forretningsrettede brugere og derved gøre gap'et i misforståelser mindre, så man derved får testet forretningsdelen af de komplekse IT-systemer allerede i unit testen?

  • 0
  • 0
#58 Ditlev Petersen

Engang omkring 1990 var der en datalog, der (dybt undrende over fakta) fortalte mig, at en computer var deterministisk. Hun forstod ikke, at samme program gav forskellige resultater på "samme" data. Jeg går stadig rundt og griner.

Verden er ikke abstrakt men konkret.

Jeg er i øvrigt edb-assistent (og datanom), ikke ingeniør.

  • 0
  • 0
#59 Jesper S. Møller

Engang omkring 1990 var der en datalog, der [...] fortalte mig, at en computer var deterministisk.

Og det er de forhåbentlig stadig. Det er måske lidt abstrakt at forstå, men hvis du ser begreber som "omverden", herunder "tiden" som input til dit program, ja, så er computere deterministiske. Ellers skal de repareres.

  • 0
  • 0
#60 Torben Mogensen Blogger

hvis du ser begreber som "omverden", herunder "tiden" som input til dit program, ja, så er computere deterministiske. Ellers skal de repareres.

Der er nogle computere, der har indbygget bevidst ikke-deterministiske komponenter til generering af tilfældig data. Det er dog typisk lavet udenfor CPU'en som en ydre enhed, så man kan i en vis forstand kalde det input.

Asynkrone computere kan også internt opføre sig ikke-deterministisk, men man bestræber sig for, at den udefra observerbare opførsel er deterministisk.

  • 0
  • 0
#61 Jesper S. Møller

Det kan godt være at computeren teoretisk er deterministisk, [...]

Hele diskussionen om deterministiske computere er vist off-topic, og jeg beklager at jeg kom til at nære den i mit svar til indlægget kl. 10:05.

Hvis man ikke designer teknologi og systemer så det kan tilpasse sig forskelligartethed og kontinuert fonyelse, så tvangstilpasser man samfund og mennesker til teknologien.

Meget enig, og enig i en stor del af resten.

  • 0
  • 0
#62 Anonym

Det kan godt være at computeren teoretisk er deterministisk, men det er hverken interessenterne, processerne, organisationerne eller systemet selv (i det omfang det kan hackes).

En deterministisk verden er det sidste vi ønsker - det kaldes planøkonomi og det har vi allerede alt for meget af FORDI systemerne er alt for ufleksible.

Det går galt når man ikke forstår at teknologi kun indgår som en del af mere komplekse samfundsprocesser som kontinuert ændrer sig, fornyes og løber i mange forskellige retninger på samme tid - fordi behov er forskellige og ændrer sig.

Hvis man ikke designer teknologi og systemer så det kan tilpasse sig forskelligartethed og kontinuert fonyelse, så tvangstilpasser man samfund og mennesker til teknologien.

Det kunne gå når vi taler en gaffel, et computerspil eller til nød en bro/vej, men ikke når vi taler basal infrastruktur som indgår som strukrureende (og dermed også blokerende/dikterende) byggeklods i mange processer.

Identitet er f.eks. det mest kritiske af al kritisk infrastruktur fordi det er universelt. Intet påvirkes ikke eller styres i sidste ende af den identitetsmodel som et system arbejder efter. Når man så tvangsdikterer worst case modeller, så skader man samfundet.

Når teknisk fokuserede diskuterer f.eks. NemId så bliver det oftest reduceret til noget ret ligegyldigt såsom HVILKEN teknologi i stedet for principper, hvilken forandringsmodel, magtstruktur, processeunderstøttelse etc. etc.

Pointen er ikke at trække diskussionen over i noget speielt, men at man skal erkende at it-design også er samfundsdesign - unaset om man er opmærksom på det eller ej.

Det er en årsag til at Dansk konkurrence- og innovationsevne falder som en sten. Vi har så tralvt med at antage at de gamle forældede 60er filosofier er så gode uden at stille spørgsmålstegn ved de basale antagelser. Virkeligheden kræver flere nuancer som ikke kan håndteres ved at eliminere frihedsgrader for at et it-system skal være "pålideligt". Det var det gamle TDC-monopol også - men den form for pålidelighed kan vi ikke bruge til noget.

  • 0
  • 0
#63 Anonym

Her har vi et af de mange triste eksempler.

http://www.version2.dk/artikel/15267-dokumentboks-skal-spare-kommunerne-...

Rambøll kan regne ud at afsender sparer lidt, men hvem fortæller Rambøll at dette koster langt mere i tabt innovationsevne og mindre konkurrence i samfundet? Det er ren planøkonomi.

Der er INGEN grund whatsoever til at man skulle monopolisere dette område - slet ikke med en model uden sikkerhed eller fleksibilitet.

  • 0
  • 0
#64 Poul-Henning Kamp Blogger

Det sjove ved ligenøjagtigt det eksempel er at besparelsen overvældende handler om porto til Post Danmark, som Rambøl, så vidt jeg husker, har rådgivet staten Danmark om privatiseringen af.

Så ikke alene sparer kommunerne penge, det betyder også dårligere post-besørgelse osv. osv.

Poul-Henning

  • 0
  • 0
#65 Anonym

Det var blot et eksempel - ikke for at sidetracke diskussionen.

At man får dårligere postservice fordi nogen gennemfører en besparalse ved at digitalisere bør ikke føre til at man kunstigt subsidierer Posten - det bør tværtimod synliggøres så man kan forholde sig til hvad det reelle behov for fysisk post.

Problemet er at man forsøger at tvinge borgernes ind i one-size-fits-all og single-points-of-failure modeller fordi man fejldesigner it-systemerne.

  • 0
  • 0
#66 Lasse Reinholt

Jeg hører ikke PHK sige at uddannelserne er værdiløse, tværtimod er den fundamentale fysiske forståelse (punktformige lodder) et udmærket begyndelsespunkt

Jamen hvor er det punktformige lod, når vi i Databaser benchmarker en query før og efter indeksering?

Hvor er vakuumet, når vi i Netværk måler båndbredde over atlanten med for lille TCP receive vindue i forhold latenstid?

Hvor er den vægtløse snor, når vi i Klyngearkitekturer benchmarker iteration over rækker i matricer fremfor søjler på grund af cache?

Hvor er den friktionsløse trisse, når en opgave i Multiprogrammering med vilje lader os dø i trådoverhead og spinlocks?

Hvor er Viking-II, når de aller ældste lærebøger for årgang 2009 er fra 2007?

Jeg forstår ikke kritikken.

  • 0
  • 0
#67 Kim Garsdal Nielsen

Hvis et enigt folketing var kommet, halvvejs igennem bygningen af Storebæltsbroen, og havde bedt om at få tilføjet et jernbanespor mere, er der ingen der ville have sagt "Det kan vi nok godt fuske sammen" eller lovet at det nok kun ville forsinke projektet en lille smule, eller at man kunne betale det over vedligeholdelseskontrakten.

Måske ikke lige en jernbane...

http://ing.dk/artikel/11354-rekordbro-overrasket-af-cykelsti

/Kim

  • 0
  • 0
#68 Anonym

Nu harceleres der over at dataloger ikke er i stand til at undgå de efterhånden velkendte IT skandaler, men jeg tror det er nødvendigt lige at se på hvordan datalogers og ingeniørers faglige ekspertise udnyttes, når der er tale om IT projekter.

Det er korrekt at vi stoler på ingeniørers arbejde, når det kommer til broer, jernbaner og andet i den dur. Det er netop fordi at deres konstruktion ses som en opgave for en ingeniør, der derefter benytter sin viden og erfaring indenfor området til at konstruere pågældende ting. I sin værktøjskasse har en ingeniør en mænge formalismer, der hjælper ham til at overskue problemet og til at finde en løsning, der opfylder kravene. Der er stor tiltro til løsningen allerede inden den føres ud i livet, da ingeniøren har lavet en model af løsningen og eftervist løsningens korrekthed.

Tingene ser lidt anderledes ud indenfor IT. Det er ikke fordi IT systemer er mere komplekse en broer (det er kun folk, der aldrig har bygget broer, som siger det), men holdningen til IT systemer er helt anderledes. Problemet er at enhver, der har "rodet lidt med computere" bliver anset for at være professionelle "IT folk" og deres ord bliver taget for gode varer. Konstruktionen af softwaresystemer regnes nærmest for at være magi så uddannelse ikke hjælper. Her hjælper kun "kodere", der kan deres kram.

Derudover er der jo hele det politiske aspekt. Når politikere beslutter at der skal bygges en Storebæltsbro, kan de ikke overskue detaljerne og overlader resten til professionelle. Når det gælder IT systemer kan enhver give sin mening med, for det kan jo ikke være så svært lige at lave sådan et system.

Vi ser det også her på Version2, hvor der tales om "IT folk", programmører, kodere. Ingeniører nævnes ikke på trods af, at Version2 er en afstikker af Ing.

IDA har en statikerordning hvor nogle statikeres faglige kompetence kan anerkendes, således at deres udsagn kan antages at være ekspertudsagn. Hvorfor har IDA ikke en SW-ingeniør-ordning, hvor noget lignende gør sig gældende? Svaret er jo at selv i IDA taler man om "IT folk", programmører, kodere mv og anerkender ikke at området er et ingeniør-relevant område på højde med byggeriet. Det er nok den største grund til, at jeg ikke er medlem af IDA.

Det er anderledes i England, hvor man kan anerkendes af en ordning der ligner statikerordningen. De anerkendte SW professionelle kan afgive ekspertudsagn i retten og deres udsagn er desuden generelt ansvarspådragende.

En ingeniørs klassiske arbejdsområde er kontrollen med det område, der ligge mellem forskellige domæneeksperter og brugerne. Ingeniøren sikrer vha. sin formalisme, at tingene hænger sammen og står inde for det færdige resultat. I IT verdenen betyder det, at SW-ingeniøren skal kunne tale med dataloger, matematikere, fysikere, programmører mv. og brugerne og så sikre at det hele hænger sammen. Desværre bliver SW-ingeniører ikke anvendt til dette. De pålægges at skulle være "kodere" og så sættes der en djøffer ind på ingeniørens plads. Dette medfører at både valg og fravalg ikke bliver foretaget på det nødvendige tekniske grundlag.

Så jo, den efterlyste uddannelse findes i Danmark, men hele IT-området bliver simpelthen ikke taget alvorligt.

  • 0
  • 0
#69 Ditlev Petersen

"Og det er de forhåbentlig stadig. Det er måske lidt abstrakt at forstå, men hvis du ser begreber som "omverden", herunder "tiden" som input til dit program, ja, så er computere deterministiske. Ellers skal de repareres."

Nu skrev jeg "samme" data (i gåseøjne). Problemet er, at situationen for en computer + program sjældent er helt den samme, hvorfor udfaldende ind i mellem er ganske forskellige. Når man har flere brugere, multitasking, interrupts fra uret og netværket, musepositioner og lidt forskellige data på disken, så skajer systemerne sommetider ud. Tilsyneladende forekommer "bit rot" faktisk i virkeligheden.

Jeg har et program, der engang imellem bliver sløvt (et indtastet tegn per syv sekunder) selv om maskinen ikke sveder, Paint Shop Pro viste kun sort i sort forleden, ikonerne i proceslinien kommer og går efter guderne må vide hvilke principper, Word skifter "mode", copy kopierer noget helt andet end det selekterede osv. osv.

Man har ikke kun brug for en pragmatisk it-mand. Vi har brug for en horde af excorsister.

  • 0
  • 0
#70 Jesper Udby

Egentligt interessant at en mand uden formel IT-uddannelse gør sig klog på IT-uddannelser der tilsyneladende mangler.

Som en (anden) gammel rotte i branchen er jeg efterhånden nået til den erkendelse at der er én "ting" er kan afgøre et projekts success:

projektlederen

Jeg har aldrig været på et decideret "fiasko projekt", men alle de bedste og sjoveste (!) projekter har også været bemandet med eminente projektledere, der forstår at sætte kundens krav i perspektiv ("fint at du nu vil have feature X, men prioritér den lige og vi finder ud af hvad det koster").

Som professionel oplever jeg at "alle kan deltage", men de mest interessante arkitektur- og designmæssige diskussioner får man generelt med folk med højere uddannelse. Desuden oplever jeg at folk med laveste uddannelsesniveau generelt konstruerer mere "spaghettikode" som de helst ikke ser man refaktorerer i - "hvorfor skrev du dét om, det virkede jo".

Jeg synes PHK skulle rette skytset mod dem som udformer håbløse krav, de leverandører der gerne tager håbløse opgaver og de amatører der gerne implementerer dem.

  • 0
  • 0
#71 Anonym

Jesper

Hvilken uddannelse er der til dem som udformer de "håbløse krav"?

Selvom jeg tror alle er enige i det du siger, så nytter det ikke at vaske hænder på denne måde. Der er it-folk på begge sider af bordet.

Eksemplerne med NemId, DokumentBoks og Borger.dk dokumenterer at uanset at man har "folk med højere uddannelser" involveret, så går det helt galt alligevel.

  • 0
  • 0
#72 Poul-Henning Kamp Blogger

Egentligt interessant at en mand uden formel IT-uddannelse gør sig klog på IT-uddannelser der tilsyneladende mangler. [...] Jeg synes PHK skulle rette skytset mod dem som udformer håbløse krav, de leverandører der gerne tager håbløse opgaver og de amatører der gerne implementerer dem.

Ad 1: Ja, det er interessant, burde det ikke netop være fagfolkenes bekymring, hvad enten de er ingeniører eller dataloger ?

Ad 2: Det er sådan set det jeg gør. Du overser forresten at mange af de omtalte er folk hvis uddannelse giver det indtryk at de burde vide bedre, i visse tilfælde væsentligt bedre.

Poul-Henning

  • 0
  • 0
#74 Jeppe Boelsmand

Jeg har selv min Cand. Polyt. som software ingeniør fra AAU. Jeg kan sagtens se hvordan noget af kritikken kan berettiges; en del af undervisningen foregår sammen med dataloger og informatikere.

Compilere, algoritmer og dataarkitekturer, Syntax og Semantik og Kompleksitet og beregnelihed for at nævne nogle.

Jeg ser dog disse discipliner som ret centrale for forståelsen for god IT og mange kurser som er specifikke for ingeniørerne handler om skalerbarhed, udviklingsmetodik og planlægning, team management, systemadministration(Der går en prås op for en når man opdager at der faktisk er nogen der skal sidde og vedligeholde det man laver), men det der adskiller os allermest fra Datalogerne er projekterne.

Hvor datalogernes projekter drejer sig om at udfordre eller udvide teorien er de fleste SW semestre præget af at bygge et artefakt og inkorporere de kurser man har i løbet af halvåret.

Når jeg kigger to år tilbage på tiden umiddelbart efter mit speciale føler jeg nu at jeg var rimeligt udrustet til at begå mig på arbejdsmarkedet. Personligt syntes jeg at den store forskel på hvor dygtig man er er hvordan man anvender den erfaring man har opbygget.

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