Det er deprimerende at møde unge datalogi-studerende på gaden og høre deres misforståede syn på tilværelsen. Hvis man spørger en tilfældig datalogi studerende, lad os kalde hende Anne, om hendes syn på mainframes hører man tit citater ala:
- Bliver de stadig brugt?
- Er de ikke forældet?
- Dem har jeg ikke lært om!
Og det synes jeg i bund og grund er trist.
Personligt arbejder jeg i den finansielle sektor. Her er det netop mainframen der er rygraden i hele forretningen. Bevares, der er kommet nye platforme til der enten integrerer med mainframen eller lever deres eget liv, men i det store hele findes de mest essentielle data på mainframen og dens database. Et aktuelt eksempel på moderne teknik der integrer med en mainframe de mobile netbanker og de mobile betalingsløsninger. Der er ingen af dem der ikke anvender mainframe som backend. Uden at jeg kender arkitekturen for disse systemer, så kan jeg garantere at deres data ender med at blive gemt på en mainframe. På deres vej til mainframen passerer de formentlig en række mere moderne systemer som behandler dataene så de passer ind i de resterende systemer.
Jeg blev selv introduceret til mainframes via et studie-job hos TietoEnator i Åbyhøj hvor der blev udviklet og vedligeholdt Cobol kode til en Tandem-mainframe for en kunde. Det var naturligvis en omvæltning at komme fra Microsoft Visual Studio, som jeg anvendte til at skrive C/C++, og til et terminal-baseret miljø med en meget skrabet Windows IDE. Omvendt var det spændende at arbejde med et system jeg aldrig havde hørt om før, men som havde en enorm historik bag sig.
Jeg er ikke nødvendigvis den store fortaler for at anvende mainframes. Mine hobbyprojekter bliver typisk afviklet på forskellige cloud-løsninger, på mobilen eller på PC’en.
Det skal dog ikke underkendes at de RISC baserede mainframes har en stor historik og en betragtelig markedsandel. I følge en undersøgelse fra Intel omkring salget af server CPU’er, så havde RISC baserede mainframes en andel på ca. 35 % i 2010 hvor Intel selv havde ca. 60 %.
Hvad er en mainframe egentlig?
Wikipedia siger følgende:
“Mainframe computere er høj-kapacitetscomputere som hovedsageligt anvendes af større virksomheder og offentlige institutioner til kritiske applikationer, samt behandling af større mængder data såsom forbruger- og sektorrelateret statistik, ressourceallokering og registrering af transaktioner”
Hvis man skal sige det med andre, mere moderne, udtryk så kan det sidestilles med et grid eller en cloud. Den største forskel er dog at en mainframe er én stor integreret fysisk enhed, hvor grid og cloud typisk består af flere forbundne fysiske enheder.
Hvad kan de så?
De typiske programmeringssprog på mainframes er Cobol og PL/1. Cobol blev opfundet i 1959 mens PL/1 “først” kom i 1964. Det er altså to aldrende sprog – og det kan ses og mærkes på den måde der tænkes og programmeres i sprogene. Begge sprogene er procedurelle og har forskellige finurligheder som man enten lærer at elske eller hader for evigt. Én af de helt store sproglige features, som PL/1 og Cobol har haft i mange år, er den tætte integration med databasen; og da stortset alt bliver lagret i en database, så er det jo godt!
Cobol har embedded SQL ala Linq og man skriver f.eks. blot “EXEC SQL SELECT <felt> INTO :<cobol-variabel> FROM <tabel> END-EXEC” og voila så har man indlæst et værdi fra et felt fra databasen. Ydermere er der compile-time typecheck af at variablen rent faktisk passer sammen med feltet.
Hvorfor skifter virksomhederne ikke væk fra mainframe (cobol og pl/1)?
Det er der sikkert mange forskellige årsager til. Umiddelbart ser jeg én åbenlys faktor: If it ain’t broken, don’t fix it!
Desuden er der ikke nødvendigvis meget at hente ved at skifte væk fra mainframen.
Ja, udviklerne vil få adgang til nyere programmeringssprog og værktøjer, men tilgengæld vil man introducere en voldsom risiko for forretningen ved omskrivning af al softwaren til f.eks. C#. Yderligere er der heller ikke nogen garanti for at C# koden vil blive afviklet hurtigere, billigere eller mere effektivt end på mainframen.
Værktøjer og myter
Én af de store myter er at al udvikling sker via en terminal og tegnbaserede værktøjer. Det var virkeligheden for et par år siden og det er da også stadig muligt i dag. Umiddelbart tilbyder, f.eks. IBM z/OS adgang til systemet via en 3270 protokol, som oprindeligt blev udviklet til display terminaler eller “tynde klienter” som de hedder i dag.
De sidste 10-15 år er der dog kommet en række værktøjer der tillader udviklerne at trække sig længere væk fra de terminalbaserede værktøjer og over i værktøjer der er sammenlignlige med nyere programmeringssprog som Java og C#.
Helt konkret, så har IBM udviklet en Eclipse baseret IDE, kaldet Rational Developer for System z, der på alle måder minder om andre Eclipse baserede IDE’er og ved hjælp af Rational Team Concert kan man også håndtere source control i et “moderne” miljø.
… og hvad så nu?
Tjaeh, det ved jeg ikke. En opfordring herfra skal dog lyde at man ikke skal lade sig skræmme af mainframes. Det er måske ikke så sexet at fortælle ens studiekammerater at man tager et ”Mainframe” kursus på universitet, men til gengæld kan det være det ender med at give dig smør på brødet?
Det er altid en fascinerende diskussion omkring hvad det egentlig er man skal lære på universiteterne. I princippet er det vel en forskningsinstitution – samtidig forventer virksomheder også en vis viden og bestemte færdigheder når folk er uddannede derfra. Problemstillingen er velkendt i kampen mellem den frie forskning og industrien; universiteter forsker fremad, virksomheder eksisterer på fortidens fremtidssyn.
Helt enig Mathilde. Spørgsmålet bør vel heller ikke være om de studerende direkte har taget et mainframe-kursus, men om de har lært nok til at de kan sætte sig ind i mainframe-problematikker og programmering, hvis de får job indenfor det?
Vi kan ikke undervise i alt og det vigtigste er at få afdækket en række grundproblemstillinger og så lære de studerende at lære.
Husk at mainframe, cobol og pl/1 blot er værktøjer.
En mainframe er typisk et lager for enorme mængder data og håndtering af disse kunne være oplagte forskningsområder (big data, søgning, håndtering af databaselager, generelle algoritmer, m.m.).
Men er det ikke også allerede det? I Århus har vi f.eks. en center for massive data-algoritmer MADALGO og jeg er rimelig sikker på at det ikke er enestående.
Det er altid en fascinerende diskussion omkring hvad det egentlig er man skal lære på universiteterne. I princippet er det vel en forskningsinstitution – samtidig forventer virksomheder også en vis viden og bestemte færdigheder når folk er uddannede derfra. Problemstillingen er velkendt i kampen mellem den frie forskning og industrien; universiteter forsker fremad, virksomheder eksisterer på fortidens fremtidssyn.
Helt enig Mathilde. Spørgsmålet bør vel heller ikke være om de studerende direkte har taget et mainframe-kursus, men om de har lært nok til at de kan sætte sig ind i mainframe-problematikker og programmering, hvis de får job indenfor det?
Vi kan ikke undervise i alt og det vigtigste er at få afdækket en række grundproblemstillinger og så lære de studerende at lære.
Husk at mainframe, cobol og pl/1 blot er værktøjer.
En mainframe er typisk et lager for enorme mængder data og håndtering af disse kunne være oplagte forskningsområder (big data, søgning, håndtering af databaselager, generelle algoritmer, m.m.).
Men er det ikke også allerede det? I Århus har vi f.eks. en center for massive data-algoritmer MADALGO og jeg er rimelig sikker på at det ikke er enestående.
Det er pudsigt at I begge angriber vinklen omkring kurser på universiteter.
Der findes mainframe kurser på nogle universiteter (er det DTU eller DIKU?).
Min hoved anke er egentlig at folk tror 1) at mainframes er forældet og 2) at de ikke bliver anvendt i industrien. Begge er, som nævnt ovenfor, ikke nødvendigvis korrekt.
Én af de ting jeg tog med fra universitetet var de mange forskellige programmeringsparadigmer, værktøjer og sprog som jeg var igennem. Det gav mig en ballast som tillod mig at vælge job uafhængigt at værktøj.
Hvis studerende udelukkende bliver undervist i f.eks. Java, så går de glip af en masse ting!
Men studerende bliver vel ikke kun undervist i Java, gør de? Hvis de gør er jeg enig i at det er et kæmpe-problem. Forskellige programmeringsparadigmer bør være basal viden (og jeg angriber ikke en vinkel – jeg gav bare Mathilde ret :)).
Alle studerende jeg har mødt har vidst at mainframes bliver brugt i bankverdenen i Danmark. Bankerne er ret aktive i at promovere sig overfor de studerende. Mange har ikke lyst til at arbejde med det – men gerne med nyere problemstillinger indenfor batch-processering og databaser. Jeg selv vil helst ikke arbejde med mainframe-problemstillinger fordi jeg har en ide om at det specialiserer en ned i et (velbetalt) hul, som gør at det kan være sværere at bevæge sig rundt på arbejdsmarkedet (delvist også på grund af fordomme). Jeg er personligt mere til at være generalist og arbejde på mange forskellige domæner.
Du understøtter egentlig mine argumenter ret fint, idet du skildrer mainframes som værende noget der er på vej til at blive faset ud og dermed være “et hul”.
Mainframes er ligeså meget på vej ud som Internettet er det. Faktisk er begge ca. lige gamle og de fundamentale principper
Det er korrekt at der er en del af funktionaliteten fra mainframen der stille og roligt flyttes over på andre, mere moderne, platforme. Det sker (forhåbentlig) med en stærk business case i baghånden og ikke på baggrund af farvede billeder om at xyz-teknologi er ved at blive udfaset.
Men er der virkelig mange nye virksomheder som baserer sig på mainframes? Ellers er det jo et hul (og det gælder også for specialisering indenfor andre felter, hvor feltet er domineret af veldefinerede aktører og der ikke løbende kommer mange nye aktører til).
Om man skal skal skifte væk fra mainframen vil jeg ikke udtale mig om. En del af businesscasen er vel adgang til arbejdskraft og så må man tage den derfra. Jeg udtalte mig kun om mine egne præferencer og ikke bankernes tilfredshed med deres platform.
Det er pudsigt at I begge angriber vinklen omkring kurser på universiteter.
Der findes mainframe kurser på nogle universiteter (er det DTU eller DIKU?).
Min hoved anke er egentlig at folk tror 1) at mainframes er forældet og 2) at de ikke bliver anvendt i industrien. Begge er, som nævnt ovenfor, ikke nødvendigvis korrekt.
Én af de ting jeg tog med fra universitetet var de mange forskellige programmeringsparadigmer, værktøjer og sprog som jeg var igennem. Det gav mig en ballast som tillod mig at vælge job uafhængigt at værktøj.
Hvis studerende udelukkende bliver undervist i f.eks. Java, så går de glip af en masse ting!
Men studerende bliver vel ikke kun undervist i Java, gør de? Hvis de gør er jeg enig i at det er et kæmpe-problem. Forskellige programmeringsparadigmer bør være basal viden (og jeg angriber ikke en vinkel – jeg gav bare Mathilde ret :)).
Alle studerende jeg har mødt har vidst at mainframes bliver brugt i bankverdenen i Danmark. Bankerne er ret aktive i at promovere sig overfor de studerende. Mange har ikke lyst til at arbejde med det – men gerne med nyere problemstillinger indenfor batch-processering og databaser. Jeg selv vil helst ikke arbejde med mainframe-problemstillinger fordi jeg har en ide om at det specialiserer en ned i et (velbetalt) hul, som gør at det kan være sværere at bevæge sig rundt på arbejdsmarkedet (delvist også på grund af fordomme). Jeg er personligt mere til at være generalist og arbejde på mange forskellige domæner.
Du understøtter egentlig mine argumenter ret fint, idet du skildrer mainframes som værende noget der er på vej til at blive faset ud og dermed være “et hul”.
Mainframes er ligeså meget på vej ud som Internettet er det. Faktisk er begge ca. lige gamle og de fundamentale principper
Det er korrekt at der er en del af funktionaliteten fra mainframen der stille og roligt flyttes over på andre, mere moderne, platforme. Det sker (forhåbentlig) med en stærk business case i baghånden og ikke på baggrund af farvede billeder om at xyz-teknologi er ved at blive udfaset.
Men er der virkelig mange nye virksomheder som baserer sig på mainframes? Ellers er det jo et hul (og det gælder også for specialisering indenfor andre felter, hvor feltet er domineret af veldefinerede aktører og der ikke løbende kommer mange nye aktører til).
Om man skal skal skifte væk fra mainframen vil jeg ikke udtale mig om. En del af businesscasen er vel adgang til arbejdskraft og så må man tage den derfra. Jeg udtalte mig kun om mine egne præferencer og ikke bankernes tilfredshed med deres platform.
Fedt – godt sagt! Jeg bliver også irriteret når (primært unge) softwareudviklere kritiserer teknologier uden forståelse for de problemer, som den pågældende teknologi (bevist ved massiv empiri) har løst siden før de blev født – netop f.eks. Cobol, PL/1, AS/400, DB2, SQL, osv osv.
NoSQL og din yndlings-Lisp er sikkert cool nok, bevares, og de løser sikkert også en masse problemer på en elegant måde – der opstår bare ofte et smalsyn omkring de “nye” teknologier, som om de kan frelse hele verden, og som om at nye ting der ikke udvikles i disse teknlogier er født legacy.
Min holdning er at alle teknologier er mere eller mindre defekte, og at det du laver altid er født legacy. Jeg har endnu ikke set noget, som har kunnet forandre den indstilling 🙂
Jeg bliver så til gengæld irriteret, når (primært gamle 🙂 ) softwareudviklere kritiserer nye teknologier som “gammel vin på nye flasker” uden forståelse for at verden ændrer sig og det kan være at der er et twist til den gamle vin som passer bedre til nyere tankegang. Det kan f.eks. være et bedre toolsæt som kan udvikles fordi firmaet bag de nye teknologier investerer i communitiet og firmaet bag de gamle teknologier er tilfredse bare de har nogle folk og firmaer låst fast i de gamle teknologier fordi det er for svært at skifte ud.
Humlen er vel at vi alle har brug for et nuanceret billede af gamle og nye teknologier, men vi kan ikke alle have et dybdeborende billede af hele tech-verdenen (dertil er den trods alt for stor) og derfor er vi afhængige af at nogle få eksperter har lyst til at dele deres viden, så vi kan nuancere vores allesammens billede af hvordan verden ser ud i stedet for at bygge det på fordomme.
Kalder du mig “gammel”? 😉
Og ja, helt sikkert – jeg er skam meget enig. Hvis man skal generalisere det lidt, så er det bare irriterende når folk er frelste og tror at deres yndlingsteknologi (ny eller gammel) kan redde verden.
Men lige præcis i de kredse, som jeg typisk bevæger mig i, anses mainframe og den slags bare som stenalderteknologi – og det er bare rigtig sjovt, fordi mainframe på mange måde har fællestræk med cloud og alt det der. Og med “sjovt” mener jeg “irriterende”.
PS: Jeg plejer ikke at bruge ordet “irriterende” så mange gange – inderst inde elsker jeg alle mennesker 🙂
Jeg er helt enig Mogens, jeg driller bare :).
“Silver bullets”-teknologier tror jeg ikke på og det kan nemt blive salgssnakke om snakeoil. Derfor skriver jeg ofte “problemet med”-blogindlæg for at balancere – forhåbentlig uden at lyde for gammel og bitter. Jeg har nemt ved at blive begejstret for teknologier og derfor har jeg stor forståelse for at folk fortæller vidt og bredt om deres nye hammer – og har en tendens til at dømme folk ud fra deres intentioner (f.eks. dømmer jeg folk hårdt når de fortier problemer for at få hammeren til at se mere shiny ud og sælge flere, men ikke så hårdt, når det bare er (den første) forelskelse fra en glad entusiast).
Jeg var også meget varm fortaler for sprog X og framework Y da jeg var yngre. Som tiden går og man modnes begynder man at se mønstre gentage sig – man kan forledes nemt til at afvise nye tiltag med “det har vi prøvet, det virker ikke”, hvilket selvfølgelig er arrogant.
Jeg synes nu også det er svært ikke at blive smittet af de unge og uerfarnes energi og lyst til at eksperimentere og kombinere teknologier, selv om de nogen gange er en tand for blåøjede og tunnelsynede.
Nysgerrighed og eksperimentering er vigtig, også selv om man ender med at genopfinde tingene. Nogen gange kan vinklingen eller den hardware mæssige udvikling pludselig gøre en gammel “ny-opfindelse” relevant.
De unge vil med tiden også lære, for de lærer det tilsyneladende ikke på universitetet, at anerkende “gamle” sprog og teknologier ud fra den kontekst og tid som de blev opfundet i.
En lille pudsighed. Mange af de ting vi er imponerede over at vi kan i dag indenfor software, kunne de allerede for 50 år siden.
Jeg kan anbefale at se Bret Victors fantastiske foredrag “Programming in the future”. Jeg blev ret flov over hvor lidt vi reelt har bevæget os de sidste 50 år indenfor software/programmering (hardware er en helt anden sag): http://worrydream.com/#!/dbx
Mht. mainframe er det vel reelt et godt eksempel på en silver bullet. Fleksibilitet og høj pris tror jeg er blandt årsagerne til at mainframes stadig overlever i mange virksomheder. Ingen tvivl om, at mainframes stadig kan nogle ting som som ingen andre platforme kan, men jeg tror at de mange cloud platforme med tiden vil løbe fra den. Ikke mindst på skalerings og pris siden.
Min erfaring fra flere danske finansielle virksomeheder efterlader mig også et indtryk af at udviklingshastigheden på mainframen ikke er specielt hurtig. Så jeg forstår godt at folk rynker på næsen ind i mellem.
If it ain’t broken don’t fix er et godt mantra, men det er heller ikke nogen løgn at de fleste virksomheder heller ikke har mange alternativer end at blive på mainframen. En omskrivning er tit for bekostelig og investeringerne har været for store. Og det er her man også nemt bliver ramt af loss aversion. Som når man har smidt 500 millioner efter et offentligt projekt og så smider yderligere 200 millioner ekstra efter det, for at få det gjort færdig; så man ikke har mistet de 500 millioner.
Fedt – godt sagt! Jeg bliver også irriteret når (primært unge) softwareudviklere kritiserer teknologier uden forståelse for de problemer, som den pågældende teknologi (bevist ved massiv empiri) har løst siden før de blev født – netop f.eks. Cobol, PL/1, AS/400, DB2, SQL, osv osv.
NoSQL og din yndlings-Lisp er sikkert cool nok, bevares, og de løser sikkert også en masse problemer på en elegant måde – der opstår bare ofte et smalsyn omkring de “nye” teknologier, som om de kan frelse hele verden, og som om at nye ting der ikke udvikles i disse teknlogier er født legacy.
Min holdning er at alle teknologier er mere eller mindre defekte, og at det du laver altid er født legacy. Jeg har endnu ikke set noget, som har kunnet forandre den indstilling 🙂
Jeg bliver så til gengæld irriteret, når (primært gamle 🙂 ) softwareudviklere kritiserer nye teknologier som “gammel vin på nye flasker” uden forståelse for at verden ændrer sig og det kan være at der er et twist til den gamle vin som passer bedre til nyere tankegang. Det kan f.eks. være et bedre toolsæt som kan udvikles fordi firmaet bag de nye teknologier investerer i communitiet og firmaet bag de gamle teknologier er tilfredse bare de har nogle folk og firmaer låst fast i de gamle teknologier fordi det er for svært at skifte ud.
Humlen er vel at vi alle har brug for et nuanceret billede af gamle og nye teknologier, men vi kan ikke alle have et dybdeborende billede af hele tech-verdenen (dertil er den trods alt for stor) og derfor er vi afhængige af at nogle få eksperter har lyst til at dele deres viden, så vi kan nuancere vores allesammens billede af hvordan verden ser ud i stedet for at bygge det på fordomme.
Kalder du mig “gammel”? 😉
Og ja, helt sikkert – jeg er skam meget enig. Hvis man skal generalisere det lidt, så er det bare irriterende når folk er frelste og tror at deres yndlingsteknologi (ny eller gammel) kan redde verden.
Men lige præcis i de kredse, som jeg typisk bevæger mig i, anses mainframe og den slags bare som stenalderteknologi – og det er bare rigtig sjovt, fordi mainframe på mange måde har fællestræk med cloud og alt det der. Og med “sjovt” mener jeg “irriterende”.
PS: Jeg plejer ikke at bruge ordet “irriterende” så mange gange – inderst inde elsker jeg alle mennesker 🙂
Jeg er helt enig Mogens, jeg driller bare :).
“Silver bullets”-teknologier tror jeg ikke på og det kan nemt blive salgssnakke om snakeoil. Derfor skriver jeg ofte “problemet med”-blogindlæg for at balancere – forhåbentlig uden at lyde for gammel og bitter. Jeg har nemt ved at blive begejstret for teknologier og derfor har jeg stor forståelse for at folk fortæller vidt og bredt om deres nye hammer – og har en tendens til at dømme folk ud fra deres intentioner (f.eks. dømmer jeg folk hårdt når de fortier problemer for at få hammeren til at se mere shiny ud og sælge flere, men ikke så hårdt, når det bare er (den første) forelskelse fra en glad entusiast).
Jeg var også meget varm fortaler for sprog X og framework Y da jeg var yngre. Som tiden går og man modnes begynder man at se mønstre gentage sig – man kan forledes nemt til at afvise nye tiltag med “det har vi prøvet, det virker ikke”, hvilket selvfølgelig er arrogant.
Jeg synes nu også det er svært ikke at blive smittet af de unge og uerfarnes energi og lyst til at eksperimentere og kombinere teknologier, selv om de nogen gange er en tand for blåøjede og tunnelsynede.
Nysgerrighed og eksperimentering er vigtig, også selv om man ender med at genopfinde tingene. Nogen gange kan vinklingen eller den hardware mæssige udvikling pludselig gøre en gammel “ny-opfindelse” relevant.
De unge vil med tiden også lære, for de lærer det tilsyneladende ikke på universitetet, at anerkende “gamle” sprog og teknologier ud fra den kontekst og tid som de blev opfundet i.
En lille pudsighed. Mange af de ting vi er imponerede over at vi kan i dag indenfor software, kunne de allerede for 50 år siden.
Jeg kan anbefale at se Bret Victors fantastiske foredrag “Programming in the future”. Jeg blev ret flov over hvor lidt vi reelt har bevæget os de sidste 50 år indenfor software/programmering (hardware er en helt anden sag): http://worrydream.com/#!/dbx
Mht. mainframe er det vel reelt et godt eksempel på en silver bullet. Fleksibilitet og høj pris tror jeg er blandt årsagerne til at mainframes stadig overlever i mange virksomheder. Ingen tvivl om, at mainframes stadig kan nogle ting som som ingen andre platforme kan, men jeg tror at de mange cloud platforme med tiden vil løbe fra den. Ikke mindst på skalerings og pris siden.
Min erfaring fra flere danske finansielle virksomeheder efterlader mig også et indtryk af at udviklingshastigheden på mainframen ikke er specielt hurtig. Så jeg forstår godt at folk rynker på næsen ind i mellem.
If it ain’t broken don’t fix er et godt mantra, men det er heller ikke nogen løgn at de fleste virksomheder heller ikke har mange alternativer end at blive på mainframen. En omskrivning er tit for bekostelig og investeringerne har været for store. Og det er her man også nemt bliver ramt af loss aversion. Som når man har smidt 500 millioner efter et offentligt projekt og så smider yderligere 200 millioner ekstra efter det, for at få det gjort færdig; så man ikke har mistet de 500 millioner.
Humlen, et eller andet sted, er at jeg synes ikke man skal lade sin karriere begrænse af et værktøj (som platforme, databaser og sprog jo er).
Lidt cases:
– Hvis man gerne vil lave mobilapps og kun kan Cobol
– Hvis man gerne vil lave websites og services og kun kan Beta
– Hvis man gerne vil lave videnskabelig kode i Mathlab og kun kan C#
– Hvis man gerne vil lave low-level programmering men kun kan højniveau sprog
I alle tilfælde er sproget blot et værktøj. Det essentielle er ikke om du er “god til C++” men om du er god til at programmere eller tænke som en programmør.
Der er naturligvis en masse folk der gerne vil arbejde med de nyeste teknologier og disse er, ofte, primært tilgængelige i nyere sprog. Det er nok utopisk at tænke sig en mobilapp udelukkende udviklet i Fortran.
Du er inde på noget at det rigtige rasmus.
Det det handler om er at adskille værktøj, fra problemløsningen. For at bruge en fortærsket analogi. Alle kan bruge en hammer (eller meget hurtigt lære det), men det kan være svært at finde ud af hvordan man laver et køkken.
Man skal lære problemløsning først. Så kan man lære at bruge værktøjer, og deres fordele og begrænsninger. Jeg er en dygtigt håndværker fordi jeg kan lave gode løsninger. Jeg er en effektiv håndværker hvis jeg vælge de rigtige værktøjer.
For nogen år siden var der en del debat omkring hvor vide software udvikling var håndværk eller ej. Personligt mener jeg at det er håndværk, det kan ikke automatiseret og der er en stor del kreativ proces involveret.
De små kæpheste ligger begravet omkring jobtitler, f.eks:
– Programmers vs Developers
– Software Engineers vs Software Developers
Humlen, et eller andet sted, er at jeg synes ikke man skal lade sin karriere begrænse af et værktøj (som platforme, databaser og sprog jo er).
Lidt cases:
– Hvis man gerne vil lave mobilapps og kun kan Cobol
– Hvis man gerne vil lave websites og services og kun kan Beta
– Hvis man gerne vil lave videnskabelig kode i Mathlab og kun kan C#
– Hvis man gerne vil lave low-level programmering men kun kan højniveau sprog
I alle tilfælde er sproget blot et værktøj. Det essentielle er ikke om du er “god til C++” men om du er god til at programmere eller tænke som en programmør.
Der er naturligvis en masse folk der gerne vil arbejde med de nyeste teknologier og disse er, ofte, primært tilgængelige i nyere sprog. Det er nok utopisk at tænke sig en mobilapp udelukkende udviklet i Fortran.
Du er inde på noget at det rigtige rasmus.
Det det handler om er at adskille værktøj, fra problemløsningen. For at bruge en fortærsket analogi. Alle kan bruge en hammer (eller meget hurtigt lære det), men det kan være svært at finde ud af hvordan man laver et køkken.
Man skal lære problemløsning først. Så kan man lære at bruge værktøjer, og deres fordele og begrænsninger. Jeg er en dygtigt håndværker fordi jeg kan lave gode løsninger. Jeg er en effektiv håndværker hvis jeg vælge de rigtige værktøjer.
For nogen år siden var der en del debat omkring hvor vide software udvikling var håndværk eller ej. Personligt mener jeg at det er håndværk, det kan ikke automatiseret og der er en stor del kreativ proces involveret.
De små kæpheste ligger begravet omkring jobtitler, f.eks:
– Programmers vs Developers
– Software Engineers vs Software Developers