mboost-dp1
SXC - Gokoroko
bliver de så også kun undervist i et sprog ...
Inden for programering er det jo meget vigtigt at man har arbejdet med en masse forskelligt. Hvis du sider på et C# projekt og der kommer en ny opgave, så er det da vigtigt at have styr på om det er smart at løse den i C# eller om denne delopgave skal laves i noget andet.
Men okay. De kan så have en IT-Ingeniør til det
Inden for programering er det jo meget vigtigt at man har arbejdet med en masse forskelligt. Hvis du sider på et C# projekt og der kommer en ny opgave, så er det da vigtigt at have styr på om det er smart at løse den i C# eller om denne delopgave skal laves i noget andet.
Men okay. De kan så have en IT-Ingeniør til det
#1
Jeg er enig i, at man burde have nok erfaring til at vide når noget skal udvikles i fx .NET eller om noget burde laves i Java, eller C / C++.
Men at have arbejdet 'med en masse forskelligt' mener jeg kun er relevant hvis det er en almindelig 'all-round' udvikler.
De fleste software-projekter er nu til dags så store, at det er specialister der er behov for. Én der kan presse hver eneste dråbe ud af hvert framework, så det spiller.
Det afhænger af hvad man vil, hvor meget tid man vil lægge i det, samt om man tør satse på at blive specialist.
Jeg satser selv på JEE udvikling, og jeg stryger let og elegant udenom .NET, selvom jeg ved hvad frameworket er i stand til.
Men skal man satse på dem begge to, kommer man nok næppe i dybden med nogen af dem.
Jeg er selv datamatiker, og jeg mener ikke at en IT-Ingeniør nødvendigvis er en 'silver-bullet' fordi vedkommende har læst avanceret matematik og algoritmer på uni. Det er erfaring, meget læsning og logisk tænkning der spiller ind.
Inden for programering er det jo meget vigtigt at man har arbejdet med en masse forskelligt. Hvis du sider på et C# projekt og der kommer en ny opgave, så er det da vigtigt at have styr på om det er smart at løse den i C# eller om denne delopgave skal laves i noget andet.
Jeg er enig i, at man burde have nok erfaring til at vide når noget skal udvikles i fx .NET eller om noget burde laves i Java, eller C / C++.
Men at have arbejdet 'med en masse forskelligt' mener jeg kun er relevant hvis det er en almindelig 'all-round' udvikler.
De fleste software-projekter er nu til dags så store, at det er specialister der er behov for. Én der kan presse hver eneste dråbe ud af hvert framework, så det spiller.
Det afhænger af hvad man vil, hvor meget tid man vil lægge i det, samt om man tør satse på at blive specialist.
Jeg satser selv på JEE udvikling, og jeg stryger let og elegant udenom .NET, selvom jeg ved hvad frameworket er i stand til.
Men skal man satse på dem begge to, kommer man nok næppe i dybden med nogen af dem.
Men okay. De kan så have en IT-Ingeniør til det
Jeg er selv datamatiker, og jeg mener ikke at en IT-Ingeniør nødvendigvis er en 'silver-bullet' fordi vedkommende har læst avanceret matematik og algoritmer på uni. Det er erfaring, meget læsning og logisk tænkning der spiller ind.
Jeg er selv IT ingeniør og mener heller ikke at man nødvendigvis har brug for en IT ingeniør til at bestemme hvilket sprog der er smartest at bruge. På DTU har man ikke en speciel holdning til at ingeniører skal lære flest mulige sprog. Det er ikke rigtigt noget der har været i tankerne da man planlage studiet. Da jeg læste var vi kun tvunget til at lære Java (at det kun var det sprog var vist mere tilfældigt end et bevidst valg), og kun via valgfag og andet stiftede jeg bekendtskab med C#/.NET.
I den IT konsulentvirksomhed hvor jeg arbejder (små 200 medarbejdere) satses der ikke specielt meget på specialister. Hvis man kan programmere og kan samarbejde (både med kunde og kollegaer) så er det ikke så vigtigt hvad for et sprog man er god til, og man kan godt opleve at komme på et Java projekt selvom man er .NET specialist.
I den IT konsulentvirksomhed hvor jeg arbejder (små 200 medarbejdere) satses der ikke specielt meget på specialister. Hvis man kan programmere og kan samarbejde (både med kunde og kollegaer) så er det ikke så vigtigt hvad for et sprog man er god til, og man kan godt opleve at komme på et Java projekt selvom man er .NET specialist.
Jeg synes stadig det er ufatteligt ringt at de bliver ved med at spytte programmerings uddannelse efter programmerings uddannelse ud, uden at tænke på netværks uddannelser, server drift, osv.
Og kom ikke og sig at Datatekniker og IT Supporter dækker disse områder, for med den teknisk skole kvalitet i dagens Danmark ved vi godt de uddannelser er det værste lort indenfor IT.
Og kom ikke og sig at Datatekniker og IT Supporter dækker disse områder, for med den teknisk skole kvalitet i dagens Danmark ved vi godt de uddannelser er det værste lort indenfor IT.
Ja, det handler ikke ret meget om uddannelse, men om indstillingen til tingene og den erfaring man har samlet. Jeg trækker langt mere på den viden jeg selv har tilegnet mig udenfor uddannelsen end det jeg er blevet undervist i.
Ofte er problemerne man støder på i den virkelige verden også langt mere simple end avancerede algoritmer og det handler langt mere om hvordan man skaber den simpleste og mest stabile løsning, frem for hvor avanceret det kan laves.
Man skal hellere lære at løse problemer, tænke selv og undervise i hvordan man lære sig selv nye kompetencer, i stedet for at undervise i specifikke programmeringssprog.
Ofte er problemerne man støder på i den virkelige verden også langt mere simple end avancerede algoritmer og det handler langt mere om hvordan man skaber den simpleste og mest stabile løsning, frem for hvor avanceret det kan laves.
Man skal hellere lære at løse problemer, tænke selv og undervise i hvordan man lære sig selv nye kompetencer, i stedet for at undervise i specifikke programmeringssprog.
Ville være nice at vide om min 3,5års uddadlse som Multimedia Intagrator kan bygge videre ;) vil gerne ha været datamatiker men havde ikke skole kundskaber nok til at komme ind, nu har jeg indgangs vinklen fordi jeg har reletert uddandlse til den linje, men at tage datamatiker er lidt spild i mine øjne hvis de laver en ny web uddandlse :)
Hvad er fordelen med de her uddannelser?
Datamatiker uddannelsen tager 2½ år og overbygningen 1½ år
på den omtalte uddannelse.
For at uddanne sig til diplomingeniør i IT på DTU som datamatiker, er overbygningen 2 år.
Der er godt nok ½ år mere, men så har man en grad der
er ækvivalent med en bachelor og dermed også adgang til
at lære videre til kandidat.
Indenfor ingeniørvidenskaben er informationsteknologi det eneste
gren, hvor størstedelen af folk ikke bruger matematiske opstillinger før man går igang med den faktiske konstruktion.
Det er så netop derfor der er så meget der går galt,
og skal bruge massere af tid på debugging og aftercare.
Og lige præcist derfor der er brug for folk der som minimum kan diskret matematik, for at kunne formulere formelle specifikationer,
der ikke er tvetydige eller upræcise.
Så længe man står for management
og ikke direkte skal udvikle er det jo fint nok.
Datamatiker uddannelsen tager 2½ år og overbygningen 1½ år
på den omtalte uddannelse.
For at uddanne sig til diplomingeniør i IT på DTU som datamatiker, er overbygningen 2 år.
Der er godt nok ½ år mere, men så har man en grad der
er ækvivalent med en bachelor og dermed også adgang til
at lære videre til kandidat.
#2: squad2nd skrev:
Jeg er selv datamatiker, og jeg mener ikke at en IT-Ingeniør nødvendigvis er en 'silver-bullet' fordi vedkommende har læst avanceret matematik og algoritmer på uni.
Indenfor ingeniørvidenskaben er informationsteknologi det eneste
gren, hvor størstedelen af folk ikke bruger matematiske opstillinger før man går igang med den faktiske konstruktion.
Det er så netop derfor der er så meget der går galt,
og skal bruge massere af tid på debugging og aftercare.
Og lige præcist derfor der er brug for folk der som minimum kan diskret matematik, for at kunne formulere formelle specifikationer,
der ikke er tvetydige eller upræcise.
#2: squad2nd skrev:
Det er erfaring, meget læsning og logisk tænkning der spiller ind.
Så længe man står for management
og ikke direkte skal udvikle er det jo fint nok.
Den der med bredde/specialisering vil jeg godt være lidt fræk og skyde lidt til jorden. Forskellene mellem f.eks. Java, C# VB.NET samt flere er primært syntaks, hvis du kan kode i det ene af sprogene er din logiske/semantiske viden på plads, til at arbejde med et af de andre. Dette gælder sådan set også over til f.eks. C++, selvom man her har lidt flere forskelle ift. f.eks. .NET programmering, som at der ikke er nogen der rydder op efter én.
Så med dette i mente, vil jeg mene det er muligt at specialisere sig i et sprog og derefter relativt hurtigt komme op at køre med et andet sprog, hvis behovet skulle opstå.
Så med dette i mente, vil jeg mene det er muligt at specialisere sig i et sprog og derefter relativt hurtigt komme op at køre med et andet sprog, hvis behovet skulle opstå.
#1 Datamatikere er ikke uddannede til at tænke, det er uddannede til at skrive. Som du selv siger det, vi har Ingeniørene til at planlægge projekterne, og så er datamatikerne bare tolke der oversætter skitser af løsninger til kode.
Og ingen har nogensinde påstået at tolke skulle kunne alle sprog.
#11 "jeg mene det er muligt at specialisere sig i et sprog og derefter relativt hurtigt komme op at køre med et andet sprog"
Du mener vel forhåbenligt ikke specialicere sig, men derimod bare at "være vant til" et sprog. Når du har specialiceret dig i et sprog er du mindst på et master niveau med speciale i sprogets opbygning, hvilket indebærer et uniqt kendskab til hele strukturen og kompileren, og håndteringen af hele evalueringen af koden, ikke bare et godt kendskab til syntaxen, og når du sidder som specialist i c++, så kan det godt være at koncepeterne er de samme som i .Net, men du kan ikke "bare lige" finde samme kendskab over night.
Og det er vigtigt at pointere at datamatikere ikke er specialister, og hobyister er i særdeleshed aldrig specialister, heller ikke selvom dine venner kalder dig guru, og du er god til at kode i et givent sprog, der skal lidt mere til for at være specialist, og i de fleste tilfælde er det "lidt mere" en universitetsuddannelse, selvom dette ikke garanterer at du bliver specialist.
#2 "Det er erfaring, meget læsning og logisk tænkning der spiller ind."
Det skader ikke, men (undskyld mig udtrykket) idioter med en datamat uddannelse der selv syntes at de tænker logisk fordi de kan skrive en hurtig lille håndfuld kode der løser et problem tænker sjællent logisk. Formel logik er vigtig, det er den logik der rent faktisk betyder at når en IT-ingeniør aflevere et stykke kode som udfører opgaven X og med garanti ikke laver fejlen Y, så er det realt set det der sker, mens man med idioterne får et stykke kode der udfører opgaven X, og "sikkert ikke" opgaven Y.
kodere er for matematikken hvad kemikere er for fysiken. Det er rigtig nok at man kan lave interessante ting ved bare at hælde tilfældige væsker sammen, men hvis man glemmer fysiken når man heller aldrig videre end det.
(Undskyld biaset, men jeg kender ret mange datamatikere, der selv syntes de er guds gave til kode, men er matematisk handikappede og derfor efterlader idiotiske fejl i deres kode, som de ikke lige selv kan gennemskue.)
Og ingen har nogensinde påstået at tolke skulle kunne alle sprog.
#11 "jeg mene det er muligt at specialisere sig i et sprog og derefter relativt hurtigt komme op at køre med et andet sprog"
Du mener vel forhåbenligt ikke specialicere sig, men derimod bare at "være vant til" et sprog. Når du har specialiceret dig i et sprog er du mindst på et master niveau med speciale i sprogets opbygning, hvilket indebærer et uniqt kendskab til hele strukturen og kompileren, og håndteringen af hele evalueringen af koden, ikke bare et godt kendskab til syntaxen, og når du sidder som specialist i c++, så kan det godt være at koncepeterne er de samme som i .Net, men du kan ikke "bare lige" finde samme kendskab over night.
Og det er vigtigt at pointere at datamatikere ikke er specialister, og hobyister er i særdeleshed aldrig specialister, heller ikke selvom dine venner kalder dig guru, og du er god til at kode i et givent sprog, der skal lidt mere til for at være specialist, og i de fleste tilfælde er det "lidt mere" en universitetsuddannelse, selvom dette ikke garanterer at du bliver specialist.
#2 "Det er erfaring, meget læsning og logisk tænkning der spiller ind."
Det skader ikke, men (undskyld mig udtrykket) idioter med en datamat uddannelse der selv syntes at de tænker logisk fordi de kan skrive en hurtig lille håndfuld kode der løser et problem tænker sjællent logisk. Formel logik er vigtig, det er den logik der rent faktisk betyder at når en IT-ingeniør aflevere et stykke kode som udfører opgaven X og med garanti ikke laver fejlen Y, så er det realt set det der sker, mens man med idioterne får et stykke kode der udfører opgaven X, og "sikkert ikke" opgaven Y.
kodere er for matematikken hvad kemikere er for fysiken. Det er rigtig nok at man kan lave interessante ting ved bare at hælde tilfældige væsker sammen, men hvis man glemmer fysiken når man heller aldrig videre end det.
(Undskyld biaset, men jeg kender ret mange datamatikere, der selv syntes de er guds gave til kode, men er matematisk handikappede og derfor efterlader idiotiske fejl i deres kode, som de ikke lige selv kan gennemskue.)
#12 Nu er jeg selv datalog på Kandidat niveau, så jeg går ikke ind under hobbyist niveauet.
Jeg mente ikke at man bliver specialist i et nyt sprog "over night" ved at "komme op og køre med det", men jeg vil holde fast ved at hvis folk har specialiceret sig i et sprog, så vil de relativt hurtigt kunne "omskole" sigtil at komme igang med et andet sprog...alt læring tager selvfølgelig tid.
Din definition af specialist er jo nødvendigvis heller ikke den endegyldige sandhed, en datamatiker med en MCTS kan jo i princippet kalde sig specialist, da TS jo står for "Technology Specialist" Jeg har selv en MCTS og synes selv indholdet er ganske dækkende for at man kan kalde sig specialist.
Jeg mente ikke at man bliver specialist i et nyt sprog "over night" ved at "komme op og køre med det", men jeg vil holde fast ved at hvis folk har specialiceret sig i et sprog, så vil de relativt hurtigt kunne "omskole" sigtil at komme igang med et andet sprog...alt læring tager selvfølgelig tid.
Din definition af specialist er jo nødvendigvis heller ikke den endegyldige sandhed, en datamatiker med en MCTS kan jo i princippet kalde sig specialist, da TS jo står for "Technology Specialist" Jeg har selv en MCTS og synes selv indholdet er ganske dækkende for at man kan kalde sig specialist.
Hvilket objektorienteret sprog der undervises i er fuldstændigt ligegyldigt. Jeg vil foretrække at man ikke bruger tid og kræfter på at lære studerende en ny dialekt af OO men i stedet går i dybdten med en eller anden platform og et eller andet sprog. Så kan man bruge tiden på relevante emner som f.eks. design patterns i stedet for at lære hvordan man nu lige laver generics i java når man nu er vandt til en anden syntaks i C#.
#12
Jeg var tæt på at smadre skærmen da jeg læste dit indlæg, fordi din mening omkring datamatikere vs. IT-ingeniører er meget fejl-informeret.
Det er en lodret løgn at datamatikere er kodeslaver og det er mærkeligt at de bliver sammenlignet med IT-ingeniører igen og igen. Nu vil jeg dog gerne prøve...
Jeg har været igennem hele møllen: OOP design, design patterns, data structures, database desig foruden det, er der rigtigt god kontakt med erhvervslivet.
Mens jeg efter 2½ år har valgt IT-retning og sidder i en virksomhed og er begyndt en SERIØS praktisk, hands-on oplæring i firmaets systemer og real-life udvikling, så sidder IT-ingeniøren stadig på sit studenterværelse og læser alt hans teori, som man jo så kun kan håbe er MEGET generelt, så det ikke er forældet inden han starter i en virksomhed.
Når store virksomheder som Jyske Bank, Nykredit, Danfoss m.v. ansætter datamatikere, må det jo netop også
betyde, at de IT-ingeniører som de har ansat (eller hørt om pga. virksomheder) ikke har imponeret dem synderligt mere end datamatikerne.
Hvis man ikke kan tænke logisk, kan man vel heller ikke være istand til at løse et givent problem?
Fx fyren i denne tråd:
http://newz.dk/forum/programmering/iterator-datama...
Han ville gøre tingene på én måde, mens han lærer ville gøre det på en anden måde. I forummet ville folk gøre det på en tredje måde. Hvem skal bedømme hvilken løsning var mest logisk?
Den løsning der løste problemet selvfølgelig!
Formel logik er vigtigt... ud fra et optimerings standpunkt.
Men seriøst, når der skal laves systemer, hvad er egenligt så vigtigt? At det object-orienterede design stemmer nogenlunde ens med kundens ønsker og systemets iterationer kører efter planen.....eller formel logikken, hvor hurtige algoritmer og procedurer man kan lave?
Tidlig optimering er roden til alt ondt.
Du får IT-ingeniører til at lyde som uovervindelige robotter der aldrig laver fejl. Det er jo nok næppe datamatikere der arbejder hos Microsoft, SAP, Oracle, Sun, Logica, Cisco m.v. og deres produkter er næppe erklæret 'fejlfrie'.
Til projekter på flere milliarder, såsom DeMars, Amanda og Virk.dk m.v er det forhåbenligt også de bedste IT-ingeniører der er på de projekter, og vi ved jo allesammen godt hvordan de endte?
Det er en lige lovlig grovkornet sammenligning. Fysikken og kemien har overhovedet ikke noget med hinanden
at gøre, udover at de kan kombineres og skabe interessante resultater.
En datamatiker kan påtage sig flere roller efter endt studie, derfor er uddannelsen meget generel, og derfor er det ikke relevant for en datamatiker at bruge halvdelen af sin studietid på at læse hvordan man optimerer eksisterende algoritmer eller læse teori i dybden om et emne, da det ikke er sikkert han kommer til at arbejde med det.
Tror du ikke snarere det er en mangel på viden mht. værktøjer som fx JUnit?
Spøg til side. Man kan sagtens være en god programmør og udvikler, selvom man ikke har fået 13 i matematik. Jeg har endnu ikke set noget kode der kunne slå mig ud, medmindre det var 3D programmering i OpenGL. Spil, CAD og 3D grafik interesserer mig ikke en skid generelt, så hvorfor skulle jeg være god til alle de vanvittige ligninger og geometriske udregninger? Sålænge jeg kan styre canvas'en og 2D egenskaberne i .NET og Java til at vise grafer m.v. er jeg meget tilfreds.
Når det er sagt, hvis man efter kun 1½ års ekstra-uddannelse har en universitets-bachelor, så kan det vel ikke være helt spildt det man har lært på datamatiker-uddannelsen? ;)
Jeg var tæt på at smadre skærmen da jeg læste dit indlæg, fordi din mening omkring datamatikere vs. IT-ingeniører er meget fejl-informeret.
Det er en lodret løgn at datamatikere er kodeslaver og det er mærkeligt at de bliver sammenlignet med IT-ingeniører igen og igen. Nu vil jeg dog gerne prøve...
Jeg har været igennem hele møllen: OOP design, design patterns, data structures, database desig foruden det, er der rigtigt god kontakt med erhvervslivet.
Mens jeg efter 2½ år har valgt IT-retning og sidder i en virksomhed og er begyndt en SERIØS praktisk, hands-on oplæring i firmaets systemer og real-life udvikling, så sidder IT-ingeniøren stadig på sit studenterværelse og læser alt hans teori, som man jo så kun kan håbe er MEGET generelt, så det ikke er forældet inden han starter i en virksomhed.
Når store virksomheder som Jyske Bank, Nykredit, Danfoss m.v. ansætter datamatikere, må det jo netop også
betyde, at de IT-ingeniører som de har ansat (eller hørt om pga. virksomheder) ikke har imponeret dem synderligt mere end datamatikerne.
Det skader ikke, men (undskyld mig udtrykket) idioter med en datamat uddannelse der selv syntes at de tænker logisk fordi de kan skrive en hurtig lille håndfuld kode der løser et problem tænker sjællent logisk.
Hvis man ikke kan tænke logisk, kan man vel heller ikke være istand til at løse et givent problem?
Fx fyren i denne tråd:
http://newz.dk/forum/programmering/iterator-datama...
Han ville gøre tingene på én måde, mens han lærer ville gøre det på en anden måde. I forummet ville folk gøre det på en tredje måde. Hvem skal bedømme hvilken løsning var mest logisk?
Den løsning der løste problemet selvfølgelig!
Formel logik er vigtig, det er den logik der rent faktisk betyder at når en IT-ingeniør aflevere et stykke kode som udfører opgaven X og med garanti ikke laver fejlen Y, så er det realt set det der sker, mens man med idioterne får et stykke kode der udfører opgaven X, og "sikkert ikke" opgaven Y.
Formel logik er vigtigt... ud fra et optimerings standpunkt.
Men seriøst, når der skal laves systemer, hvad er egenligt så vigtigt? At det object-orienterede design stemmer nogenlunde ens med kundens ønsker og systemets iterationer kører efter planen.....eller formel logikken, hvor hurtige algoritmer og procedurer man kan lave?
Tidlig optimering er roden til alt ondt.
Du får IT-ingeniører til at lyde som uovervindelige robotter der aldrig laver fejl. Det er jo nok næppe datamatikere der arbejder hos Microsoft, SAP, Oracle, Sun, Logica, Cisco m.v. og deres produkter er næppe erklæret 'fejlfrie'.
Til projekter på flere milliarder, såsom DeMars, Amanda og Virk.dk m.v er det forhåbenligt også de bedste IT-ingeniører der er på de projekter, og vi ved jo allesammen godt hvordan de endte?
kodere er for matematikken hvad kemikere er for fysiken. Det er rigtig nok at man kan lave interessante ting ved bare at hælde tilfældige væsker sammen, men hvis man glemmer fysiken når man heller aldrig videre end det.
Det er en lige lovlig grovkornet sammenligning. Fysikken og kemien har overhovedet ikke noget med hinanden
at gøre, udover at de kan kombineres og skabe interessante resultater.
En datamatiker kan påtage sig flere roller efter endt studie, derfor er uddannelsen meget generel, og derfor er det ikke relevant for en datamatiker at bruge halvdelen af sin studietid på at læse hvordan man optimerer eksisterende algoritmer eller læse teori i dybden om et emne, da det ikke er sikkert han kommer til at arbejde med det.
(Undskyld biaset, men jeg kender ret mange datamatikere, der selv syntes de er guds gave til kode, men er matematisk handikappede og derfor efterlader idiotiske fejl i deres kode, som de ikke lige selv kan gennemskue.)
Tror du ikke snarere det er en mangel på viden mht. værktøjer som fx JUnit?
Spøg til side. Man kan sagtens være en god programmør og udvikler, selvom man ikke har fået 13 i matematik. Jeg har endnu ikke set noget kode der kunne slå mig ud, medmindre det var 3D programmering i OpenGL. Spil, CAD og 3D grafik interesserer mig ikke en skid generelt, så hvorfor skulle jeg være god til alle de vanvittige ligninger og geometriske udregninger? Sålænge jeg kan styre canvas'en og 2D egenskaberne i .NET og Java til at vise grafer m.v. er jeg meget tilfreds.
Når det er sagt, hvis man efter kun 1½ års ekstra-uddannelse har en universitets-bachelor, så kan det vel ikke være helt spildt det man har lært på datamatiker-uddannelsen? ;)
squad2nd (2) skrev:
Men at have arbejdet 'med en masse forskelligt' mener jeg kun er relevant hvis det er en almindelig 'all-round' udvikler.
De fleste software-projekter er nu til dags så store, at det er specialister der er behov for. Én der kan presse hver eneste dråbe ud af hvert framework, så det spiller.
Det er rigtigt at der primært er brug for specialister.
Men problemet er at den slags specialister der er brug for ændrer sig over tid.
En uddannet IT person skal være på arbejdsmarkedet i ca. 40 år. Der vil ske store ændringer i de sprog og værktøjer som bruges i den periode.
Derfor er det vigtigt at IT uddannelser fokuserer på:
- universelle principper
- even til at lære konkrete teknologier fremfor de konkrete teknologier
Øvelse gør mester også med hensyn til at lære nye sprog og teknologier. Derfor mener jeg at det er godt hvis en IT uddannelse lærer de studerende flere sprog. Fordi den process lærer dem at lære nye sprog.
Og jeg ser det ikke som det store problem at de lærer ML, Haskell, Lisp etc..
De skal nok lære Java og .NET når de kommer ud på arbejdsmarkedet.
#8 og 9
Principielt mener jeg også at behovet for flere højtuddannede IT folk burde dækkes af de højere læreanstalter.
Og det er svært ikke at få en mistanke om at disse nye uddannelser mere har til hensigt at skaffe penge til erhversskolerne end at lave de optimale uddannelser.
Principielt mener jeg også at behovet for flere højtuddannede IT folk burde dækkes af de højere læreanstalter.
Og det er svært ikke at få en mistanke om at disse nye uddannelser mere har til hensigt at skaffe penge til erhversskolerne end at lave de optimale uddannelser.
Stryder (10) skrev:
Indenfor ingeniørvidenskaben er informationsteknologi det eneste
gren, hvor størstedelen af folk ikke bruger matematiske opstillinger før man går igang med den faktiske konstruktion.
Det er så netop derfor der er så meget der går galt,
og skal bruge massere af tid på debugging og aftercare.
Og lige præcist derfor der er brug for folk der som minimum kan diskret matematik, for at kunne formulere formelle specifikationer,
der ikke er tvetydige eller upræcise.
Stryder (10) skrev:
Så længe man står for management
og ikke direkte skal udvikle er det jo fint nok.
Jeg tror ikke at der er mange steder hvor de kan bruge en udvikler der mener at formelle specifikationer er brugbare til typiske business apps.
Så er jordforbindelsen smuttet.
Den slags er for andre typer af apps.
Leonhard (12) skrev:Datamatikere er ikke uddannede til at tænke, det er uddannede til at skrive. Som du selv siger det, vi har Ingeniørene til at planlægge projekterne, og så er datamatikerne bare tolke der oversætter skitser af løsninger til kode.
Den teori har så intet med virkeligheden at gøre ude i virksomhederne.
Må jeg anbefale en naturvidenskabelig tilgang til tingene + man opstiller en hypotese og så tester man om den passer me dvirkeligheden?
Leonhard (12) skrev:Du mener vel forhåbenligt ikke specialicere sig, men derimod bare at "være vant til" et sprog. Når du har specialiceret dig i et sprog er du mindst på et master niveau med speciale i sprogets opbygning, hvilket indebærer et uniqt kendskab til hele strukturen og kompileren, og håndteringen af hele evalueringen af koden, ikke bare et godt kendskab til syntaxen, og når du sidder som specialist i c++, så kan det godt være at koncepeterne er de samme som i .Net, men du kan ikke "bare lige" finde samme kendskab over night.
At være specialist i et sprog har intet at gøre med at forstå hvordan compileren processer koden. Det er et emne for en specialist i compilere.
Og jeg kan ikke se relevansen af en kandidat grad for at være specialist i et sprog. Der er forhåbentligt ingen højere læreanstalter der udsteder kandidatgrader i et enkelt sprog. Det ville da være en skandale.
Leonhard (12) skrev:Og det er vigtigt at pointere at datamatikere ikke er specialister, og hobyister er i særdeleshed aldrig specialister, heller ikke selvom dine venner kalder dig guru, og du er god til at kode i et givent sprog, der skal lidt mere til for at være specialist, og i de fleste tilfælde er det "lidt mere" en universitetsuddannelse, selvom dette ikke garanterer at du bliver specialist.
Vi er nogenlunde enige om at hobby web udviklere som oftest har nogle forståelsesmæssige huller i stillehavs størrelse.
Leonhard (12) skrev:
Det skader ikke, men (undskyld mig udtrykket) idioter med en datamat uddannelse der selv syntes at de tænker logisk fordi de kan skrive en hurtig lille håndfuld kode der løser et problem tænker sjællent logisk. Formel logik er vigtig, det er den logik der rent faktisk betyder at når en IT-ingeniør aflevere et stykke kode som udfører opgaven X og med garanti ikke laver fejlen Y, så er det realt set det der sker, mens man med idioterne får et stykke kode der udfører opgaven X, og "sikkert ikke" opgaven Y.
Brug af IT ingeniører eller dataloger synes ikke at være nogen garanti for software der virker.
Igen er det det med at teste sine hypoteser.
Leonhard (12) skrev:
kodere er for matematikken hvad kemikere er for fysiken. Det er rigtig nok at man kan lave interessante ting ved bare at hælde tilfældige væsker sammen, men hvis man glemmer fysiken når man heller aldrig videre end det.
Jeg tvivler på at en kemiker er enig i din vurdering af hvad kemi går ud på.
Leonhard (12) skrev:
(Undskyld biaset, men jeg kender ret mange datamatikere, der selv syntes de er guds gave til kode, men er matematisk handikappede og derfor efterlader idiotiske fejl i deres kode, som de ikke lige selv kan gennemskue.)
Datamatiker studiet leverer nogle glimrende programmører og nogle elendige programmører.
Mit indtryk er at studiet for nemt. Dem der kan og vil noget lærer noget. Men dem som ikke kan og vil noget alligevel kan slippe igennem.
squad2nd (17) skrev:
Jeg var tæt på at smadre skærmen da jeg læste dit indlæg, fordi din mening omkring datamatikere vs. IT-ingeniører er meget fejl-informeret.
Det kan jeg sgodt forstå.
I parentes bemærket er der almindelig enighed om at sociale egenskaber er ret vigtige for software udviklere.
Evnerne til at arbejde sammen med andre faggrupper med andre uddannelser etc..
:-)
squad2nd (17) skrev:
Når store virksomheder som Jyske Bank, Nykredit, Danfoss m.v. ansætter datamatikere, må det jo netop også
betyde, at de IT-ingeniører som de har ansat (eller hørt om pga. virksomheder) ikke har imponeret dem synderligt mere end datamatikerne.
Eller så kan de ikke få nok IT-ingeniører og dataloger nok.
Den hypotese understøttes lidt af at når der er høj arbejdsløshed i IT branchen så rammes datamatikere hårdere end IT-ingeniører og dataloger.
Lidt spinkelt statistisk grundlag, men det holder nu nok vand.
IT uddannelser udenfor de højere læreanstalter er ikke specielt udbredt i andre lande.
Hvis jeg blev udnævnt til enevældig diktator i den danske uddannelses sektor, så ville jeg nedlægge datamatiker og lade de studerende tage en bachelor på en højere læreanstalt.
De gode datamatikere ville stadig blive gode. Måske endda en anelse bedre, fordi der ville være bedre support for dybere indsigt.
De dårlige datamatikere ville nok falde fra i endnu større omfang end de gør idag. Men det ser jeg ikke som et problem. Hvis ikke de har evner og interesse for IT, så er det også deres egen interesse at de kommer over på en anden uddannelse.
squad2nd (17) skrev:Fx fyren i denne tråd:
http://newz.dk/forum/programmering/iterator-datama...
Han ville gøre tingene på én måde, mens han lærer ville gøre det på en anden måde. I forummet ville folk gøre det på en tredje måde. Hvem skal bedømme hvilken løsning var mest logisk?
Den løsning der løste problemet selvfølgelig!
Jeg tror ikke at windcape er den typiske datamatiker studerende.
:-)
Jeg vil iøvrigt mene at der skal noget mere end at løse problemet til for at være en god løsning. Det er en nødvendig men ikke en tilstrækkelig betingelse.
squad2nd (17) skrev:Spøg til side. Man kan sagtens være en god programmør og udvikler, selvom man ikke har fået 13 i matematik.
Hm. Min erfaring er nu at en solid matematisk fundering er en god ting. Bl.a. hvis man skal ind på algoritmer.
3 uddannelser? Jeg kan kun finde 2:
http://www.ug.dk/Uddannelse.aspx?article_id=udb-pr...
og
http://www.ug.dk/Uddannelse.aspx?article_id=udb-pr... ...
Nogen der kan se den tredje, kan nemlig heller ikke se det på version2.dk
http://www.ug.dk/Uddannelse.aspx?article_id=udb-pr...
og
http://www.ug.dk/Uddannelse.aspx?article_id=udb-pr... ...
Nogen der kan se den tredje, kan nemlig heller ikke se det på version2.dk
#21: arne_v skrev:Jeg tror ikke at der er mange steder hvor de kan bruge en udvikler der mener at formelle specifikationer er brugbare til typiske business apps.
Ja, du har helt ret.
Det var både en kritik af hvad de fleste softwarevirksomheder kræver af udviklerne og hvad #2 mente hvad der gjorde til en god udvikler.
Kan du give nogle konkrete eksempler med hvad du definerer som typiske business apps?
Mener du generel software som ikke er missionskritiske?
Hele problemet ligger i at de fleste firmaer og udviklere svarer: "Formel... hvad er det for noget?",
altså at udviklingsteknikkerne i IT verdenen er for uformel til noget der er så formelt.
Hvis det er énmandsprojekt, så "kan" det fint nok med
"erfaring, meget læsning og logisk tænkning".
Det er da vigtigt at kunne omsætte sin logiske tænkning
til formel logik på et dokument, så man selv kan huske det og
andre også kan forstå det (uden at misforstå det), hvis man har tænkt sig at arbejde i et firma, hvor flere udviklere skal kunne samarbejde.
#21: arne_v skrev:
Så er jordforbindelsen smuttet.
Det er netop jordforbindelsen der aldrig har eksisteret for
de fleste i softwarebranchen :oD
Som et eksempel kan man ikke bare gå igang med at bygge et højhus, lige efter man har beskrevet med ord og diagrammer hvordan det skal laves.
Jeg vil mene det var det samme for software udviklingen
hvis man ser det fra en ingeniørs synsvinkel.
Matematiske modeller er essentielt for softwarekonstruktion, som det er for bygningskonstruktion.
#21: arne_v skrev:
Den slags er for andre typer af apps.
Det behøver det jo ikke at være. Når det kommer til stykket,
vil fejlfri produkt jo ikke skade, tvært imod.
Det må være ubeskriveligt befriende ikke skulle tænke på
at debugge og udgive patch konstant :oP
Er der mange i byggebrachen der praler med at deres konstruktioner ikke braser sammen af og til?
Det er jo underforstået.
Konstuktioner der braser sammen er jo heldigvis en undtagelse
og ikke en regel, hvor det er det omvende i softwarebranchen
(til alles store frustration).
Et projekt der har været fejlfri fra dens udgivelse,
som jeg kan nævne er Felica chippen (udviklet af
Sony's datterselskab Felica Networks) som bruges til
e-pengepungssystem i Japan.
Det bliver blandt andet brugt til betaling af metro, tog og bus systemer i Tokyo.
Udviklingen forgik med et formelt specifikations sprog VDM++.
Det ville også skabe millioner af sure japanere hvis der gik
noget galt i deres e-pengepunge :oD
#22: arne_v skrev:Brug af IT ingeniører eller dataloger synes ikke at være nogen garanti for software der virker.
Det har formel specifikation at været vist sig at være en kæmpe
fordel. (Det er en selvfølge i andre ingeniørgrene).
Men ja, som du siger, så er det ikke noget de fleste softwarefirmaer efterlyser,
eller for den sag skyld overhovedet har kendskab til.
Sådan kører den onde cirkel rundt og rundt,
med endeløs og ihærdig kampe med at fare rundt og nakke
virtuelle kryb.
Nå tilbage til hovedartiklen,
firmaerne har brug for folk der kan overbevise ledelsen om
at deres udviklingsmetode er grunden til det meste af de fejl der opstår i deres produkter, og kunne indføre formelle metoder.
Hvis datamatilere alligevel skal til at gå i gang med softwareudvikling eller webudvikling, hvorfår så ikke tage den halve år ekstra, lære diskret matematik, tage nogle valgfrie kurser i formelle metoder og være parat eller bare at have muligheden i at kunne omvælte den nuværende mode med uformelle udviklingsmetoder, hvilket som regel producerer myriader af kryb som man bliver nødt til at splatte én efter én?
Jeg siger slet ikke som #12 at datamatikere burde holde sig væk fra software branchen, men at de burde lære og forstå at formalisme er vigtigt for at kunne konstruere software (netop fordi er det er et formelt system) og at det ville være godt for dem at læse videre på universitets niveau.
Der er da et par af mine kammerater min årgang i diplomingeniør studiet der læste videre fra datamatikerstudiet.
De er da blevet fine ingeniører ;o)
Og så omtopic, jeg studerer datamatiker på Århus Akademi (Viby J), på 3. semester.
Jeg synes absolut at de er for teknologi specifikke i en lang række af fagene. Personligt har jeg overvuderet at tage en Datalog Bachalor bagefter, hvis jobmarkedet viser at det er en god ide.
Problemet er at man kan lære så og så meget teori. Men hvis man står til at blive omskolet til at slet ikke arbejde med samme sprog og teknikker (OOAD er altså ikke særlig brugt i COBOL), så er det ikke rigtig værd at bruge 2 år mere på, istedet for at få erfaring med hvordan man rent faktisk udvikler i den rigtige verden.
Hvis i har nogle specifikke spørgsmål til hvordan uddanelsen fungerer, til at give et bedre overblik, så kan jeg forsøge at svare :)
Jeg synes absolut at de er for teknologi specifikke i en lang række af fagene. Personligt har jeg overvuderet at tage en Datalog Bachalor bagefter, hvis jobmarkedet viser at det er en god ide.
Problemet er at man kan lære så og så meget teori. Men hvis man står til at blive omskolet til at slet ikke arbejde med samme sprog og teknikker (OOAD er altså ikke særlig brugt i COBOL), så er det ikke rigtig værd at bruge 2 år mere på, istedet for at få erfaring med hvordan man rent faktisk udvikler i den rigtige verden.
Hvis i har nogle specifikke spørgsmål til hvordan uddanelsen fungerer, til at give et bedre overblik, så kan jeg forsøge at svare :)
Har du lyst til at forklare hvorfor?Stryder (25) skrev:Matematiske modeller er essentielt for softwarekonstruktion, som det er for bygningskonstruktion.
Måske er det fordi jeg tager meget for givet, men der er rigtig rigtig meget software som ikke kræver noget advanceret matematik.
Jeg ser altså ikke særlig meget grund til at kende til integral-regning og applied-mathematics for at lave et lager-styrings program.
Kode-performance (big oh og lign), 3D rendering og specialiseret forsknings-software er de mest typiske brug af matematik jeg ser.
Begge mine forældre er udviklerer, og ingen af dem har brugt universitetsniveau matematik de sidste 30 år.
Stryder (25) skrev:
Kan du give nogle konkrete eksempler med hvad du definerer som typiske business apps?
Mener du generel software som ikke er missionskritiske?
En business app er en app som bruge stil at tjene penge. Den kan godt være mission critical for firmaet, men hvis den går ned så koster det kun penge ikke menneskeliv.
Stryder (25) skrev:
Hele problemet ligger i at de fleste firmaer og udviklere svarer: "Formel... hvad er det for noget?",
altså at udviklingsteknikkerne i IT verdenen er for uformel til noget der er så formelt.
Der er masser af IT folk som kender begrebet.
Og har kasseret det til det store flertal af apps.
Stryder (25) skrev:
Det er da vigtigt at kunne omsætte sin logiske tænkning
til formel logik på et dokument, så man selv kan huske det og
andre også kan forstå det (uden at misforstå det), hvis man har tænkt sig at arbejde i et firma, hvor flere udviklere skal kunne samarbejde.
Udviklere over hele verden er tilsyneladende i stand til at kommunikere uden.
Stryder (25) skrev:
Det behøver det jo ikke at være. Når det kommer til stykket,
vil fejlfri produkt jo ikke skade, tvært imod.
Det må være ubeskriveligt befriende ikke skulle tænke på
at debugge og udgive patch konstant :oP
For det første, så er der jo den lille detalje som hedder omkostninger. Det kan ikke betale sig øknomisk at lave fejlfrit software til typiske business apps.
For det andet så er det en misforståelse at formelle metoder sikrer 100% fejlfrit software.
Stryder (25) skrev:
Er der mange i byggebrachen der praler med at deres konstruktioner ikke braser sammen af og til?
Det er jo underforstået.
Konstuktioner der braser sammen er jo heldigvis en undtagelse
og ikke en regel, hvor det er det omvende i softwarebranchen
(til alles store frustration).
Argumentet om at traditionel ingeniør arbejde bare virker og IT bareer fejlbehæftet er ret almindeligt.
Men den holder ikke vand.
Tænk på DR's nye bygning (enorme budget overskridelser og bygningen er pive utæt), motorvejsbroer som smuldrede efter alt for få år o.s.v..
Eller tænk på mere daglidags ting som biler, kaffemaskiner etc.. De går da utroligt tit i stykker.
Stryder (25) skrev:
Men ja, som du siger, så er det ikke noget de fleste softwarefirmaer efterlyser,
eller for den sag skyld overhovedet har kendskab til.
Som sagt tror jeg at der er masser der har kendskab til det.
Men de har ikke noget at bruge det til.
Stryder (25) skrev:
Nå tilbage til hovedartiklen,
firmaerne har brug for folk der kan overbevise ledelsen om
at deres udviklingsmetode er grunden til det meste af de fejl der opstår i deres produkter, og kunne indføre formelle metoder.
Dem der tror at formelle metoder er egnede til alle problem stillinger bør da starte deres eget software konsulent firma og blive multi-multi-milliardærer. Hvis altså deres ide er så god som de siger den er.
Windcape (27) skrev:Problemet er at man kan lære så og så meget teori. Men hvis man står til at blive omskolet til at slet ikke arbejde med samme sprog og teknikker (OOAD er altså ikke særlig brugt i COBOL), så er det ikke rigtig værd at bruge 2 år mere på, istedet for at få erfaring med hvordan man rent faktisk udvikler i den rigtige verden.
Man bliver også en bedre Cobol programmør af at lære OOAD.
Man kan stort set altid bruge et eller andet af det man lærer.
Windcape (28) skrev:Har du lyst til at forklare hvorfor?
Måske er det fordi jeg tager meget for givet, men der er rigtig rigtig meget software som ikke kræver noget advanceret matematik.
Jeg ser altså ikke særlig meget grund til at kende til integral-regning og applied-mathematics for at lave et lager-styrings program.
Kode-performance (big oh og lign), 3D rendering og specialiseret forsknings-software er de mest typiske brug af matematik jeg ser.
Begge mine forældre er udviklerer, og ingen af dem har brugt universitetsniveau matematik de sidste 30 år.
Nu taler han om formelle metoder d.v.s. krav udtrykt i Z eller VDM og verfikation af at koden matcher kravene.
Ikke om almindelig algoritme matematik.
Min erfaring er iøvrigt lidt anderledes. Den matematiske forståelse er ofte en stor fordel i forbindelse med software.
Beregninger, algoritmer, big-O analyse, statistik o.s.v..
#29: lorenzen skrev:
Stryder, når du snakker om formel logik, så bliver jeg lidt forvirret.
Mener du formel, som i formal methods eller?
Ja, det var det jeg mente :)
#28: Windcape skrev:Har du lyst til at forklare hvorfor?
Måske er det fordi jeg tager meget for givet, men der er rigtig rigtig meget software som ikke kræver noget advanceret matematik.
#32: arne_v har svaret på det :)
#30: arne_v skrev:
Udviklere over hele verden er tilsyneladende i stand til at kommunikere uden.
Ja, er det ikke netop grunden til at der opstår fejl og
misforståelser, fordi de tror at de har forstået det?
#30: arne_v skrev:
For det første, så er der jo den lille detalje som hedder omkostninger.
De projekter jeg kender til som f.eks.
informations management systemet udviklet for det hollandske forsvar, blomster auktionen i Aalsmeer,
e-penge punge systemet af Felica Networks,
børs systemet udviklet af JFITS (nuværende CSK corporation),
har alle været leveret til tiden og fejlfrit,
altså ikke overskredet budgettet.
#30: arne_v skrev:
Det kan ikke betale sig øknomisk at lave fejlfrit software til typiske business apps.
Grunden til du siger det, er det fordi budgettet er så meget
mere stramt for typiske business apps i forhold til de
missionskritiske projekter?
#30: arne_v skrev:
For det andet så er det en misforståelse at formelle metoder sikrer 100% fejlfrit software.
Formelle metoder i sig selv sikre selvfølgelig ikke 100% fejlfrit software.
Der skal jo være folk der kan finde ud af det,
og folk der læres op.
Men det er måske også inkluderet i det du mente?
#30: arne_v skrev:
Argumentet om at traditionel ingeniør arbejde bare virker og IT bareer fejlbehæftet er ret almindeligt.
Men den holder ikke vand.
Ser man på dagligdags software kommer der jo kontinuært
patches fordi den indeholder fejl eller sikkerhedshuller.
Ja, selvfølgelig kræver andre ingeniør projekter vedligeholdelse
fordi de er bundet på fysiske begrænsninger,
men software har den privilegie at ikke at være begrænset
af fysikken (ser bort fra indlejret systemer).
At systemet slukker pga. hardwarefejl, er jo et helt andet problem.
#30: arne_v skrev:
Tænk på DR's nye bygning (enorme budget overskridelser og bygningen er pive utæt), motorvejsbroer som smuldrede efter alt for få år o.s.v..
Yeps, men det er jo også mere undtagelse end regel.
Standard huse laves jo af komponenter, hvor folk år tilbage har beregnet på det og er gennemafprøvet utallige gange,
#30: arne_v skrev:
Eller tænk på mere daglidags ting som biler, kaffemaskiner etc.. De går da utroligt tit i stykker.
Er det ikke en del af specifikationen at der opvejes dens holdbarhed?
Et produkt kan laves utroligt solidt, så det bare holder mange
gange andre end de andre på markedet, men koster
af den grund så også ekstra.
Også er der de ting der bare skal være billigt, og
dermed bare er skrøbeligt.
Der er folk der hellere vil udskifte hele tiden og
folk der vil have noget der bare virker.
Jeg hører til dem der gerne vil have noget der bare virker.
#30: arne_v skrev:
Som sagt tror jeg at der er masser der har kendskab til det.
Men de har ikke noget at bruge det til.
Det kan bare være mig der har talt med de uvidende udviklere
og firmaer og forsvindende få der kender til det :oD
Fra min egen erfaring fra at arbejde i CSK Corporation i Japan,
var problemet at overtale ledelsen i andre firmaer til det.
Af de firmaer der kun kender til det, men ikke har brugt det,
er nysgerrige, men er tilbageholdende i at financiere for oplæring af deres udviklere.
#30: arne_v skrev:
Dem der tror at formelle metoder er egnede til alle problem stillinger bør da starte deres eget software konsulent firma og blive multi-multi-milliardærer. Hvis altså deres ide er så god som de siger den er.
Det går sgu meget godt for Felica Networks :o)
Hey, du må da vide at for at opstarte det firma
kræver det meget kapital.
Det er jo lækkert for Felica at Sony har været så gavmilde
i at financiere for det.
Der er brug for forskellige folk der kan noget andet
udover udviklerne, som regnskabsansvarlige, driftansvarlige, pr-ansvarlige, hr-ansvarlig, sekretærer,osv. osv.
Ikke alle kan rumme at være det hele i sig selv.
(jaja, jeg ved godt at du mente det ironisk :o) ).
Beklager at mit indlæg er blevet lidt offtopic.
Den matematiske forståelse er klart en fordel, men jeg vil indrømme at jeg ikke kan huske særlig meget af mit A niveau matematik.arne_v (32) skrev:Min erfaring er iøvrigt lidt anderledes. Den matematiske forståelse er ofte en stor fordel i forbindelse med software.
Beregninger, algoritmer, big-O analyse, statistik o.s.v..
Men jeg ved tilgengæld hvor jeg kan slå det op, samt at jeg ville kunne forstå formlerne nogenlunde, og sandsyneligvis implementere dem i kode. (Funktionelle sprog er geniale til at implementere former i).
Men det ville jo ikke nøtte noget at kunne matematikken hvis jeg ikke ved hvordan jeg bruger den i programmering :-) Så den del bør uddanelserne vel stadig undervise i.
Dataloger modsat datamatikere, lærer ikke specifikt at kode. Det er meget valgfrit, og mest på hobby niveau.
Jeg har ikke snakket med mange dataloger som havde software-design (OOAD/xP/Scrum/UP) som en del af deres undervisningsforløb.
De fleste endte op med at kode lowlevel asm/c++ programmer, og blev direkte sure hvis man snakkede om strukturerede kode, design, kode conventioner, osv.
Det er vel ligesom en ingenør. Måske kan han regne, men det er jo ikke særlig brugbart hvis han ikke kan finde rundt på en byggeplads.
#35 (Holder lige offtopic stilen)
PGL er mine specialevejleder. Iøvrigt kan jeg for da fortælle, hvis du ikke allerede ved det, at man arbejdet hårdt på at overflødiggøre VDMtools via overturetool (og det ser ud til at være tæt på). Yderligere så arbejdes der på at indføre VDM i CO-simulation/design, her hvor jeg blandt andet skriver mit speciale. Hvis du vil høre mere om det,
http://www.overturetool.org/twiki/bin/view
http://www.marcelverhoef.nl/pmwiki.php?n=Main.PhdT... (første PhD omkring co-simulation)
#36
Jeg kender en del dataloger, stort set ingen af dem kan kode ASM eller C++. Hvertfald ikke fra deromkring hvor de bliver skudt afsted som nyuddannet, hvad de kan bagefter skal jeg ikke kunne lige.
Tilgengæld kan de alle sammen udemærket godt OOAD og arbejde meget analytisk og struktureret hvad angår softwareudviklig.
Men hvorfor dog du mene at det er nødvendigt med undervisning i SCRUM, XP, UP og andet hejs forstår jeg ikke. Og jeg forstår slet ike hvordan det har ret meget med softwaredesign at gøre.
Det er fint du er ved at uddanne datamatiker og hører til dem som tror at de 2 år der er rigeligt, og resten bedst læres på arbejdsmarkedet. Men at tro de 2 år er de gyldne og perfekt, og dataloger nærmest spilder tiden synes jeg er at overvurdere sig selv. (Sådan jeg læser dit indlæg). Man kan lære uendeligt meget mere teori, og husk at selv dataloger arbejder med projekter (DIKU måske undttaget :) ) i stor stil, hvor det netop er nødvendigt at udvise en stor sikkerhed i det at kunne holde hammeren rigtigt når man slår søm i. (læs programmere).
Personligt er jeg på linie med arne_v hvad angår uddannelse af udviklere, datamatikeren er for kort og burde helt erstattes af en bachelor (evt. ingeniør uddannelse). Fordi det kan da godt være at du er pisse dygtig Windcape (du virker hvertfald til at brænde for dine ting), men der kommer stadigvæk alt for mange igennem p ådet studie der ikke kan noget som helst.
Og skulle det endeligt være, så ville jeg hellere oplære en datalog der ikke har kodet ret meget, fremfor en datamatiker der heller ikke har det samme.
Og hvad angår formal methods i denne sammehæng, så synes jeg at flere burde undervises i det. Det behøves ikke at være den store tunge udgave, men der er flere tilfælde hvor formal methods light kunne være dejligt at bruge. Jeg ser hvertfald gerne det brugt til krav, og andre steder, eller i det mindste hvor man arbejder med mission critical systemer.
Og en af grundene til at mange ryster på hovedet af formal methods, er nok også at det endte med at blive oversolgt som silverbullet, og så opnår man hurtigt det som arne_v også beskriver, en hel industri som ryster på hovedet af det.
PGL er mine specialevejleder. Iøvrigt kan jeg for da fortælle, hvis du ikke allerede ved det, at man arbejdet hårdt på at overflødiggøre VDMtools via overturetool (og det ser ud til at være tæt på). Yderligere så arbejdes der på at indføre VDM i CO-simulation/design, her hvor jeg blandt andet skriver mit speciale. Hvis du vil høre mere om det,
http://www.overturetool.org/twiki/bin/view
http://www.marcelverhoef.nl/pmwiki.php?n=Main.PhdT... (første PhD omkring co-simulation)
#36
Jeg kender en del dataloger, stort set ingen af dem kan kode ASM eller C++. Hvertfald ikke fra deromkring hvor de bliver skudt afsted som nyuddannet, hvad de kan bagefter skal jeg ikke kunne lige.
Tilgengæld kan de alle sammen udemærket godt OOAD og arbejde meget analytisk og struktureret hvad angår softwareudviklig.
Men hvorfor dog du mene at det er nødvendigt med undervisning i SCRUM, XP, UP og andet hejs forstår jeg ikke. Og jeg forstår slet ike hvordan det har ret meget med softwaredesign at gøre.
Det er fint du er ved at uddanne datamatiker og hører til dem som tror at de 2 år der er rigeligt, og resten bedst læres på arbejdsmarkedet. Men at tro de 2 år er de gyldne og perfekt, og dataloger nærmest spilder tiden synes jeg er at overvurdere sig selv. (Sådan jeg læser dit indlæg). Man kan lære uendeligt meget mere teori, og husk at selv dataloger arbejder med projekter (DIKU måske undttaget :) ) i stor stil, hvor det netop er nødvendigt at udvise en stor sikkerhed i det at kunne holde hammeren rigtigt når man slår søm i. (læs programmere).
Personligt er jeg på linie med arne_v hvad angår uddannelse af udviklere, datamatikeren er for kort og burde helt erstattes af en bachelor (evt. ingeniør uddannelse). Fordi det kan da godt være at du er pisse dygtig Windcape (du virker hvertfald til at brænde for dine ting), men der kommer stadigvæk alt for mange igennem p ådet studie der ikke kan noget som helst.
Og skulle det endeligt være, så ville jeg hellere oplære en datalog der ikke har kodet ret meget, fremfor en datamatiker der heller ikke har det samme.
Og hvad angår formal methods i denne sammehæng, så synes jeg at flere burde undervises i det. Det behøves ikke at være den store tunge udgave, men der er flere tilfælde hvor formal methods light kunne være dejligt at bruge. Jeg ser hvertfald gerne det brugt til krav, og andre steder, eller i det mindste hvor man arbejder med mission critical systemer.
Og en af grundene til at mange ryster på hovedet af formal methods, er nok også at det endte med at blive oversolgt som silverbullet, og så opnår man hurtigt det som arne_v også beskriver, en hel industri som ryster på hovedet af det.
#37
Der er også en del forskel på at læse Datalogi på Aalborg, Århus, DTU og KU (jeg mener ikke SDU tilbyder datalogi?)
I Århus er det meget mere matematisk end i f.eks. Aalborg.
De firmaer jeg kender til, f.eks. Danske Bank, bruger 90% af tiden på forberedelse, altså ting som udviklingsmetoder (som begreb) dækker over.
Og selve softwaren er bygget på koncepter og hacks over 20 år, hvor du får meget svært ved at putte moderne koncepter fra den rent faktiske software udvikling ind.
At kender til arkitektur og koncepter er fint, men det er ikke særlig brugbar viden hvis du laver 95% udvidelses arbejde eller fejlretninger.
Et rent pratisk eksempel på hvorfor både teori og viden er nødvendig. Dette er fra vores netværksprojekt vi lige har afsluttet:
I Java og C# skal man afslutte en string med newline (\n) for at denne bliver sendt med autoflush.
Dette var ikke en del af vores teori, men sprogspecifikt, og volte størstedelen af klassen problemer, da de ikke havde lært om dette, eller arbejdet med det før (ligesom mig), og derfor ikke kendte til det.
Der er også en del forskel på at læse Datalogi på Aalborg, Århus, DTU og KU (jeg mener ikke SDU tilbyder datalogi?)
I Århus er det meget mere matematisk end i f.eks. Aalborg.
Hvordan kan udviklingsmetoder ikke have noget med software udvikling at gøre?lorenzen (37) skrev:Men hvorfor dog du mene at det er nødvendigt med undervisning i SCRUM, XP, UP og andet hejs forstår jeg ikke. Og jeg forstår slet ike hvordan det har ret meget med softwaredesign at gøre.
De firmaer jeg kender til, f.eks. Danske Bank, bruger 90% af tiden på forberedelse, altså ting som udviklingsmetoder (som begreb) dækker over.
Og selve softwaren er bygget på koncepter og hacks over 20 år, hvor du får meget svært ved at putte moderne koncepter fra den rent faktiske software udvikling ind.
At kender til arkitektur og koncepter er fint, men det er ikke særlig brugbar viden hvis du laver 95% udvidelses arbejde eller fejlretninger.
Et rent pratisk eksempel på hvorfor både teori og viden er nødvendig. Dette er fra vores netværksprojekt vi lige har afsluttet:
I Java og C# skal man afslutte en string med newline (\n) for at denne bliver sendt med autoflush.
Dette var ikke en del af vores teori, men sprogspecifikt, og volte størstedelen af klassen problemer, da de ikke havde lært om dette, eller arbejdet med det før (ligesom mig), og derfor ikke kendte til det.
Og så kom denne her lige op på vores informations-board
Så vi får sikkert mulighed for at høre mere om den inden jeg er færdig uddannet.
Da jeg skal deltage i udviklingarbejde i forbindelse med de nye professionsbachelor uddannelser aflyses undervisning i CNDS fredag den 24. april. Det er endnu ikke bestemt hvor de blokke flyttes til. - (CNDS Læreren)
Så vi får sikkert mulighed for at høre mere om den inden jeg er færdig uddannet.
#37: lorenzen skrev:
Og en af grundene til at mange ryster på hovedet af formal methods, er nok også at det endte med at blive oversolgt som silverbullet, og så opnår man hurtigt det som arne_v også beskriver, en hel industri som ryster på hovedet af det.
Ja, kender et par professorer der er hardcore formalister,
der vil have det hele skal kunne bevises fra den ene ende til den anden og derfor bliver budgettungt.
Det er nok for tungt og økonomisk belastende for firmaer
at tage det til sig.
Jeg har ikke været så specifik med hvor formelt det skal være,
men som #36 Lorentzen skriver så vil formal methods lite
anvendt bredere i industrien være kæmpe fremskridt mod at fjerne
fejl i software før release, og allerde opdage fejlene på specifikationsniveau.
#38: Windcape skrev:
Men hvorfor dog du mene at det er nødvendigt med undervisning i SCRUM, XP, UP og andet hejs forstår jeg ikke. Og jeg forstår slet ike hvordan det har ret meget med softwaredesign at gøre.
lorenzen (#37)
Hvordan kan udviklingsmetoder ikke have noget med software
Citerer PGL : "Udviklingsmetoder i softwarebranchen er som mode. Det er der hip for tiden, er det der bliver anvendt".
Kunne ikke være mere enig :oD
Software projekter kan jo kæmpestore, kan jo svare til at bygge et højhus i byggeprojekter.
Og det er dem der er ryger ind i avisen, hvor flere millioner eller nogen tilfælde milliarder går til spilde.
Men ja, hvis man bare skal lave noget hjemmeudviklet software tilsvarernde et hundehus, er det nok overkill med at lave matematiske beregninger :oD
#38: Windcape skrev:
De firmaer jeg kender til, f.eks. Danske Bank, bruger 90% af tiden på forberedelse, altså ting som udviklingsmetoder (som begreb) dækker over.
Men fordi et firma (lille som stort )vælger at bruge uformelle udviklingsmetoder, betyder det jo ikke at det er det mest effektive.
Det var hele pointen med min klagesang over software industrien :oD
Folk i udviklingsfirmaerne kigger på hvad der er af muligheder og tager stilling til metoden om den kan anvendes.
Netop derfor at visse metoder er bedre end andre?Stryder (40) skrev:Software projekter kan jo kæmpestore, kan jo svare til at bygge et højhus i byggeprojekter.
Men nu om dage er den iterative model alligevel ved at vinde temmlig meget ind. Og ellers har man meget meget faste deadlines.
Stryder (33) skrev:De projekter jeg kender til som f.eks.
informations management systemet udviklet for det hollandske forsvar, blomster auktionen i Aalsmeer,
e-penge punge systemet af Felica Networks,
børs systemet udviklet af JFITS (nuværende CSK corporation),
har alle været leveret til tiden og fejlfrit,
altså ikke overskredet budgettet.
Jeg er altid meget skeptisk, når projekter påstår at de er fejlfrie.
Stryder (33) skrev:
Grunden til du siger det, er det fordi budgettet er så meget
mere stramt for typiske business apps i forhold til de
missionskritiske projekter?
Business apps er skam ofte mission critical.
Men det er validt at sige at man ikke vil bruge 50 millioner kroner ekstra på at reducere forventet nedtid for en netbank og dermed spare 25 millioner kroner.
Det anses normalt ikke for validt at at sige at man ikke vil bruge 50 milloner kroner ekstra på at reducere forventede dødstal med 25.
Stryder (33) skrev:
Ser man på dagligdags software kommer der jo kontinuært
patches fordi den indeholder fejl eller sikkerhedshuller.
Der kommer også hyppigt tilbagekaldelser af biler.
Stryder (33) skrev:
Standard huse laves jo af komponenter, hvor folk år tilbage har beregnet på det og er gennemafprøvet utallige gange,
Kvalitet af IT løsninger vil sikkert også være noget bedre hvis vi skulle udvikle det samme igen og igen.
Stryder (33) skrev:
Er det ikke en del af specifikationen at der opvejes dens holdbarhed?
Et produkt kan laves utroligt solidt, så det bare holder mange
gange andre end de andre på markedet, men koster
af den grund så også ekstra.
Også er der de ting der bare skal være billigt, og
dermed bare er skrøbeligt.
Det er det samme med software. Du kan få kvalitet eller du kan få det billigt. Du kan ike få begge dele, fordi kvalitet koster.
Så der prioriteres.
Stryder (33) skrev:
Det går sgu meget godt for Felica Networks :o)
Men de har ikke overhalet IBM, TCS, Accenture, Cap Gemini endnu.
Stryder (33) skrev:
Hey, du må da vide at for at opstarte det firma
kræver det meget kapital.
Software konsulent firma er nok noget af det mindst kapitalkrævende.
Windcape (36) skrev:Men jeg ved tilgengæld hvor jeg kan slå det op, samt at jeg ville kunne forstå formlerne nogenlunde, og sandsyneligvis implementere dem i kode. (Funktionelle sprog er geniale til at implementere former i).
Jeg tror ikke rigtigt på den med at slå matematik op, når man har brug for det.
Det er ligesom at slå design patterns op, når man har brug for det.
Det virker ikke i praksis.
Windcape (36) skrev:Dataloger modsat datamatikere, lærer ikke specifikt at kode. Det er meget valgfrit, og mest på hobby niveau.
Jeg troede at alle dataloger kom gennem adskillige programmerings sprog i løbet af studiet.
ML o.s.v..
Windcape (36) skrev:Jeg har ikke snakket med mange dataloger som havde software-design (OOAD/xP/Scrum/UP) som en del af deres undervisningsforløb.
Software design burde være et valg fag på et datalogi studie.
Jeg er ikke sikker på at udviklings metodikker hører til under datalogi.
lorenzen (37) skrev:Og hvad angår formal methods i denne sammehæng, så synes jeg at flere burde undervises i det. Det behøves ikke at være den store tunge udgave, men der er flere tilfælde hvor formal methods light kunne være dejligt at bruge. Jeg ser hvertfald gerne det brugt til krav, og andre steder, eller i det mindste hvor man arbejder med mission critical systemer.
Det burde absolut være et valgfag på en længerevarende IT uddannelse.
Fordi:
1) der er projekter hvor den slags ikke bare kan bruges men bør bruges
2) selvom man arbejder med et projekt hvor platin udgaven med diamant støv ikke giver mening, så kunne man stadig blive en bedre udvikler af at have den ekstra ballast
Windcape (38) skrev:Der er også en del forskel på at læse Datalogi på Aalborg, Århus, DTU og KU (jeg mener ikke SDU tilbyder datalogi?)
http://www.sdu.dk/Uddannelse/Fuldtidsstudier/Kandi...
Windcape (38) skrev:
Og selve softwaren er bygget på koncepter og hacks over 20 år, hvor du får meget svært ved at putte moderne koncepter fra den rent faktiske software udvikling ind.
At kender til arkitektur og koncepter er fint, men det er ikke særlig brugbar viden hvis du laver 95% udvidelses arbejde eller fejlretninger.
Der er normalt mere prestige i at nyudvikle end i at vedligeholde eksisterende software.
Men det er faktisk ofte nemmere at nyudvikle end det er at finde gode løsninger på at tilføje funktionalitet til eksisterende software.
Og hvis ændringerne ligger udover simple "ups der mangler en +1 der" bugfixes, så kan man også godt bruge sin viden om software design.
Windcape (38) skrev:
Et rent pratisk eksempel på hvorfor både teori og viden er nødvendig. Dette er fra vores netværksprojekt vi lige har afsluttet:
I Java og C# skal man afslutte en string med newline (\n) for at denne bliver sendt med autoflush.
Dette var ikke en del af vores teori, men sprogspecifikt, og volte størstedelen af klassen problemer, da de ikke havde lært om dette, eller arbejdet med det før (ligesom mig), og derfor ikke kendte til det.
Den slags kan jeg så ikke se hører hjemme på en videregående uddannelse.
Det må man lære via noget erfaring (og i disse moderne tider via noget googling).
Og om 10 når man sidder og koder i det på dette tidspunkte populære sprog Foobar, så er det alligevel nogle helt andre problemstillinger man tumler med.
#46
Det er ikke helt så sort hvidt.
Hvis vi går fra 2 til 4 "farver" finder vi:
1) totalt nye systemer
2) tilføje nye subsystemer/komponent til eksisterende systemer
3) tilføje ny funktionalitet til eksisternde subsystem/komponent
4) rette fejl i eksisternde subsystem/komponent
Et rent gæt fra min side vil være 10%-30%-50%-10%.
Men ja - man skal kunne det hele.
Og #3-4 er iøvrigt gode at lære noget fra.
Og folk som nægter at lave #3-4 kan meget hurtigt blive "overflødige" når der skal skæres ned.
Det er ikke helt så sort hvidt.
Hvis vi går fra 2 til 4 "farver" finder vi:
1) totalt nye systemer
2) tilføje nye subsystemer/komponent til eksisterende systemer
3) tilføje ny funktionalitet til eksisternde subsystem/komponent
4) rette fejl i eksisternde subsystem/komponent
Et rent gæt fra min side vil være 10%-30%-50%-10%.
Men ja - man skal kunne det hele.
Og #3-4 er iøvrigt gode at lære noget fra.
Og folk som nægter at lave #3-4 kan meget hurtigt blive "overflødige" når der skal skæres ned.
#42: arne_v skrev:
Jeg er altid meget skeptisk, når projekter påstår at de er fejlfrie.
Er det ikke netop fordi det er uvildigt accepteret at software fejler,
og at det ikke er rigtigt kan gøres noget?
Og derfor ser det ud som utopi, når noget er blevet fejlfrit?
#42: arne_v skrev:
Business apps er skam ofte mission critical.
Men det er validt at sige at man ikke vil bruge 50 millioner kroner ekstra på at reducere forventet nedtid for en netbank og dermed spare 25 millioner kroner.
Ja, det vil give mening hvis man er sikret i at folks penge ikke flyder sammen med andres.
Projektlederne der var involdveret i de 4 projekter jeg nævnte
(info systemet for forsvaret, blomster auktionssystem,
felica chip og børs systemet), som jeg har talt med, sagde
med tilfredsstillende stemme at det hele blev færdigt til tiden
og inden for budgettet.
#30: arne_v skrev:
Det kan ikke betale sig øknomisk at lave fejlfrit software til typiske business apps.
Det jeg mente var, det du sagde var fordi budgettet er så meget
mere stramt for typiske business apps i forhold til de
projekter der anvender formelle metoder?
Jeg ved ikke om dette kan klassificeres som den typiske business app, men nu kom der lige den der nyhed om skats projekter der fejlede.
Det er da ikke fordi SKAT er sparsommelige :oD
Der er jeg overbevist om at formal methods lite, ville
have hjulpet big time, hvis de havde mandskab der praktiserede
det.
http://newz.dk/4-af-5-af-skats-it-projekter-i-2008...
#42: arne_v skrev:
Der kommer også hyppigt tilbagekaldelser af biler.
Ja, det betyder jo ikke at derfor at det er acceptabelt for alle.
Ok de tjener måske mindre fordi de skal bruge mere tid på at checke det igennem,
men hvis det får en omtale til at være rigtig solid og god til prisen, vil den helt sikkert sælge mere.
Ville da også mene det vil gælde for software.
#42: arne_v skrev:
Men de har ikke overhalet IBM, TCS, Accenture, Cap Gemini endnu.
Tag lige en slapper :oD
IBM har eksisteret siden 1889, Tata 1968, Accenture 1989, Cap Gemini 1967.
Felica networks er et nyt firma startet i 2004 og har kun 120 ansatte.
Giganternes medarbejder antal er heller ikke til at hamle op med her og nu for felica.
IBM 400.004 ansatte, TCS 141.143, Accenture 186.000 og Capgemini 86.000+.
IBM er over 3300 gange større og selv Cap Gemini har over 700 gange flere folk.
De er også specialiseret i kort distance IC kort, hvor alle de gamle giganter
har projekter over mange forskellige domæner.
Jeg skal ikke kunne sige hvor mange medarbejdere, projekter og kapital de respektive firmaer havde til at starte med
og hvor meget de voksede efter 5 år.
#42: arne_v skrev:
Software konsulent firma er nok noget af det mindst kapitalkrævende.
Ok, men fordi står inde for formelle metoder er det jo stadig svært at få røven fuld af penge.
Det er jo projekt i sig selv at overtale folk med meget erfaring til at skifte firma,
finde udviklere der er interesseret i det, finde folk der har talent for at sælge,
have en vis kundekreds der er inde for projektet og rekrutere de administrative folk.
Stryder (49) skrev:
Er det ikke netop fordi det er uvildigt accepteret at software fejler,
og at det ikke er rigtigt kan gøres noget?
Og derfor ser det ud som utopi, når noget er blevet fejlfrit?
Måske.
Men generelt er jeg meget skeptisk overfor fejlfrit software og systemer med 100% optid.
Og jeg er meget skeptisk hvis det ikke koster mere en den normale "næsten godt nok" kvalitet.
Stryder (49) skrev:
Projektlederne der var involdveret i de 4 projekter jeg nævnte
(info systemet for forsvaret, blomster auktionssystem,
felica chip og børs systemet), som jeg har talt med, sagde
med tilfredsstillende stemme at det hele blev færdigt til tiden
og inden for budgettet.
overholde budget != billigt
Stryder (49) skrev:
Jeg ved ikke om dette kan klassificeres som den typiske business app, men nu kom der lige den der nyhed om skats projekter der fejlede.
Det er da ikke fordi SKAT er sparsommelige :oD
Er det noget der er nogen kilde til?
Stryder (49) skrev:
Ok, men fordi står inde for formelle metoder er det jo stadig svært at få røven fuld af penge.
Det er jo projekt i sig selv at overtale folk med meget erfaring til at skifte firma,
finde udviklere der er interesseret i det, finde folk der har talent for at sælge,
have en vis kundekreds der er inde for projektet og rekrutere de administrative folk.
Der omsættes for hundredevis af milliarder dollars i software udvikling om året.
Hvis man havde en sikker måde at lave fejlfrit software uden at det kostede mere, så ville jeg tror at de praktisk problemer kunne overkommes.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund