Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Extreme Programming Frightens This Perl Programmer

by sierrathedog04 (Hermit)
on Feb 18, 2001 at 17:56 UTC ( [id://59247]=perlmeditation: print w/replies, xml ) Need Help??

XP is Extreme Programming. A commentator on amazon.com says of XP that
Code review takes the form of pair programming. That is, two programmers sitting side-by-side, one driving and the other paying close attention to the task at hand. So, it's continuous code review.

Even thinking about such a practice gets me angry. It is treating junior programmers like dirt. When the time comes to go for the next job, what is the junior programmer going to say? "I never programmed a line of code, I merely examined someone else's?"

And how is the junior programmer going to learn to recognize good code if he merely looks at someone else's and never writes code himself? It's like the line from the Gilbert and Sullivan song:

Stay by your desks and never go to sea
and you all may be the leaders of the Queen's Navy

Moreover, what senior programmer wants someone else looking over his shoulder 40 hours a week? Often I try something and it doesn't work. Last week I spent several days trying to get user_manage to work before giving up and using Apache::htgroup and Apache::htpasswd instead. Think how embarassed I would have been to tell a junior programmer that all the work he did supporting me was for naught, we are not going to use user_manage after all.

I don't know much about extreme programming, but just hearing about it upsets me. Save "extreme" for extreme sports and tattooed skateboarders. Let's develop software using moderation, not extremism.

Replies are listed 'Best First'.
Re: Extreme Programming Frightens This Perl Programmer
by davorg (Chancellor) on Feb 18, 2001 at 18:22 UTC

    You should take a closer look at XP before criticising it like that. Look at the XP web site or read Extreme Programming Explained.

    Pair programming is only one small part of XP and it works nothing like the way you assume. There aren't junior and senior partners in a pair. A particular pair might only exist for a day and then both programmers move on to other pairs.

    I confess that I had a similar reaction to you when I first heard about it, but I've investigated further and I'm more excited by XP than I've ever been by any other development methodology. I can't wait to find a project enlightened enough to give it a try.

    --
    <http://www.dave.org.uk>

    "Perl makes the fun jobs fun
    and the boring jobs bearable" - me

(Corion) My Xperience regarding Pair Programming (Re: Extreme Programming Frightens This Perl Programmer)
by Corion (Patriarch) on Feb 19, 2001 at 01:40 UTC

    I can only report from my personal experience about pair programming - I've done this over the years together with a close friend, and I must say that it always worked very well, even in the implementation stage, since we did everything together, the high-level planning, the implementation and the debugging (this was before the light of regression testing shone on me). Of course, there was no ego problem between us and neither of us had any problem getting criticized<sp?> for what he wrote, but most of the time, bad code wasn't written at all because the questions came in the instant of writing that questionable code. The whole setup worked very well for us while we explored the wonders of the Windows 3.1 API, object oriented programming and writing device drivers (not all in one project, mind you) - all of these were projects where both of us didn't have any experience in at the time, and so explaining each straw of wisdom gathered was helpful for both.

    Nowadays, I don't do much pair programming anymore (I don't do much programming beyond bash, quick Perl hacks and some Java anyway), but I find that I am very helpful at debugging code (mostly C(++) code) without even seeing it. People come to me, explaining their symptoms, and I oracle at the (possible) errors in their code. Of course, my sage abilities aren't that good, but while people then go over their code looking for proof of correctness of their code viz my foretold error, they look at the code with other eyes and find their error. It's not that much fun as pair programming, but it's also effective (and spares me from having to actually write C code ;-)

    Summarizing, my experience only comes from pair programming in situations where the needed specific knowledge was low and had to be achieved, but there I can say pair programming worked for me.

Re: Extreme Programming Frightens This Perl Programmer
by Oaks (Novice) on Feb 18, 2001 at 23:45 UTC
    Let's compare staffing a project to pulling adventurers from a dungeon and sending them on a quest. As they strive towards their goal, they will gain experience as they hack through monstrous insects (bugs), ogres (management), and cryptic mazes (legacy code). But if they pair up, either one of them may have that key magic item (software tool) or special skill (knowledge) to bypass certain hazards. Combining assets creates great power.

    However, let's say both parties have a viable solution to removing green slime (memory leaks). One burns it from their body while the other casts a complex spell which painlessly dissolves it. Burning it inflicts some damage on yourself, but it is done instantly and recovery usually isn't too bad. Casting the spell takes a long time and requires resources, but it destroys the slime without any pain or mess. If both adventurers are civilized, they will decide on which method is best for the situation.

    Back in the real world, my own experience has led me to conclude that paired efforts are very effective for high and mid level design, but cumbersome when it comes to implementation. However, if there's an effective way to do it, I'll be interested to see how it's done. Would anyone who has used XP successfully care to share?
Re: Extreme Programming Frightens This Perl Programmer
by Anonymous Monk on Feb 18, 2001 at 18:56 UTC

    Both programmers in the pair suggest code to each other, this isn't "I write the code and you spot my typos".

      I stand corrected. Maybe the reason my initial reaction is so negative is that XP would make me change the way I do things, and I don't want to.

      On the other hand, the word "extreme" expresses an "in-your-face" attitude. "Hardcore programming" would be a better term. Or even better, "grunge programming." I am never extreme, but my wife tells me I am pretty grungey.

        Maybe the reason my initial reaction is so negative is that XP would make me change the way I do things, and I don't want to.
        Then be sure to let your employer know that, so that they don't bother making the mistake of putting you on any advanced stuff, and they can keep you with the other junior programmers and programmer technicians who are coding the designs of others or low-level crapwork like I had when I first started.

        The day I stop learning how to change the way I do things is the day I hang my hat up as a mature programmer.

        -- Randal L. Schwartz, Perl hacker

        The use of "extreme" in the name is partly supposed to convery the "in-your-face" attitude.

        XP takes previous approches to software development and turns them around completely.

        From the stories that I have heard of Kent Beck teaching people about XP, he's very extreme as well. Very entertaining stories. In a post grad course I took, we covered XP in one lecture. My lecturer took an extreme approach to teaching it, which made the lecture a lot of fun and carried across Kent's attitude. I've picked some of this up as well, so I don't talk about extreme programming, it's EXTREME Programming!

        "Hardcore programming"
        Like hardcore asians, teens, whatever? :-)

        I guess we'll be seeing that on pr0n sites soon :-(
        oh damn ... here come the popups!

        just kidding, the idea made me laugh out loud


        split $CBAS;     # ouch!

Re: Extreme Programming Frightens This Perl Programmer
by chipmunk (Parson) on Feb 19, 2001 at 00:49 UTC
    People often fear what they don't understand.

    That certainly seems to be the case in this thread. Although I don't know much about Extreme Programming myself, I've gathered enough from discussion on this site to deduce that those who are attacking XP here are doing so from a position of ignorance.

    I think that's really unfortunate.

Re: Extreme Programming Frightens This Perl Programmer
by Seumas (Curate) on Feb 19, 2001 at 16:55 UTC
    As some others have pointed out, XP is not at all about "here, watch me", with the only duty to spot typos and minor errors. It is about two sets of minds operating on the same issue in the same moment of time, simultaneously generating and reviewing code. It combines the effort, experience and alternate views of two people into, essentially, one input (into the machine). After a little experience with this method and with the same partner, you can churn out some pretty impressive material pretty quickly.

    I'm not sure if this is a "general practice" in some places, but I do know a lot of people who do this for their own projects or in their small companies, not out of a requirement but a preference.

    It's understandable that some people would prefer to be left alone and do their coding rogue-style, but being a complete neophyte (have a medium-range experience with Perl, but absolutely no formal education or in-depth knowledge of programming), I would very much welcome such a situation, if the partner was a more mature programmer. Having someone watch over my shoulder and offering tips and advice when I'm about to make a blunder or to offer explanations of why what I attempted was silly or non-functional would be an extremely benifical experience.

    --
    gothicauctions.com

Re: Extreme Programming Frightens This Perl Programmer
by Anonymous Monk on Feb 19, 2001 at 00:53 UTC
    I think you're labouring under a misconception about code review in particular and XP in general. It isn't the case that all code's written this way, or that the 'guru' writes all the code. It's people who happen to be working on the same project sometimes collaborating to write new code, or perhaps to look at code they've already written. Either person can write code and either can comment. It's categorically not a case of one person programming and the other spectating. In my experience this works well if applied sensibly rather than dogmatically and it's actually quite close to the way I've tended to work in the twenty or so years I've been developing software.

    Also the "Extreme" in XP is, I think, quite misleading. While I'm as keen as anyone on a bit of extremity XP actually tends to make things less "extreme" in the sense that software developers would normally recognise (i.e. extreme == 16 hour days, crazy deadlines).

Re: Extreme Programming Frightens This Perl Programmer
by Rudif (Hermit) on Feb 19, 2001 at 05:10 UTC
    Hi 04

    When a junior person takes car driving lessons with an instructor, he/she does the driving, and the instructor pays close attention.
    My limited understanding of XP/pair programming is that typically the person who knows less about the problem at hand does the driving/coding/typing, while the other one helps to plan the trip and foresee obstacles. But it is up to them to switch the roles as they see fit.

    I rather like the tongue-in-cheek attitude of XPers. Their mantras go something like this
    "if we think pair programming is a good thing then we take it to the extreme and do it all the time."
    "if we think that unit testing is a good thing then ..."
    ... many more like this (about 12). They would probably also say
    "if we think that programming in Perl is a good thing ..." which might please some people and give creeps to others ;-)

    Myself, I don't mind admitting my mistakes to a junior programmer - helps to learn how to avoid repeating them.

    Rudif
Re: Extreme Programming Frightens This Perl Programmer
by tlynch001 (Initiate) on Feb 20, 2001 at 20:11 UTC
    'Extreme' is overused, and it really doesn't express the idea behind this style of software development.

    The goal is to reduce costs involved with software development. One interesting fact is that the sooner you catch mistakes, the less it costs to fix them (compare the cost of fixing a mistake the minute you make it vs. after you've already shipped the product). So that's one reason to team developers up.

    Another very important reasons to partner up is so everyone knows what each other is working on. You see, you change partners daily. If a programmer leaves, you don't have to spend time trying to figure out what he was doing and get the new guy up to speed.

    No one knows if extreme programming is the next great thing. More research has to be done. Software development is still a new and exciting field (at least I think so). There's a lot of interesting ideas behind extreme programming. Too bad the name turns so many people off. 'Extreme' is such a 90's term anyway.

    Now I'm babbling...

    -tl
Re: Extreme Programming Frightens This Perl Programmer
by bheckel (Beadle) on Feb 18, 2001 at 19:22 UTC
    I completely agree. The idea of paired programming gives me the creeps. So does the word 'Extreme.' XP may have benefits but I don't see this as one of them. Having someone senior to me say my code sucks or being weighed down by a junior coder (in effect, training him) seems unpleasant. And why stop at pairs, why not have 15 programmers huddled around the screen?
      Why novices must learn from veterans:

      Because 9 times out of 10, when a novice asks "Why not do it this way?" the veteran can provide a good reason.

      Why veterans must learn from novices:

      Because 1 time out of 10, when a novice asks "Why not do it this way?" there *is* no good reason.

      (disclaimer: this is a rule of thumb, and pair programming isn't about sitting a 12 year old behind John Carmack for six hours.)

      If senior programmers never give you feedback, how will you learn?

      Conversely every teacher I have talked to agrees that when they try to explain things to other people they quickly find out how much they did not know and wind up learning the subject much better.

      This seems like a good thing both ways.

      Besides which, your statement seems to assume that there is a hierarchy of levels of skill, each of which has little to gain from those below, and little to say other than, "You suck." I hope that this is not really how you feel, and it certainly does not fit my experience...

      Having someone senior to me say my code sucks or being weighed down by a junior coder (in effect, training him) seems unpleasant.

      Don't you ever do code reviews? Does someone then telling you how your code could be seem unpleasant, or does it actually help?

      Pairing allows someone to do this in real time. It's not a senior/junior pairing - for pairing to really work well it's meant to be people of roughly equal skill. And counter-intuitive as it seems, any time we've tried it you tend to get more 'value' from it than from the two individuals coding alone.

      Tony

        OK, I phrased that way too negatively. I agree with the benefits of advice from senior programmers.

        The pairing is still an uncomfortable idea for me. Maybe it's based on my personality. It seems that people who "gain energy" from being around other people will be better suited for it.
      Having someone senior to me say my code sucks or being weighted down by a junior coder (in effect, training them) seems unpleasant.

      Two comments on this:

      First, to get better at programming, most people to need external input (i.e., feedback). Some of that feedback will come in a constructive form, and some may be harsh. Good Extreme Programming people learn to be tactful when giving feedback, but if someone chooses to hear any and all criticism of their code as being "this sucks", then they're cutting themselves off from a lot of valuable information, and their path up the mountain is going to be that much more difficult.

      Second, if someone isn't willing to share the responsibility of helping train junior team members, then perhaps Extreme Programming isn't for them. But then perhaps lots of other things aren't for them, either. Like anything to do with being on a team. The chance to impart what you know on a junior programmer, helping mold them into a more capable programmer, is a challenge that one can learn a lot from.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://59247]
Approved by root
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (2)
As of 2024-03-19 04:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found