mboost-dp1
Arbejdstid
Der lader til at være en generel virksomhedskultur i Asien hvor de ikke har fundet ud af at være effektive endnu. Og der er jo ikke ligefrem en overraskelse at de _stadigvæk_ ikke har fundet ud af hvordan man laver software i Asian.
Alt seriøst software bliver udviklet i vesten (Europa/USA). Asiatiske virksomheder som Samsung har grinagtig dårlig software kvalitet. Der skulle vestlige virksomheder som Google og Apple til at skabe smartphones. Ja, de kan lave hardwaren i Asien, men programmere den? Det kan de ikke.
Og måske arbejder de 12 timer om dagen, men de laver sandsynligvis mindre end hvad jeg kan nå på en formiddag.
Fordi de er ineffective, og (in min erfaring) generelt dovne. De sidder gerne og venter en fuld arbejdsdag på at få en ny kommando fra chefen. Ingen kommando? Så laver man jo bare ikke noget.
Alt seriøst software bliver udviklet i vesten (Europa/USA). Asiatiske virksomheder som Samsung har grinagtig dårlig software kvalitet. Der skulle vestlige virksomheder som Google og Apple til at skabe smartphones. Ja, de kan lave hardwaren i Asien, men programmere den? Det kan de ikke.
Og måske arbejder de 12 timer om dagen, men de laver sandsynligvis mindre end hvad jeg kan nå på en formiddag.
Fordi de er ineffective, og (in min erfaring) generelt dovne. De sidder gerne og venter en fuld arbejdsdag på at få en ny kommando fra chefen. Ingen kommando? Så laver man jo bare ikke noget.
#2
https://adtmag.com/articles/2019/04/10/alibaba-ope... har en historie om at Alibaba (med de 72 timers arbejdsuge) nu også ligesom alle de store amerikanske og europiske firmaer nu har deres egen OpenJDK distro.
Men den har også:
10000 udviklere, 1 milliard linier kode og din beskriverlse:
lyder som en slem kombination.
:-)
https://adtmag.com/articles/2019/04/10/alibaba-ope... har en historie om at Alibaba (med de 72 timers arbejdsuge) nu også ligesom alle de store amerikanske og europiske firmaer nu har deres egen OpenJDK distro.
Men den har også:
Most of the application running on the Alibaba platform are written in Java, which translates to more than 1 billion lines of code and the work of more than 10,000 Java developers, the company has said.
10000 udviklere, 1 milliard linier kode og din beskriverlse:
Claus Jørgensen (2) skrev:
...
Og der er jo ikke ligefrem en overraskelse at de _stadigvæk_ ikke har fundet ud af hvordan man laver software i Asian.
...
Asiatiske virksomheder ... har grinagtig dårlig software kvalitet.
...
lyder som en slem kombination.
:-)
#4
Jeg tror faktisk mere at skandinavien er undtagelsen. Det er ikke unormalt at have en 40+ timers arbejdsuge i f.eks. Tyskland
Derudover, så er det svært at sammenligne på tværs af kulture som Claus også skriver, "vi" kan ofte tænke selv, hvor mange andre kulturer venter på at få besked på hvad de skal lave. Igen, så skal man ikke langt væk.
Hvis jeg sammenligner bureaukratiet i Danmark og Tyskland er der en verden til forskel! Ting er mere "analoge" og skal igennem 117 instanser i Tyskland for selv de simpleste ting. Tager man brandvæsnet så er de i Tyskland 5 mand for hver 1 mand herhjemme, hvor 3 af dem har en eller anden lederrolle.
DK:
Holdleder:
4 røgdykkere
1 pumpepasser
Tyskland:
Gruppenführer:
2 Truppenführer
-- 2 røgdykkere for hver truppenführer
1 Artemluft kontrollant (har ikke mere end 10 mand "under" sig)
1 til at tage tid/noter (hvem går ind, og hvor lang tid)
Det kan ligne et kaos når vi er syd for grænsen for at hjælpe, men ordnung muss sein som de jo siger ;)
-- edit --
Ofte joker vi også med "alvorligheden" syd for grænsen. Det er ikke unormalt at en almindelig parcelhus brand har overskriften "Mehr als 100 feuerwehrleute im einsatz"
@Arne, lidt det samme som i større byer i US hvor man vælter rundt i køretøjer, da de hver er bemandet med 3-4 mand, og man ikke bruger mandskabsbiler eller lign. En 4-alarm vælter jo rundt i autosprøjter og drejestiger, hvor man ved samme størrelse herhjemme ville have 3-4 sprøjter og måske 2 drejestiger.
Jeg tror faktisk mere at skandinavien er undtagelsen. Det er ikke unormalt at have en 40+ timers arbejdsuge i f.eks. Tyskland
Derudover, så er det svært at sammenligne på tværs af kulture som Claus også skriver, "vi" kan ofte tænke selv, hvor mange andre kulturer venter på at få besked på hvad de skal lave. Igen, så skal man ikke langt væk.
Hvis jeg sammenligner bureaukratiet i Danmark og Tyskland er der en verden til forskel! Ting er mere "analoge" og skal igennem 117 instanser i Tyskland for selv de simpleste ting. Tager man brandvæsnet så er de i Tyskland 5 mand for hver 1 mand herhjemme, hvor 3 af dem har en eller anden lederrolle.
DK:
Holdleder:
4 røgdykkere
1 pumpepasser
Tyskland:
Gruppenführer:
2 Truppenführer
-- 2 røgdykkere for hver truppenführer
1 Artemluft kontrollant (har ikke mere end 10 mand "under" sig)
1 til at tage tid/noter (hvem går ind, og hvor lang tid)
Det kan ligne et kaos når vi er syd for grænsen for at hjælpe, men ordnung muss sein som de jo siger ;)
-- edit --
Ofte joker vi også med "alvorligheden" syd for grænsen. Det er ikke unormalt at en almindelig parcelhus brand har overskriften "Mehr als 100 feuerwehrleute im einsatz"
@Arne, lidt det samme som i større byer i US hvor man vælter rundt i køretøjer, da de hver er bemandet med 3-4 mand, og man ikke bruger mandskabsbiler eller lign. En 4-alarm vælter jo rundt i autosprøjter og drejestiger, hvor man ved samme størrelse herhjemme ville have 3-4 sprøjter og måske 2 drejestiger.
#5
10000 udviklere til en milliard linjer, det er jo kun 100k linjer per mand. Så ja, det lyder utrolig ineffektivt, specielt i et sprog som Java der er ret verbose.
Altså en simpel klasse er jo nemt 1000 linjer hvis vi inkludere interfacer (og måske endda header docs). Og så er det jo pludseligt kun 100 klasser i alt. Der er jo ingenting.
Så hvis de har brug for at arbejde 72 timer om ugen for at vedligeholde deres kode, så er kvaliteten nok ret svingende...
Jeg tvivler på at et firma i vesten ville ansætte 20000 udviklere til at vedligeholde en sølle milliard linjer kode.
10000 udviklere til en milliard linjer, det er jo kun 100k linjer per mand. Så ja, det lyder utrolig ineffektivt, specielt i et sprog som Java der er ret verbose.
Altså en simpel klasse er jo nemt 1000 linjer hvis vi inkludere interfacer (og måske endda header docs). Og så er det jo pludseligt kun 100 klasser i alt. Der er jo ingenting.
Så hvis de har brug for at arbejde 72 timer om ugen for at vedligeholde deres kode, så er kvaliteten nok ret svingende...
Jeg tvivler på at et firma i vesten ville ansætte 20000 udviklere til at vedligeholde en sølle milliard linjer kode.
Og forresten så arbejder jeg nok tættere på 50 timer end 40. Men der er med den forståelse hos mine chefer at min arbejdstid er meget fleksibel.
F.eks. så kan jeg tage i biografen for at se Avengers: Endgame kl. 13 på en eftermiddag (d. 24), eller tage til frisøren midt på dagen, sålænge jeg kan passe mit arbejde.
Og det synes jeg absolut det er værd at arbejde lidt over for at have den frihed.
F.eks. så kan jeg tage i biografen for at se Avengers: Endgame kl. 13 på en eftermiddag (d. 24), eller tage til frisøren midt på dagen, sålænge jeg kan passe mit arbejde.
Og det synes jeg absolut det er værd at arbejde lidt over for at have den frihed.
#8: jeg har samme frihed men jeg arbejder kun 32 timer om ugen
...jeg bliver faktisk ok glad for min arbejdsplads efterhånden, når jeg hører om ting som andre ser som et kæmpe plus som jeg kan tage for givet på min arbejdsplads?
til gengæld har jeg en mere "normal" løn sammenlignet med dem der har de høje lønninger i IT branchen
plus jeg er bare en helt almindelig tastatur jockey og jeg har mulighed for at skubbe opgaver videre hvis jeg syntes
...jeg bliver faktisk ok glad for min arbejdsplads efterhånden, når jeg hører om ting som andre ser som et kæmpe plus som jeg kan tage for givet på min arbejdsplads?
til gengæld har jeg en mere "normal" løn sammenlignet med dem der har de høje lønninger i IT branchen
plus jeg er bare en helt almindelig tastatur jockey og jeg har mulighed for at skubbe opgaver videre hvis jeg syntes
#9
Mange af mine kollagere arbejder tætter på præcist de nomimerede 40 timer. Jeg har bare ikke så meget andet at lave, så jeg glemmer normalt at gå hjem :P
Men det er altså de færreste jobs hvor man kan møde kl. 11 med tømmermænd, og alligevel tjene nok til at skulle betale topskat :P
Mange af mine kollagere arbejder tætter på præcist de nomimerede 40 timer. Jeg har bare ikke så meget andet at lave, så jeg glemmer normalt at gå hjem :P
Men det er altså de færreste jobs hvor man kan møde kl. 11 med tømmermænd, og alligevel tjene nok til at skulle betale topskat :P
#10: det kan der være noget om,
jeg har fx en kollega der typisk møder mellem kl 11 og 13...
dog tager han så også en tørn i weekenden i ny og næ.. men det er ikke noget han er pålagt...
blot at han cirka er her de antal timer han skal have i løbet af en måned...
men ja vi har en del frihed... også derfor jeg har tid til at hygge med jer herinde på newz i hverdagene
jeg har fx en kollega der typisk møder mellem kl 11 og 13...
dog tager han så også en tørn i weekenden i ny og næ.. men det er ikke noget han er pålagt...
blot at han cirka er her de antal timer han skal have i løbet af en måned...
men ja vi har en del frihed... også derfor jeg har tid til at hygge med jer herinde på newz i hverdagene
#10
Kender jeg alt for godt. Jeg havde en periode hvor chefen hjemmefra måtte ringe eller skrive "Hvornår kommer du hjem" - og ja, at møde kl 11 hvis det er det man vil er guld værd!
Kender jeg alt for godt. Jeg havde en periode hvor chefen hjemmefra måtte ringe eller skrive "Hvornår kommer du hjem" - og ja, at møde kl 11 hvis det er det man vil er guld værd!
Claus Jørgensen (7) skrev:
10000 udviklere til en milliard linjer, det er jo kun 100k linjer per mand. Så ja, det lyder utrolig ineffektivt, specielt i et sprog som Java der er ret verbose.
Jeg kan ikke følge dig.
En standard "produktivitet" (i anførselstegn fordi mindre kode faktisk er bedre end mere kode) er 150-450 linier per udvikler per måned. For store projekter.
Det er 1800-5400 linier per udvikler per år.
#13
Det er tal jeg vil kalde ekstreme ineffektivt. Hvis en udvikler kun laver 500 linjer nye eller ændrede kodelinjer på en måned, så er der noget galt med deres arbejde. Jeg har arbejdet på projekter hos Microsoft hvor folk var så ineffektive, og nej, de er ikke "mere systematiske", det er bare langsomme.
Og hvis man arbejder i en virksomhed med greenfield udvikling (som jeg gør), så er de 500 linjer et ugenligt minimum.
Det er et meget gammeldags synspunkt at mene at folk kan tillade sig at lave så få ændringer. Hvis der ikke bliver ændret noget, så er der jo tydeligvis ingen udvikling i virksomheden. Ja, gamle "stabile" produkter bliver ikke ændret meget, men hvem har brug for 100000 mand til at vedligeholde i hjemmeside og en mobil app + noget infrastruktur?
Det er tal jeg vil kalde ekstreme ineffektivt. Hvis en udvikler kun laver 500 linjer nye eller ændrede kodelinjer på en måned, så er der noget galt med deres arbejde. Jeg har arbejdet på projekter hos Microsoft hvor folk var så ineffektive, og nej, de er ikke "mere systematiske", det er bare langsomme.
Og hvis man arbejder i en virksomhed med greenfield udvikling (som jeg gør), så er de 500 linjer et ugenligt minimum.
Det er et meget gammeldags synspunkt at mene at folk kan tillade sig at lave så få ændringer. Hvis der ikke bliver ændret noget, så er der jo tydeligvis ingen udvikling i virksomheden. Ja, gamle "stabile" produkter bliver ikke ændret meget, men hvem har brug for 100000 mand til at vedligeholde i hjemmeside og en mobil app + noget infrastruktur?
Personligt har jeg lavet 7423 ændringer over 94 commits (Pull Requests) den sidste måned.
Dvs. jeg har lavet 16 måneders arbejde (a 450 ændringer per måned). Kan jeg holde fri de næste 15 måneder nu? Fordi jeg kan godt garantere at alt den kode jeg har skrevet er nødvendig.
Dvs. jeg har lavet 16 måneders arbejde (a 450 ændringer per måned). Kan jeg holde fri de næste 15 måneder nu? Fordi jeg kan godt garantere at alt den kode jeg har skrevet er nødvendig.
Claus Jørgensen (15) skrev:
Personligt har jeg lavet 7423 ændringer over 94 commits (Pull Requests) den sidste måned.
7423 ændringer per måned ved 21 dage af 8 timer i en måned er ca. 1m20s per ændring.
Det er ikke typisk for store projekter.
Claus Jørgensen (15) skrev:
Dvs. jeg har lavet 16 måneders arbejde (a 450 ændringer per måned). Kan jeg holde fri de næste 15 måneder nu?
Det ville din chef nok blive ked af.
:-)
Claus Jørgensen (17) skrev:#16
Men jeg gætter på at du ikke laver 5-10 nye skærmbilleder hver måned. Og der er jo stadigvæk 4-8 gange så meget som arne_v foreslog.
Det har du ret i
Tja jeg laver nok måske 2 nye skærmbilleder hver måned
Jeg tror det er stor spredning i hvor travlt folk har i deres jobs
#18
Hvis du vedligeholder noget 20 år gammel kode laver du nok ikke 300 linje ændringer om dagen. Hvis du arbejder på et nyt projekt, så er det altså helt normalt at skrive 300 nye linjer hver dag. Specielt hvis du arbejder med UI, hvor kode kan være meget verbose.
Og hvis jeg tilføjer eller ændre 1 parameter til en eksisterende method så kan det jo sagtens føre til 10-20-30 linjeændringer på en brøkdel af et sekund -- eller sådan burde være det, Xcode har ikke refactoring options til Swift :(
Jeg er 100% sikker på at hvis du selv kiggede dine commit logs igennem, ville du finde ud af at du laver meget mere end 150 ændringer om måneden.
7423 ændringer per måned ved 21 dage af 8 timer i en måned er ca. 1m20s per ændring.
Det er ikke typisk for store projekter.Jeg er uenig. Jeg vil faktisk sige det modsatte. Det er normalt i begyndelsen af store projekter, men ikke i slutningen.
Hvis du vedligeholder noget 20 år gammel kode laver du nok ikke 300 linje ændringer om dagen. Hvis du arbejder på et nyt projekt, så er det altså helt normalt at skrive 300 nye linjer hver dag. Specielt hvis du arbejder med UI, hvor kode kan være meget verbose.
Og hvis jeg tilføjer eller ændre 1 parameter til en eksisterende method så kan det jo sagtens føre til 10-20-30 linjeændringer på en brøkdel af et sekund -- eller sådan burde være det, Xcode har ikke refactoring options til Swift :(
Jeg er 100% sikker på at hvis du selv kiggede dine commit logs igennem, ville du finde ud af at du laver meget mere end 150 ændringer om måneden.
#SLOC/time
Der er nogen forskel på:
* evner hos udviklere
* hvor travlt udviklere har
Men den største forskel er typen af kode der skal skrives.
En-mands projekter kan være meget produktive.
Relativ simpel kode indenfor eksisterende arkitektur/design rammer kan resultere i meget høj produktivitet.
Men store projekter med store teams er noget helt andet.
Det at skrive de X liniers kode er en meget lille del af arbejdet.
Forstå krav, forstå arkitektur, POC af forskellige muligheder, design, dokumentation af design, API og protokoller, dokumentation af API og protokoller, unit tests, support af QA, support af AT fylder meget.
Der er nogen forskel på:
* evner hos udviklere
* hvor travlt udviklere har
Men den største forskel er typen af kode der skal skrives.
En-mands projekter kan være meget produktive.
Relativ simpel kode indenfor eksisterende arkitektur/design rammer kan resultere i meget høj produktivitet.
Men store projekter med store teams er noget helt andet.
Det at skrive de X liniers kode er en meget lille del af arbejdet.
Forstå krav, forstå arkitektur, POC af forskellige muligheder, design, dokumentation af design, API og protokoller, dokumentation af API og protokoller, unit tests, support af QA, support af AT fylder meget.
#19
Men jeg laver også mange ændringer fordi at jeg ser alting. Finder jeg en fejl mens jeg laver noget andet? PR med fejlretning, og så tilbage til fokus på hvad jeg nu ellers var i gang med.
Og typisk laver man lidt boy-scout rule (ryd op efter dig selv og alle andre), så nogle gange bliver det til et ekstra PR eller 2 med cleanup.
Plus, hvis man faktisk er en af dem som skriver Unit Tests til sin kode, så er argumenter om 150 linjer jo endnu værre. Fordi at 150 linjer kode+test burde svare til omkring 25-50 linjer kode, og 100-125 linjer test.
Tests er næsten altid en faktor to i numre af linjer kode skreven.
Og helt ærlig, hvis en senior udvikler kun skriver 25 linjer kode på en 160 TIMER, så tror jeg der er noget helt helt galt med deres produktivitet.
Men jeg laver også mange ændringer fordi at jeg ser alting. Finder jeg en fejl mens jeg laver noget andet? PR med fejlretning, og så tilbage til fokus på hvad jeg nu ellers var i gang med.
Og typisk laver man lidt boy-scout rule (ryd op efter dig selv og alle andre), så nogle gange bliver det til et ekstra PR eller 2 med cleanup.
Plus, hvis man faktisk er en af dem som skriver Unit Tests til sin kode, så er argumenter om 150 linjer jo endnu værre. Fordi at 150 linjer kode+test burde svare til omkring 25-50 linjer kode, og 100-125 linjer test.
Tests er næsten altid en faktor to i numre af linjer kode skreven.
Og helt ærlig, hvis en senior udvikler kun skriver 25 linjer kode på en 160 TIMER, så tror jeg der er noget helt helt galt med deres produktivitet.
#21
Igen, uenig. Medmindre du ikke mener at en mobil udgave af Skype tæller som et "stort" projekt.
Umiddelbart så er dine argumenter for ikke at skrive kode at folk har møder. Jeg synes ikke man skal argumentere for at være produktiv som programmør hvis man bruger 38 af sine 40 timer om ugen i møder.
Igen, uenig. Medmindre du ikke mener at en mobil udgave af Skype tæller som et "stort" projekt.
Relativ simpel kode indenfor eksisterende arkitektur/design rammer kan resultere i meget høj produktivitet.Hvilket sagtens kan lade sig gøre i store projekter, som f.eks. Skype.
Forstå kravPO job, ikke udvikler job.
forstå arkitekturAgile?
POC af forskellige mulighederAgile?
designAgile?
dokumentation af designDer er der altså meget få der gør i dag. Formelt design er død, og erstattet af agile udvikling.
API og protokollerIgen, agil?
unit testsTæller også som kode...
support af QA, support af AT fylder meget.Jeg arbejder direkte med vores QA til dagligt. Konstant i kontakt, enten via. Slack eller vi snakker i person.
Umiddelbart så er dine argumenter for ikke at skrive kode at folk har møder. Jeg synes ikke man skal argumentere for at være produktiv som programmør hvis man bruger 38 af sine 40 timer om ugen i møder.
Og hvis koden ikke bliver skrevet, så er der intet produkt. Så i sidste ende er det at skrive koden jo den vigtige del af produktet.
Det er lidt ligesom at sige at der er mere til at bygge et hus end at lægge mursten på mursten. Det er rigtigt nok, men størstedelen af arbejdet i hus er altså at bygge det - ikke at snakke om designet, ikke at tegne det, ikke at lave CAD tegninger for det sluttelige arbejde - men at faktisk bygge det.
Og software udvikles så meget mere effektiv når man arbejder agilt. Fordi modsat når du bygger et hus, så koster det ikke rigtig noget at bygge en del af et program. Men hvis du skal rive en væg ned i huset, så bliver det dyrt.
Det er lidt ligesom at sige at der er mere til at bygge et hus end at lægge mursten på mursten. Det er rigtigt nok, men størstedelen af arbejdet i hus er altså at bygge det - ikke at snakke om designet, ikke at tegne det, ikke at lave CAD tegninger for det sluttelige arbejde - men at faktisk bygge det.
Og software udvikles så meget mere effektiv når man arbejder agilt. Fordi modsat når du bygger et hus, så koster det ikke rigtig noget at bygge en del af et program. Men hvis du skal rive en væg ned i huset, så bliver det dyrt.
Claus Jørgensen (27) skrev:#24
Code Reviews og Unit Tests er mutually exclusive. Hvis du ikke har nogen tests, hvordan ved du så om din kode er korrekt?
Jeg tester en funktion efter den er lavet og slutter med big bang at den samlede funktionalitet
Har virket fint indtil videre
Men det er noget helt andet end dengang jeg arbejde med software til vindmøller
Der var seer strenge krav til test
Claus Jørgensen (23) skrev:Forstå kravPO job, ikke udvikler job.
Udviklerne er nødt til at forstå hvad den kode de skriver skal gøre for at de kan skrive koden.
Claus Jørgensen (23) skrev:forstå arkitekturAgile?POC af forskellige mulighederAgile?designAgile?
Det er en gængs misforståelse at agile betyder ingen upfront arkitektur eller design.
Men det er en misforståelse.
Agile betyder det mindst mulige upfront arkitektur og design.
Både Martin Fowler og Scott Ambler har skrevet en del omkring emnet.
For små projekter er det mindst mulige ofte meget lidt.
Men taler vi 1 MLOC eller 10 MLOC projekter, så er er det en del.
Claus Jørgensen (23) skrev:dokumentation af designDer er der altså meget få der gør i dag. Formelt design er død, og erstattet af agile udvikling.
Det er ikke specielt agilt at overlade en katastrofe til maintenance udviklerne.
En lille kode base kan man læse sig igennem og forstå (specielt hvis der er nogle gode relevante kommentarer i koden).
Men at forsøge at forstå 1 MLOC ved at læse kode p.g.a. manglende design dokumenter er håbløst.
Claus Jørgensen (23) skrev:API og protokollerIgen, agil?
Agil betyder at:
* de ikke nødvendigvis vedtages upfront
* de forventes at ændre sig over tid
Men de skal stadig vedtages og dokumenteres.
Ellers er der jo ingen ting som kan snakke sammen.
Claus Jørgensen (23) skrev:unit testsTæller også som kode...
Det er kode som skal skrives.
Men man tæller det normalt ikke med når man opgør projektstørrelser og produktivitet.
CBM (24) skrev:
Isf unit test så bruger jeg peer review
Unit test og peer review løser faktisk ret forskellige opgaver.
Unit tests er typisk ret primitive test men skal helst dække hele koden.
Peer review fokuserer typisk på kritisk kode (enkelte steder reviewer alt men det er dyrt) men kan til gengæld gå i dybden.
Unit tests er gode til at teste f.eks. beregninger.
Men skal man checke om en kode har sikkerhedshuller er peer review (gerne suppleret med et code analysis tool!!) bedre.
#29
Det virker underligt at undlade tests under produktivitet, specielt hvis man faktisk tager tests seriøst.
Mht. design. Ja, hvis du skal designe et helt nyt operativsystem eller lign. fra bunden så skal der jo noget design til. Men du kan jo ikke argumentere for at at lave designet tager 90% af udviklernes tid _altid_.
Hvis der allerede er design og arkitektur på plads, så kan udviklerne bruge 90% af deres tid på at kode.
Jeg køber den ikke. Selv nye projekter hos Microsoft hvor vi endte op med 100mio MLOC og 1000'ish udviklere (backend+frontend combined) brugte de fleste af udviklerne størstedelen af deres tid på at skrive kode (og tests). Ikke på at holde møder.
Det virker underligt at undlade tests under produktivitet, specielt hvis man faktisk tager tests seriøst.
Mht. design. Ja, hvis du skal designe et helt nyt operativsystem eller lign. fra bunden så skal der jo noget design til. Men du kan jo ikke argumentere for at at lave designet tager 90% af udviklernes tid _altid_.
Hvis der allerede er design og arkitektur på plads, så kan udviklerne bruge 90% af deres tid på at kode.
Jeg køber den ikke. Selv nye projekter hos Microsoft hvor vi endte op med 100mio MLOC og 1000'ish udviklere (backend+frontend combined) brugte de fleste af udviklerne størstedelen af deres tid på at skrive kode (og tests). Ikke på at holde møder.
#31
Ifølge internet sladder brugte Microsoft 2000 udviklere over 5 år på Windows Vista som var 10 millioner linier kode større end Windows XP.
Det er 83 linier per måned per udvikler.
De har dog sikkert også rettet en del eksisterende kode. Så hvis vi antager at de har rettet 10 millioner linier eksisterende kode så når vi op på 166 linier per måned per udvikler.
Og det er ingen hemmelighed at Windows Vista projektet havde store problemer. Så andre projekter ligger formentligt noget højere.
Men ...
Ifølge internet sladder brugte Microsoft 2000 udviklere over 5 år på Windows Vista som var 10 millioner linier kode større end Windows XP.
Det er 83 linier per måned per udvikler.
De har dog sikkert også rettet en del eksisterende kode. Så hvis vi antager at de har rettet 10 millioner linier eksisterende kode så når vi op på 166 linier per måned per udvikler.
Og det er ingen hemmelighed at Windows Vista projektet havde store problemer. Så andre projekter ligger formentligt noget højere.
Men ...
Claus Jørgensen (26) skrev:
Og hvis koden ikke bliver skrevet, så er der intet produkt. Så i sidste ende er det at skrive koden jo den vigtige del af produktet.
Tech lead til udviklere på projekt i 2003: det er acceptabel hvis jeres kode ikke er færdig til tiden i forhold til projektplanen, men det er ikke acceptabelt hvis unit tests ikke er færdige.
Hmmm.
Claus Jørgensen (26) skrev:
Det er lidt ligesom at sige at der er mere til at bygge et hus end at lægge mursten på mursten. Det er rigtigt nok, men størstedelen af arbejdet i hus er altså at bygge det - ikke at snakke om designet, ikke at tegne det, ikke at lave CAD tegninger for det sluttelige arbejde - men at faktisk bygge det.
Det er almindeligt at sammenligne software med fysisk byggeri.
Men:
* udvikling af software er normalt meget mere komplekst end byggeri
* forskellen mellem forskellige software projekter er langt større end forskellen mellem bygge projekter
* byggeri er et langt mere modent område hvor teknikker og værktøjer typisk er årtier eller århundreder gamle
Jeg tror ikke at det er realistisk at vi kan lave software ligesom man bygger parcelhuse.
#32
Ok, jeg kan forklare dig hvorfor de tal er forkerte. Microsoft, specielt omkring XP/Vista tiden, inkluderede alle der ikke var testere under udviklere. Dvs. product managers, program managers, leads, etc. var alle udviklere.
Jeg har ikke arbejdet på Windows, men jeg har arbejdet på Windows Phone. Her er hvordan de strukturerede det:
Et typisk hold af 5 person er der kun 4 der koder (formelt). En af de 4 er så principal/arkitekt og bruger det meste af sin tid på dokumentation/mentoring/møder etc. Microsoft havde en meget formel rang orden til møder -- jo mere senior, jo flere møder.
Så tilbage er der 3 udviklere, typisk 1 senior og 1-2 mid-level eller junior udviklere. Selve koden der bliver checket ind vil nok være cirka. 150 linjer per måned, men det tæller ikke alt deres test kode med (typisk en faktor 3-4).
Men grunden til at det ikke var mere kode var en check-in process der tog dagevis, en formel test fase der ikke tillod folk at arbejde på mere end én ting af gangen. En build-process der tog 6 timer minimum (full rebuild tættere på 18 timer). Et VCS system der frøs filer som folk ikke kunne arbejde på dem i parallel (tiltrods for at filerne var 1000+linjer)
Så rigtig mange udviklere brugte sindsyg lang tid på process og test -- og ofte trillede tommelfingere flere dage af gangen mens de ventede svar fra test (og testerne sad fysisk i en anden bygning -- de snakkede aldrig sammen).
Så ja, de skrev ikke meget kode. Fordi at processerne og værktøjerne var sindsyge ineffektive.
Ok, jeg kan forklare dig hvorfor de tal er forkerte. Microsoft, specielt omkring XP/Vista tiden, inkluderede alle der ikke var testere under udviklere. Dvs. product managers, program managers, leads, etc. var alle udviklere.
Jeg har ikke arbejdet på Windows, men jeg har arbejdet på Windows Phone. Her er hvordan de strukturerede det:
Et typisk hold af 5 person er der kun 4 der koder (formelt). En af de 4 er så principal/arkitekt og bruger det meste af sin tid på dokumentation/mentoring/møder etc. Microsoft havde en meget formel rang orden til møder -- jo mere senior, jo flere møder.
Så tilbage er der 3 udviklere, typisk 1 senior og 1-2 mid-level eller junior udviklere. Selve koden der bliver checket ind vil nok være cirka. 150 linjer per måned, men det tæller ikke alt deres test kode med (typisk en faktor 3-4).
Men grunden til at det ikke var mere kode var en check-in process der tog dagevis, en formel test fase der ikke tillod folk at arbejde på mere end én ting af gangen. En build-process der tog 6 timer minimum (full rebuild tættere på 18 timer). Et VCS system der frøs filer som folk ikke kunne arbejde på dem i parallel (tiltrods for at filerne var 1000+linjer)
Så rigtig mange udviklere brugte sindsyg lang tid på process og test -- og ofte trillede tommelfingere flere dage af gangen mens de ventede svar fra test (og testerne sad fysisk i en anden bygning -- de snakkede aldrig sammen).
Så ja, de skrev ikke meget kode. Fordi at processerne og værktøjerne var sindsyge ineffektive.
#33
Hah, ja. I 2003 har det absolut været sådan.
Men i 2018? Microsoft Teams havde et krav om 80%+ coverage (iirc) for at et PR kunne blive merged. Systematiseret check, som krævede en chef-chef til at override.
* udvikling af mobile apps eller web apps er ikke særlig komplekst
* mobile apps eller web apps er typisk meget ens i struktur
* mobile og web apps bygger på solide de-facto teknikker i industrien
Hvis man skal lave en app på iOS eller Android i dag er det super klart hvordan man vil bygge en grundlæggende arkitektur. Hvis man skal bygge en web app i .NET, Rails, Node, etc. er der super klare arkitekturer/frameworks der definere det hele for en.
Server-side arkitektur er mere tricky, men selv der er der rimelig klare retningslinjer nu om dage, hvis man følger industristandarderne nogenlunde.
Så jeg synes det er forkert at sige at software i dag ikke bygger på solide teknikker og værktøjer.
Hah, ja. I 2003 har det absolut været sådan.
Men i 2018? Microsoft Teams havde et krav om 80%+ coverage (iirc) for at et PR kunne blive merged. Systematiseret check, som krævede en chef-chef til at override.
* udvikling af software er normalt meget mere komplekst end byggeri
* forskellen mellem forskellige software projekter er langt større end forskellen mellem bygge projekter
* byggeri er et langt mere modent område hvor teknikker og værktøjer typisk er årtier eller århundreder gamle
* udvikling af mobile apps eller web apps er ikke særlig komplekst
* mobile apps eller web apps er typisk meget ens i struktur
* mobile og web apps bygger på solide de-facto teknikker i industrien
Hvis man skal lave en app på iOS eller Android i dag er det super klart hvordan man vil bygge en grundlæggende arkitektur. Hvis man skal bygge en web app i .NET, Rails, Node, etc. er der super klare arkitekturer/frameworks der definere det hele for en.
Server-side arkitektur er mere tricky, men selv der er der rimelig klare retningslinjer nu om dage, hvis man følger industristandarderne nogenlunde.
Så jeg synes det er forkert at sige at software i dag ikke bygger på solide teknikker og værktøjer.
arne_v (30) skrev:CBM (24) skrev:
Isf unit test så bruger jeg peer review
Unit test og peer review løser faktisk ret forskellige opgaver.
Unit tests er typisk ret primitive test men skal helst dække hele koden.
Peer review fokuserer typisk på kritisk kode (enkelte steder reviewer alt men det er dyrt) men kan til gengæld gå i dybden.
Unit tests er gode til at teste f.eks. beregninger.
Men skal man checke om en kode har sikkerhedshuller er peer review (gerne suppleret med et code analysis tool!!) bedre.
True
Men jeg skriver ikke kritisk software i min aktuelle stilling
Jeg tester lidt mens jeg udvikler og så tester funktionen af til slut
Det er gået helt fint de sidste 5 år
Er der endelig en ting der glipper så bliver det altid fundet i review som også fungerer som en slags QA
Den generelle holdning til test hvor jeg er, er lidt lala
#35
Op til en vis størrelse/kompleksitet er det relativt nemt.
Men når man går over den størrelse/kompleksitet, så går det ofte galt.
Projekter går over budget, bliver forsinket eller bliver skrottet fordi de ikke har en chance for at komme til at virke.
Systemer bliver hacket p.g.a. sikkerhedshuller, har en elendig UX eller går ned ved høj belastning.
Byggeprojekter går sommetider over budget eller blive forsinket. Men det er er ekstremt sjældent at byggeprojekter opgives eller at det hele styrter sammen.
Er det fordi murerer er mere intelligent og bedre uddannede end programmører?
Jeg tror det ikke.
Jeg tror at problemerne er mere vanskelige i systemudvikling end i husbygning.
Vi kender alle historierne fra store danske offentlige IT projekter.
Men den slags sker også i udlandet.
healthcare.gov (den føderale sygeforsikrings-børs som var en del af ObamaCare) i USA skulle have kostet 94 M$ men endte med alt inklusive at koste 1.7 B$.
Op til en vis størrelse/kompleksitet er det relativt nemt.
Men når man går over den størrelse/kompleksitet, så går det ofte galt.
Projekter går over budget, bliver forsinket eller bliver skrottet fordi de ikke har en chance for at komme til at virke.
Systemer bliver hacket p.g.a. sikkerhedshuller, har en elendig UX eller går ned ved høj belastning.
Byggeprojekter går sommetider over budget eller blive forsinket. Men det er er ekstremt sjældent at byggeprojekter opgives eller at det hele styrter sammen.
Er det fordi murerer er mere intelligent og bedre uddannede end programmører?
Jeg tror det ikke.
Jeg tror at problemerne er mere vanskelige i systemudvikling end i husbygning.
Vi kender alle historierne fra store danske offentlige IT projekter.
Men den slags sker også i udlandet.
healthcare.gov (den føderale sygeforsikrings-børs som var en del af ObamaCare) i USA skulle have kostet 94 M$ men endte med alt inklusive at koste 1.7 B$.
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
- ⟨
- Tagwall
Gå til bund