mboost-dp1
En som ikke er vildt begejstret for pair programming
Bla bla bla, han kan ikke lide det, fordi han var uenig med sin partner, og ikke selvsikker nok til at programmere mens andre så på..
Moving on ^^
Moving on ^^
Jeg kan godt se hvad han mener med at det er svært at overbevise sin makker om at det skal laves "rigtigt" når han mener at det bare skal laves hurtigt. Det har jeg selv haft problemer med når jeg har arbejdet sammen med andre.
Jeg synes dog efterhånden at jeg er blevet rimelig god til at forklare hvorfor det skal laves ordentligt og hvad problemerne ville være i bare at lave det på den hurtige måde, og det plejer folk at lytte til.
Jeg synes dog efterhånden at jeg er blevet rimelig god til at forklare hvorfor det skal laves ordentligt og hvad problemerne ville være i bare at lave det på den hurtige måde, og det plejer folk at lytte til.
http://mwilden.blogspot.com/2009/11/why-i-dont-like-pair-programming-and.html skrev:First, the good side. I think the production of good code with two people working together is greater than with two people working apart. It's not hugely greater. The pair has to generate twice as much code as one programmer just to break even. That's helped by the fact that pairing forces you to spend the day programming instead of goofing off.
Så vi ligestiller altså kvantitet og kvallitet her? Så jo, ud fra den antagelse så skal udviklere der parprogrammerer arbejde hurtigt for at levere noget der er tilsvarende hvis de sad hver for sig.
Intet nyt her..
Ingen arbejder ens.
Han har tydeligvis et problem med at få sit budskab igennem hos en kollega, og han har derfor gjort det eneste rigtige for ham:
Fundet en arbejdsplads hvor han kan få lov at arbejde som han arbejder bedst..
Det er der vel ingen problemer i?
Der findes jo ingen gylden løsning inden for system-udvikling..
Ingen arbejder ens.
Han har tydeligvis et problem med at få sit budskab igennem hos en kollega, og han har derfor gjort det eneste rigtige for ham:
Fundet en arbejdsplads hvor han kan få lov at arbejde som han arbejder bedst..
Det er der vel ingen problemer i?
Der findes jo ingen gylden løsning inden for system-udvikling..
Interassant artikel.
Pair programming er også et aspect af Extreme Programming som jeg heller ikke bryder mig om. Jeg har prøvet det et par gange, men problemet er at medmindre du har en som er på samme niveau som dig selv, vil det bare ikke virke.
Plus det er absolut ødelæggende for innovationen. Man kan ikke skrive hurtige mock-ups for at teste ens egen viden, fordi at man så skal forklare det til sin partner.
Og så videre...
At et arbejdsplads forlanger 100% pair-programming og følger XPs principper til fulde synes jeg er fjollet.
Og så virker SCRUM generelt mere fornuftigt til en normal arbejdsplads ;-)
Pair programming er også et aspect af Extreme Programming som jeg heller ikke bryder mig om. Jeg har prøvet det et par gange, men problemet er at medmindre du har en som er på samme niveau som dig selv, vil det bare ikke virke.
Plus det er absolut ødelæggende for innovationen. Man kan ikke skrive hurtige mock-ups for at teste ens egen viden, fordi at man så skal forklare det til sin partner.
Og så videre...
At et arbejdsplads forlanger 100% pair-programming og følger XPs principper til fulde synes jeg er fjollet.
Og så virker SCRUM generelt mere fornuftigt til en normal arbejdsplads ;-)
Medmindre du arbejder på noget super komplekst, som algoritmer, eller et større API design (ala. .NET eller Java), så er det jo netop vigtigt at der rent faktisk bliver produceret noget.milandt (4) skrev:Så vi ligestiller altså kvantitet og kvallitet her? Så jo, ud fra den antagelse så skal udviklere der parprogrammerer arbejde hurtigt for at levere noget der er tilsvarende hvis de sad hver for sig.
Umiddelbart hvis man kigger på Pivotal Labs vil jeg gætte på de har arbejdet med webudvikling og nok med Ruby on Rails.
Par-programmering til webudvikling er imo. spild af tid, og du vil slet ikke få produceret nok. Det er alt for mange resourcer at bruge på en lang række ting som er mere simpelt arbejde.
Som man kan læse sprang de også en lang række koncepter og tests over netop fordi at de skulle nå at være produktive samtidige med at de brugte par-programmering.
Jeg tror ikke rigtigt at virksomheden har haft nok forståelse af metodevalget i denne her situation.
Der er jo netop en række problemer som du også selv kan komme ud for hvis du havner i en virksomhed der benytter agile metoder, og har valgt XP som deres metode-praktik.tazimn (5) skrev:Det er der vel ingen problemer i?
Der findes jo ingen gylden løsning inden for system-udvikling..
Heldigvis er par-programmering noget man tit skærer væk fra XP, og så bare benytter sig af XPs kerne, altså TDD, User Stories og Continuous Integration.
Virksomheden havde fået mere ud af at givet ham valget, frem for at skulle skifte arbejdsplads. Og med den række fejl de laver i koden, ville en opdeling af opgaverne, eller mere review af andres kode, nok have været mere ideelt.
#8
Jeg har ikke selv prøvet pair-programming, men skal have afprøvet det i næste projekt.. Det giver selvfølgelig ikke grobund for ordentlig erfaring at have prøvet det i skolen, men jeg regner da med at det giver et indblik i om det er noget for mig..
Hvad jeg i forvejen ikke mener at det er..
Jeg har brug for fordybelse og "kunstner-pauser" når jeg skal være kreativ.. og med pres fra en partner som synes han har løsningen og med en deadline over hovedet, tror jeg at innovationen går tabt..
Jeg har ikke selv prøvet pair-programming, men skal have afprøvet det i næste projekt.. Det giver selvfølgelig ikke grobund for ordentlig erfaring at have prøvet det i skolen, men jeg regner da med at det giver et indblik i om det er noget for mig..
Hvad jeg i forvejen ikke mener at det er..
Jeg har brug for fordybelse og "kunstner-pauser" når jeg skal være kreativ.. og med pres fra en partner som synes han har løsningen og med en deadline over hovedet, tror jeg at innovationen går tabt..
par-programmering leverer væsentligt færre fejl og dermed færre omkostninger forbundet med rettelse senere i forløbet.Windcape (7) skrev:Medmindre du arbejder på noget super komplekst, som algoritmer, eller et større API design (ala. .NET eller Java), så er det jo netop vigtigt at der rent faktisk bliver produceret noget.
Nu ved jeg godt at jeg tager det ud af konteksten med web-programmering, men meningen er jo heller ikke at benytte par-programmering til simple rutine opgaver.Windcape (7) skrev:Det er alt for mange resourcer at bruge på en lang række ting som er mere simpelt arbejde.
I bund og grund er vi enige, simple opgaver kan gøres for sig selv, mens komplekse kan der med fordel anvendes parprogrammering. Det er bare ikke alle som kan det.
Hvis man kan finde to personer som er perfekt afbalancerede.Cloud02 (10) skrev:I bund og grund er vi enige, simple opgaver kan gøres for sig selv, mens komplekse kan der med fordel anvendes parprogrammering.
Sandsynligvis er det bedre at arbejde i teams, måske samme kontor, og så have en del ping/pong for at lave review på hinandens arbejde.
Det har jeg gjort meget i vores studieprojekter.
Hmm, jeg synes nu at det lyder som om, at arbejdsformen i virkeligheden var en sund ting for den pågældende person. Han bliver reduceret i hans tendens, til at lave afstikkere og han vil over tid blive mere selvsikker/"stil-sikker".
Det illustrerer faktisk meget godt nogle af de ting, som XP forsøger at opnå, så +1 til modellen. (Integritet for koden og fokuseret arbejde efter målet.)
Tilgengæld synes jeg ikke at XP og pair programmering er løsningen. Jeg vil hellere tildele "mentore" til svage programmøre eller lade "scrum"-møderne om at uddele passende opgaver til de pågældende.
Det illustrerer faktisk meget godt nogle af de ting, som XP forsøger at opnå, så +1 til modellen. (Integritet for koden og fokuseret arbejde efter målet.)
Tilgengæld synes jeg ikke at XP og pair programmering er løsningen. Jeg vil hellere tildele "mentore" til svage programmøre eller lade "scrum"-møderne om at uddele passende opgaver til de pågældende.
Faergemeister (2) skrev:Bla bla bla, han kan ikke lide det, fordi han var uenig med sin partner, og ikke selvsikker nok til at programmere mens andre så på..
Emil Melgaard (3) skrev:Jeg kan godt se hvad han mener med at det er svært at overbevise sin makker om at det skal laves "rigtigt" når han mener at det bare skal laves hurtigt. Det har jeg selv haft problemer med når jeg har arbejdet sammen med andre.
Jeg synes dog efterhånden at jeg er blevet rimelig god til at forklare hvorfor det skal laves ordentligt og hvad problemerne ville være i bare at lave det på den hurtige måde, og det plejer folk at lytte til.
Det er jo en svaghed ved en udviklingsmetode, hvis der er en forholdsvis stor andel udviklere som ikke fungerer med den.
Gode udviklingsprocesser er noget som reducerer afhængigheden af specifikke udviklere.
Windcape (7) skrev:Medmindre du arbejder på noget super komplekst, som algoritmer, eller et større API design (ala. .NET eller Java), så er det jo netop vigtigt at der rent faktisk bliver produceret noget.
Windcape (7) skrev:Par-programmering til webudvikling er imo. spild af tid, og du vil slet ikke få produceret nok. Det er alt for mange resourcer at bruge på en lang række ting som er mere simpelt arbejde.
Hvis vi antager at 5% af en udviklers tid bruges på at skrive kode, så er overhead ikke så stort.
Cloud02 (10) skrev:Nu ved jeg godt at jeg tager det ud af konteksten med web-programmering, men meningen er jo heller ikke at benytte par-programmering til simple rutine opgaver.
I bund og grund er vi enige, simple opgaver kan gøres for sig selv, mens komplekse kan der med fordel anvendes parprogrammering. Det er bare ikke alle som kan det.
En pragmatisk tilgang er næsten altid godt.
I web udvikling skal der laves en stor mængde "slave kode".arne_v (15) skrev:Hvis vi antager at 5% af en udviklers tid bruges på at skrive kode, så er overhead ikke så stort.
Det er et af det få områder hvor man kommer over 50% programmering!
(Medmindre man sidder på nogle komplekse interne systemer, men det kendetegner ikke typisk webudvikling, og slet ikke RoR)
Windcape (17) skrev:I web udvikling skal der laves en stor mængde "slave kode".
Hvis et web projekt udvikles efter "SPU håndbogen", så er "Implementation" tildelt 30%. Af disse vil hoveddelen bestå i at læse og tolke design-dokumenter. %5 til kode, er et godt bud til et sådan projekt, uanset platform.
Agile/scrum-projekter vil sandsynligvis indeholde en større "kode-procent". Men igen er det uafhængigt af platform.
RoR er så vidt jeg husker, et forsøg på at indføre RAD-udvikling til web. Men man behøver nu ikke at udvikle efter "XP" på RoR. (XP kom frem sammen med RAD-værktøjerne.)
RoR er nu listet under Web Based Rapid Application Development Tools på Wikipedia's liste over RAD-værktøjer.
Som ligeledes postulerer:
Men jo, jeg vil da godt give dig ret i, at RAD-værktøjer som regel bør være noget med GUI/IDE'er.
PS. Codegear (Delphi) har også lavet en IDE til RoR.
Som ligeledes postulerer:
It is intended to be used with an Agile development methodology that is used by web developers for rapid development
Men jo, jeg vil da godt give dig ret i, at RAD-værktøjer som regel bør være noget med GUI/IDE'er.
PS. Codegear (Delphi) har også lavet en IDE til RoR.
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