Gnaven udvikler: Moderne udvikling stinker

GOTO: En gnaven, gammel udvikler forklarer i direkte vendinger, hvorfor han mener, at moderne udvikling 'sucks'.

Den garvede udvikler Dave Thomas har sine holdninger. Hvis publikum var i tvivl, så slog han det selv fast fra begyndelsen af sit humoristiske oplæg, 'Why modern development sucks!'.

»Problemet med at tale pragmatisk er, at folk tror, du er en kynisk og gnaven gammel mand,« begyndte han storsmilende til publikum.

Den påstand svigtede han ikke undervejs i sit oplæg, hvor der ikke var sparet på generaliseringer og verbale tæsk til den moderne it-branche. Dog oftest i kombination med et opblødende glimt i øjet.

Blandt de mange punkter, som han smed på bordet, var den velkendte og i høj grad aktuelle problematik med, at virksomheder i it-branchen har store problemer med at finde kvalificeret arbejdskraft. Særligt er det de veluddannede it-folk, der har forstand på at udvikle, er efterhånden en eftertragtet vare.

De fleste virksomheder har derimod overflod af konsulenter, der oftest ikke selv har forstand på at udvikle kvalitetssoftware.

Men ifølge Dave Thomas havde nogle kræfter i branchen den perfekte løsning på det problem.

For at imødegå den manglende knowhow, opfandt branchen muligheden for at virksomheder, der ejer en teknologi, kan certificere andre virksomheder som officielle eksperter på deres produkt. Og virksomhederne elsker det.

»Så behøver de jo ikke bekymre sig om, hvorvidt de er kompetente eller ej. De ved måske stadig ingenting, men de deltager da i det mindste,« sagde han lidt komisk, før han med dyb stemme slog sin holdning fast:

»Ingen, der kan bryste sig af at kunne noget, har nogensinde påstået, at certificering er noget værd.«

Dave Thomas angreb også den agile udvikling, der er et af de store buzzwords, der florerer i branchen. Problemet har været, at særligt de store virksomheder oftest udvander og ignorerer de mest basale agile regler. Derfor får virksomhederne ikke det ud af det, som de håbede på.

Generelt mener han, at branchen bruger alt for meget tid på at definere metoder, i stedet for at udrette noget i praksis.

»Metoder kan være en god ting, men der er altså ikke tale om religion. At bruge en masse tid på at forstå og indføre agil udvikling i stedet for at udvikle dit produkt, er bare spild af tid. Brug knolden i stedet for,« opfordrede Dave Thomas.

Udviklerne, der trods alt findes i branchen, fik selvfølgelig også en opsang med på vejen.

»Den eneste grund til at vi har brug for SSD, er, at folk ikke bygger software, der er tilstrækkelig optimeret. Det bør tværtimod være programmørens mål at gøre koden mindre for hver ny version af en applikation.«

Dog skulle hele skylden ikke placeres på udviklernes skuldre.

»Min hovedregel er, at man kun kan opnå en smuk og optimeret kode, hvis man skriver den igennem tre gange. Men det tillader de færreste virksomheder i dag.«

Dave Thomas nåede ikke at sende mange løsningsforslag ud over scenekanten, før tiden var gået. Men at få pumpet noget regulær viden ind i branchen, var et særligt ønske, der dukkede op i hans oplæg flere gange undervejs.

»Hvis du [it-lederne] vil ændre på noget, så skal du investere i undervisning, der går længere end til den almindelige it-triviallitteratur.«

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (33)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Peter Hansen

God, optimeret, kode honoreres ikke i de fleste virksomheder. I stedet bliver udviklerne ofte målt på hvor meget kode, de har skrevet, ikke på hvor god koden er.
Det samme med dokumentation -der sættes næsten aldrig tid af til at dokumentere den skrevne kode.

PS. Ovenstående gælder også ved outsourcet kode.

  • 0
  • 0
Kim Rasmussen

... er der nogen andre der tør stille sig op og sige dette.

Selvfølgelig er det at generalisere for meget, men jeg synes at jeg gang på gang oplever især store virksomheder kaste dusinvis af folk efter at indføre nye metoder i udviklingsafdelingen. Når det så ikke virker efter hensigten så kastes der certificerede coaches og arkitekter og meta-mennesker og flere små gule papirlapper og whiteboards og møder og scrum og scrum of scrum ind i møllen.

Tænk hvis et hus blev bygget på samme måde.... uden tegninger, uden krav, uden fokus på resultatet men kun på processen....

Og de 2-3 udviklere som rent faktisk driver hele projektet og produceret noget forsøges druknet i møder og metoder og processer og procedurer.

... og ja, jeg er også bare en sur gammel mand ;)

  • 0
  • 0
Steen Poulsen

Ja, jeg har aldrig skrevet et program som er "godt" i første forsøg - det ender altid i en perfekt fungerende prototype. Men version 2 - skrevet fra bunden indeholder alle guldklumperne fra version 1 og bliver rigtig meget bedre. - Det eneste der kan spolere version 2 er - chefer som vil have mere funktionalitet - som der ikke oprindeligt var tænkt på - og så havner vi igen i en perfekt fungerende prototype.... :-D

Man skal i udviklings planerne afsætte tid til de her 1-2 prototyper, før den salgsbare version kommer.

God weekend.

  • 0
  • 0
Jacob Volstrup

Jeg synes det er lidt forsimplet at mene at man skal have implementeret den fulde funktionalitet tidligere, for at få systemet til at køre ordentligt. Det er jo nærmere et spørgsmål om at få gennemtænkt arkitekturen fra starten og så ellers være parat til at refaktorere koden løbende gennem udviklingen.

Jeg kan i alt fald ikke forestille mig ret mange systemer hvor der kan findes økonomi i at lave fuldt fungerende prototyper, måske endda to af slagsen, inden man påbegynder den reelle implementering. Derimod bør man bruge en prototype til at få afprøvet (og måske justeret) de centrale dele af sit system.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Mogens,

Tænk om Jesper for en gangs skyld ville gå efter bolden i stedet for manden.

Jeg går bestemt ikke efter manden her. Jeg påpeger, at han tydeligvis ikke kender forskel på "agil udvikling" til eksempelvis konstruktion af software og "vandfaldsudvikling" til konstruktion af huse.

Der er bestemt ikke noget galt i at være uinformeret.

  • 0
  • 0
Svend Haugaard

Nå nå. Det kunne du jo bare have skrevet første gang, i stedet for at skrive "Ja, tænk hvis du vidste, hvad du talte om." I øvrigt står der i Kims indlæg ikke explicit noget om hvad han ved/ikke ved, så det må du have læst mellem linierne.

Mvh. Svend

  • 0
  • 0
Kim Rasmussen

@Jesper: Nu henviste jeg mere til fokus på processen istedet for resultatet hvilket jeg mener jeg tit ser som et reelt problem ude i den virkelige verden hvor det alt for tit ikke er resultatet det handler om med deraf følgende udskudte deadlines or dårlig kvalitet.

Alt for ofte er nonfunktionelle krav (som f.eks. at det skal fungere, performe, kunne deployes, der skal være logs med de relevante ting, man skal kunne fejlsøge, det skal være sikkert osv. osv.) totalt ignoreret eller nedprioriteret.

Og dette har intet med udviklingsmodellen at gøre - man kan sagtens bygge god software med både agile metoder or med vandfaldsmodellen, men det handler ofte om hvem udviklerne er og hvad de kan og mindre om selve metoden.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Svend,

Nå nå. Det kunne du jo bare have skrevet første gang, i stedet for at skrive "Ja, tænk hvis du vidste, hvad du talte om."

Min kommentar ramte præcist kernen i Kims kommentar. Når man sammenligner agil softwareudvikling med husbyggeri og i øvrigt karakteriserer agil softwareudvikling som "uden tegninger, uden krav, uden fokus på resultatet men kun på processen", så er det imo mere end rimeligt at antage, at Kim ikke ved hvad han taler om. Det vel efter min mening være spild af tid/bits at pensle det yderligere ud.

  • 0
  • 0
Kim Rasmussen

Du misforstår mig.

Jeg sammenligner ikke agil softwareudvikling med husbyggeri - ej eller karakteriserer jeg agile metoder som "uden tegninger, uden krav osv.".

Jeg skriver om at kaste masser af folk efter at indføre nye eller andre metoder i udviklingsafdelingen og det ser jeg som et problem når dette sker på bekostning af fokus på resultatet.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Kim,

Jeg skriver om at kaste masser af folk efter at indføre nye eller andre metoder i udviklingsafdelingen og det ser jeg som et problem når dette sker på bekostning af fokus på resultatet.

Men hvis man indser, at det man gør ikke virker - så er det eneste rigtige da en gang imellem at ryste posen og se på, om man gør det på den rigtige måde ifht sine egne resourcer, den organisation (kunde) man lever i/for og projektets art.

  • 0
  • 0
Steen Christensen

Jesper

Nu tror jeg det er ved at være tid til at du klapper hesten, og hopper ned fra din selvbestaltede petestal.

Heller ikke Ciber lever altid som forventeligt.
Jeg har i min virksomhed oplevet "Microsoft" kode fra jer af. Microsoft kode = kan kompileres = kan leveres. I har naturligvis altid leveret et eller andet til tiden..... den ros skal i have.

Fokus på slutproduktet og koden der skal levere dette produkt kommer helt naturligt i fokus, når man som jeg arbejder i en medicinal virksomhed der er FDA godkendt, så det kan lade sig gøre uden agile eller andre "organiserede" forkortelses metoder.

  • 0
  • 0
Carsten Sonne

Steen,

Uden at skulle forsvare den omtalte leverandør, vil jeg da sige, at vi alle sammen jo laver fejl ind imellem. Såfremt du mener nogen ikke har levet op til en aftale, vil jeg da foreslå du tager kontakt til vedkommende - og så få den sag ud af verden.

Vh
Carsten Sonne

  • 0
  • 0
Michael Nielsen

Er faktisk en meget relevant sammenligning.

Scrum, eller hvad metode man nu vælger til software development kan lige så vel ligges over på noget som husbyggeri.

Husbyggeri egner sig dog til fortræffeligt til vandfalds modellen fordi netop den er en velforstået process, og afhængighederne er veldefineret.

Der er også software projekter der passer perfekt ind i vandfalds modellem - de er dog mere sjældene.

Agile metoder ville fungere til hus byggeri, men ville indføre væsentlig overhead i forhold til vandfalds modellen, fordi antallet af naturlige afhænighederne.

Samtlige metoder kan bruges til alle projekter, problemet er bare, at nogle modeller er mere naturlige at bruge til hvisse projekter, og bruger man den forkerte metode, gør man bare processen længere, og mere smertefuld, og dyrere.

Der findes ikke EN metode der er optimal i all sammenhæng.

Tænk hvis et hus blev bygget på samme måde.... uden tegninger, uden krav, uden fokus på resultatet men kun på processen....

Denne tekst beskriver mange system udviklings processer jeg har set og oplevet, der er ikke tænkt over hvor man skal hen, projekter omdefineres igen og igen, ganske dynamisk uden hensyn til der skal være en sammenhængende system i enden - det er alt for almindelig.

Agile metoder prøver at kompensere for at man ikke har en fast plan, og man ikke har faste krav. Her dur vandfaldsmodellen ikke, fordi vandfaldsmodellen tillader kun en vej og det er vejen frem. Tilgengæld giver vandfaldsmodellen en deterministisk endpunkt.

Software development i Hus sammenligningen er ofte at man bygger huset, og finder ud af at fundamentet er den forkerte farve, så man river lige det hele ned og starter med at bygge det forfra. Måske lykkes det at kunne genbruge nogle elementer, måske ikke. Mens man måske kommer frem til at den originale farve var bedst, så start igen.

så jeg er enig i kritikken af dig, kære jesper, fokusere på bolden og ikke manden, da det er sådan man får en saglig debat.

Vedrørende artiklen er jeg meget tilbøjeligt til at være meget enig med de emner der bliver bragt op.

Programmer nu om dage køre altså ikke hurtigere (generelt) end i 1988 da jeg fik min første computer (en amiga med fuld WYSIWYG). Hardwaren er over 10 000x hurtigere, men jeg skal stadigvæk vente på programmet starter, jeg skal stadigvæk vente ca 1 minut for computeren at blive klar.

Den eneste reelle forskel at alle programmerne er bloated med features, som 99% af folk aldrig bruger, programmerne er 200 - 10 000 x større. Min afhandling i 1993 var lavet med en word processor med billeder, tekst, gramma checker, og spell checker, som fylde 3 x 880k floppy diske, eller ca 2,4MB, Open office fylder mindst 280MB).

Moderne fokus i udvikling er at lave det hurtigst muligt, få det ud af døren, med minimal QA, og slet ingen optimering af hverken memory eller cpu forbrug.

Det var ufattlige hvor meget programmøere i 1990'erne kunne få ud af deres små computere, mens det er ufatteligt hvor lidt en moderne programmør får ud af deres enorme system resourcer!

Hvis man har hang til at tro på AGW CO2 debatten, så er den manglende optimering af kode, et enormt spild af energi, og generer enorme mængder af CO2.

  • 0
  • 0
Jesper Lund Stocholm Blogger

Hej Steen,

Nu tror jeg det er ved at være tid til at du klapper hesten, og hopper ned fra din selvbestaltede petestal.

Øh?

Heller ikke Ciber lever altid som forventeligt.
Jeg har i min virksomhed oplevet "Microsoft" kode fra jer af. Microsoft kode = kan kompileres = kan leveres. I har naturligvis altid leveret et eller andet til tiden..... den ros skal i have.

Jeg har ikke sagt, at CIBER altid leverer kode af guddommelig kvalitet - jeg har sagt, at CIBER bestemt ikke er en virksomhed, hvor "god kode ikke honoreres".

CIBER er som alle andre konsulenthuse. Nogle projekter er gode (for forretningen), andre projekter er dårlige.

  • 0
  • 0
HvorforFandenKanMan IkkeSletteSinProfil

Citat: "Blandt de mange punkter, som han smed på bordet, var den velkendte og i høj grad aktuelle problematik med, at virksomheder i it-branchen har store problemer med at finde kvalificeret arbejdskraft. Særligt er det de veluddannede it-folk, der har forstand på at udvikle, er efterhånden en eftertragtet vare."

Det er jo svært bedrøveligt at have en kammerat, der selv med meget højt niveau af forståelse og mere end 20 års erfaring med softwareudvikling i alle afskygninger, ikke kan få et arbejde. Årsagen er, at hans papir ikke lyder på IT-ingeniør eller datalog, men master i både matematik og fysik, selvom han har dedikeret sit arbejdsliv til softwaredesign.

Dette gør, at når han møder HR-funktionen i de fleste virksomheder bliver afvist med det samme. HR-funktionen har ingen kompetence til at vurdere folks egentlige evner, så min makker vil altid blive afvist såfremt der bare dukker en enkelt grønskolling op med et eller andet papir på en mere eller mindre tvivlsom uddannelse i noget, der rimer på IT.

Papirer er ikke lig kompetencer!
Kompetencer er ikke lig evner!

Hvis virksomhederne ønsker personale med evner, så må de gribe i egen barm og sørge for, at dem der behandler ansøgningerne har evnerne til at kende forskel på papir-ryttere og selvlærte eksperter. Og de må sørge for, at deres jobopslag tiltrækker kvalificerede folk (læs: Undgå at lade HR skrive deres indholdsløse pladder).

Hertil må HR-funktionen begynde at virke som tilsigtet: Som en enhed, der aktivt opdyrker og oparbejder en database over kvalificeret personel, man kan trække på, når der er behov. De fleste HR-funktioner fungerer alene som tilfældighedsbaseret spam-filter, der uden indsigt bortkaster ansøgninger og i øvrigt giver det indtryk, at "ansøgere kun er til besvær".

Kom ind i kampen, virksomheder! Stil krav, vis engagement, og drop HR-boblen!

  • 0
  • 0
Michael Nielsen

@Jacob Hansen

Ja drop HR boblen..

Jeg har ca 15 års erfaring med IT, programminger, og administration af systemer, jeg opdager at jeg bliver fravalgt af næsten alle virksomheder der benytter HR folk til hyring/fyring..

Men dem hvor hyring forgår af folk med teknisk indsigt, og viden om feldtet, har jeg for det meste få et spørgsmål "hvornår kan du starte".

Jeg har endnu ikke haft en eneste klage over den måde jeg arbejder på, eller mine evner, jeg er faktisk kun blevet rost.

Men iflg. HR folkene er jeg, ikke social nok, pædagogisk nok, så jeg bliver fravalgt på det grundlag - ja jeg har snakket med HR folkene for at finde ud af hvad problemet er.

Jeg kender en del andre i samme båd, man har fået ind i hovedet at alle IT folk skal være super sociale, og afhængige af alle andre.

Viser du nogen form for selvstændig tanke, kommer du ikke forbi HR folkene (overdrivelse for at fremme forståelsen).

  • 0
  • 0
Henrik Mikael Kristensen

Jeg er selv overbevist om, at jeg blev ansat i en større dansk virksomhed, da HR personen ikke var til stede til min jobsamtale lige præcis dén dag.

Et andet sted var jeg sammenlagt til samtale i en time hos HR personen og sølle 15 minutter med tekniske folk, og det altdominerende område var, hvorvidt jeg kunne omgås folk af andre kulturer, og hvilken religion jeg havde, og om jeg ville deltage i firmafesterne.

Så var det faktisk ligemeget, om jeg kunne noget, bare min tro eller andres tro var på en eller anden måde acceptabel. Jeg gik fra det møde med en fornemmelse af, at HR personen ikke ønskede at ansætte mig. Mit hår sad måske forkert.

Det er så immervæk snart 12 år siden (er selvstændig og glad idag), men jeg havde håbet, at HR boblen var bristet. Jeg er generelt alarmeret over, at man stiller større krav til folks påklædning, eller deres talent med karaokeudstyret ved firmafesten end deres egentlige evner.

  • 0
  • 0
Anne-Sofie Nielsen

God, optimeret, kode honoreres ikke i de fleste virksomheder. I stedet bliver udviklerne ofte målt på hvor meget kode, de har skrevet, ikke på hvor god koden er.

Det er måske i virkeligheden en vigtig lektion at sørge for til jobsamtaler at få spurgt ind til, om virksomheden benytter nogen metrikker a la "linjer kode" eller hvordan de bedømmer udviklere / hvad de lægger vægt på.
Ellers sidder man jo senere i saksen...

  • 0
  • 0
Carsten Sonne

Det er måske i virkeligheden en vigtig lektion at sørge for til jobsamtaler at få spurgt ind til, om virksomheden benytter nogen metrikker a la "linjer kode" eller hvordan de bedømmer udviklere / hvad de lægger vægt på.

Af andre områder, der kan spørges ind til kan nævnes:
* Konfigurationsstyring og versionshåndtering
* Kodekvalitet - F.eks. metrikker som cyklomatisk kompleksitet
* Udviklingsværktøjer - F.eks. IntelliJ, ReSharper eller SQL Compare
* Kodestandarder - F.eks. navngivning og politikker ifm. statisk kodeanalyse.
* Test - F.eks. kodedækning (code coverage).
* Opgavestyring - F.eks. TFS eller JIRA
* Modenheden - F.eks. CMMi
* Uddannelse - F.eks. kurser og konferencer

  • 0
  • 0
Lasse Reinholt

Et andet sted var jeg sammenlagt til samtale i en time hos HR personen og sølle 15 minutter med tekniske folk, og det altdominerende område var, hvorvidt jeg kunne omgås folk af andre kulturer, og hvilken religion jeg havde, og om jeg ville deltage i firmafesterne.

Nu findes der jo også mange mennesker, som fx ikke bryder sig om en bestemt kultur, eller som er virkelig asociale og ikke evner abstrahere fra det på arbejdet. Jeg har hørt rigtig mange historier om, hvordan det har ført til mobning og intriger og hvor ledelsen har så først har forsøgt at flytte folk rundt internt, men hele afdelingen alligevel er endt i kaos.

Den slags er meget dyrt.

Men hvis du selv er velfungerende, kan det selvfølgelig virke mærkeligt på dig at bruge så lang tid på det i en HR samtale.

  • 0
  • 0
Carsten Sonne

Den slags er meget dyrt.

At ledelse kræver uddannelse, mangler desværre anderkendelse. Dansker ledere er efter sigende nogle af de lavest (ledelsesmæssigt) uddannede.

Om ledelse i det danske uddannelsesvæsen og i den offetlige sektor:
http://www.dpu.dk/forskning/forskningsprogrammer/ol/ledelse/forskning/da...

Selv bestyrelsesmedlemmer kæmper med problemet:
http://www.erhvervsbladet.dk/ledelse/bestyrelsesmedlemmer-har-stort-beho...

Også politisk syntes af være et misforhold:
http://www.bt.dk/politik/borgmestre-er-bedre-uddannet-end-mfere

  • 0
  • 0
Frank Vilhelmsen

Sammen med ca. 250 andre gode folk var jeg på gotocph konferencen og så Dave Thomas "rant" over forskellige teknikaliteter, metodiker og menneskelige ressourcer.

Jeg havde også den store fornøjelse at tale en time med ham face2face, bla. om hans tanker omkring at skulle være en sur gammel mand for en dag. Der bliver omtalt at vi mangler gode kompetente udviklere men det er kun den halve sandhed.

Det Dave efterspørger er hele mennesker som kan indgå i sociale relationer og der er faglige dygtige. I Dave's termologi er menneskelige egenskaber som ydmyghed og det at kunne stole på helt nødvendige parameter. Dave efterspørge ligeledes flere naturlige ledertyper som er ærlige og kan bevæge sig på alle etager. Langt de fleste problemer i IT stammer fra dårlig ledelse der ofte slet ikke forstår hvad udvikling er.

Branchen har ikke brug for flere primadonnaer eller folk der ikke kan samarbejde mod et fælles mål.

Måske svare dette ikke på noget, men jeg havde bare lyst til dele :-)

  • 0
  • 0
Henrik Mikael Kristensen

Det er jo rigtigt nok, men jeg fornemmer, det er et helt forkert udgangspunkt at tage, at stille en psykologisk mur op, som man skal charmere sig forbi, som man derefter aldrig viser sig at få brug for igen i arbejdet.

Du kommer jo ikke foran en HR person, før du skal i skole, i gymnasiet på universitetet eller på en eller anden måde skal fungere i en social sammenhæng.

Hvilken type jobsamtale kommer HR personen til, når denne skal ansættes?

  • 0
  • 0
Jesper Louis Andersen

Af andre områder, der kan spørges ind til kan nævnes:

Lad mig gerne lige tilføje:

  • Byggemiljø. Kan hele molevitten bygges ved at skrive "make" et passende sted eller er der 200 små projekter hver for sig.
  • Continuous integration. Står der en række servere hvis eneste formål det er at bygge koden fra scratch og finde fejl i den hver gang det sendes et commit?
  • Deploymenttid. Hvor lang tid går der fra "Vi releaser" til det rent faktisk sker. Sekunder, Minutter, Timer, Dage, Uger, Måneder?
  • Open Source. Er noget af koden Open Source? Hvor meget er det?
  • Udviklingsmodel i forbindelse med Versionsstyring. Lever virksomheden stadig tilbage i 2003-2005 med Subversion og en trunk, eller er de kommet ind i fremtiden med enten mercurial, git eller bazaar? Hvad er life-cycle for en ny feature og hvordan bevæger den sig? Hvad med bug fixes?
  • QA. Er der en decideret QA-rolle tilknyttet projektet? Hvis nej, hvem har ansvaret? Har vedkommende veto i forhold til releases?

Som regel kan man med et par velvalgte spørgsmål omkring udviklingen ret hurtigt bestemme om virksomheden har styr på noget som helst, eller om det hele hænger i laser fordi man ikke gør noget ud af det. Et enkelt eller 3 mangler kan man som udvikler godt rette op på. Men hvis du skal starte fra bunden uden nogen support fra andre overhovedet, så er det som regel spild af tid.

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