Loading ...
Sorry, an error occurred while loading the content.

Sometimes it takes some convincing ...

Expand Messages
  • Luke Burton
    Good morning [1] all, I have been trying to convince a friend to come along to a Sydney XP group meeting, since he has so many objections (reasonably well
    Message 1 of 9 , Oct 31, 2002
    • 0 Attachment
      Good morning [1] all,

      I have been trying to convince a friend to come along to a Sydney XP
      group meeting, since he has so many objections (reasonably well thought
      out) to XP that I would really enjoy the resulting debate.

      I thought I would raise a few of his concerns here, just to test what
      people thought of them first. I think I made good stabs at answering a
      lot of them, but I'm interested to hear some general discussion first.

      One of his first is pair programming. It seems that people love to pick
      on pair programming, as it's one of the more 'radical' elements of XP. I
      ask people about XP, and they're like "hey that's where you both sit at
      the keyboard right?"

      [ if I can digress for just a moment. Another friend of mine worked on a
      Uni project with a colleague, and related this story yesterday. They
      essentially did pair programming, except all of eight years ago. They
      explained to their professor that this enable them to constantly review
      the code being written, and that it was in fact more productive than a
      single person coding. It was something they naturally fell into. The
      professor deducted marks for 'unproductive work practices' in their
      final project score. My friend is incensed that now you can buy books
      telling you how good this technique is, and he was punished for using it
      years ago ;) ]

      Anyway, my other friend's objection to pair programming is: some people
      just aren't suited to it. He cites an example of one programmer would
      come into another's office and pick his nose, then roll the boogers
      between his fingers. Nobody could stand the guy. But if management
      decreed that XP was to be adopted, some unlucky bastard would get stuck
      next to this him.

      Hitherto, working on his own, this programmer had been quite productive,
      if anti-social. How do you explain to your managers that this highly
      paid programmer can't participate in your project anymore? Do you drop
      pair programming to accommodate him? Do you fire him? How does he fit
      in? The assertion that my friend and I agreed upon was that you would
      always find someone like this in an organisation, to varying degrees.

      Another question. If you pull a representative from the client in to
      work directly with the XP team, how do you know that you haven't been
      given someone whose presence the client can afford to miss? Have you
      been given someone whose role is relatively unimportant and who can drop
      what he's doing at the client site? How can you stop this from
      happening? Does it matter?

      Another question. How are story cards any different from modular or
      functional decomposition? What do they bring to the table that older
      techniques do not?

      Another question. Neil Roodyn is presenting in Sydney on "Up front
      design, why waste your time?" My friend immediately took the extreme
      example and said "what if your first story card says 'we must be able to
      view all records in the database'. Since you haven't done any upfront
      design, you decide to use a hypothetical read-only operating system for
      speed purposes. Now your second card comes along which says 'you must be
      able to add records to the database'. Now thanks to no up-front design,
      you are stuck. You must switch operating systems to accommodate story
      card #2"

      Almost done. This guy is full of cynicism, if you can't already tell.
      Why pay an XP coach to come in to an organisation and give a whole bunch
      of people advice that will be ignored? He claims that he's seen so many
      training people come in, do their couple of days of evangelising, then
      off they go and everyone forgets everything they've said. Are XP coaches
      capitalising on organisations' tendency to think bringing in a coach or
      two will solve a heap of problems?

      Finally. Do XP projects succeed, and how many of them are there out
      there? Are there any high profile ones?

      Phew, that's it. Pick your favourite paragraph and chew it :)

      Regards,

      Luke.

      [1] Sydney time.

      --
      Luke Burton.
      Rogue Wave, Inc. (http://www.roguewave.com)

      Yes, questions. Morphology, longevity, incept dates.
    • Ron Jeffries
      Some light-hearted but sincere answers ... ... Perhaps not. Perhaps no one would pair with him. ... Pair program enough to get good at it, then decide. If the
      Message 2 of 9 , Oct 31, 2002
      • 0 Attachment
        Some light-hearted but sincere answers ...

        On Thursday, October 31, 2002, at 6:11:28 PM, Luke Burton wrote:

        > Anyway, my other friend's objection to pair programming is: some people
        > just aren't suited to it. He cites an example of one programmer would
        > come into another's office and pick his nose, then roll the boogers
        > between his fingers. Nobody could stand the guy. But if management
        > decreed that XP was to be adopted, some unlucky bastard would get stuck
        > next to this him.

        Perhaps not. Perhaps no one would pair with him.

        > Hitherto, working on his own, this programmer had been quite productive,
        > if anti-social. How do you explain to your managers that this highly
        > paid programmer can't participate in your project anymore? Do you drop
        > pair programming to accommodate him? Do you fire him? How does he fit
        > in? The assertion that my friend and I agreed upon was that you would
        > always find someone like this in an organisation, to varying degrees.

        Pair program enough to get good at it, then decide. If the person's
        work alone is as good as the work of half a standard pair, maybe keep
        him. If not ... think about it.

        > Another question. If you pull a representative from the client in to
        > work directly with the XP team, how do you know that you haven't been
        > given someone whose presence the client can afford to miss? Have you
        > been given someone whose role is relatively unimportant and who can drop
        > what he's doing at the client site? How can you stop this from
        > happening? Does it matter?

        It might. How do you know the requirements you get now weren't written
        by some fool?

        > Another question. How are story cards any different from modular or
        > functional decomposition? What do they bring to the table that older
        > techniques do not?

        They come to the table one at a time. They're about user value, not
        function. You can tear one up and not disturb the others. You can hold
        them up and say "which one of these should we do first?"

        > Another question. Neil Roodyn is presenting in Sydney on "Up front
        > design, why waste your time?" My friend immediately took the extreme
        > example and said "what if your first story card says 'we must be able to
        > view all records in the database'. Since you haven't done any upfront
        > design, you decide to use a hypothetical read-only operating system for
        > speed purposes. Now your second card comes along which says 'you must be
        > able to add records to the database'. Now thanks to no up-front design,
        > you are stuck. You must switch operating systems to accommodate story
        > card #2"

        Well, first of all, if you are really dumb enough to do this, you're a
        fool and no process will help you.

        Second, the first step in XP is to go over /all/ the stories and
        estimate them all against the calendar. So if the above happens to
        you, you're not just a fool, you're a forgetful fool.

        Third, there is no read-only operating system. There used to be, but
        they went out of business because no one could load their data.

        > Almost done. This guy is full of cynicism, if you can't already tell.
        > Why pay an XP coach to come in to an organisation and give a whole bunch
        > of people advice that will be ignored? He claims that he's seen so many
        > training people come in, do their couple of days of evangelising, then
        > off they go and everyone forgets everything they've said. Are XP coaches
        > capitalising on organisations' tendency to think bringing in a coach or
        > two will solve a heap of problems?

        If the team's not going to listen, don't pay anyone to talk. Just send
        us the money, we'll stay home or meet you at the pub.

        > Finally. Do XP projects succeed, and how many of them are there out
        > there? Are there any high profile ones?

        No. No XP project has ever succeeded. The three thousand people on
        this list are just goofing off.

        > Phew, that's it. Pick your favourite paragraph and chew it :)

        Does your friend like sushi? Has he ever tried it?

        Ron Jeffries
        www.XProgramming.com
        Fear is the mindkiller. --Bene Gesserit Litany Against Fear
      • banshee858
        ... people ... would ... stuck ... This picking you nose thing is a red herring. We programmers are very good at identifying the boundary conditions and edge
        Message 3 of 9 , Oct 31, 2002
        • 0 Attachment
          >
          > Anyway, my other friend's objection to pair programming is: some
          people
          > just aren't suited to it. He cites an example of one programmer
          would
          > come into another's office and pick his nose, then roll the boogers
          > between his fingers. Nobody could stand the guy. But if management
          > decreed that XP was to be adopted, some unlucky bastard would get
          stuck
          > next to this him.
          >
          This picking you nose thing is a red herring. We programmers are
          very good at identifying the boundary conditions and edge cases.
          However, we fail in evaluating just how important the edge cases
          are. People with poor hygine are just edge cases since most people
          do not have such extreme habits.

          So, for the picking the your nose guy, I would just say, wrinkling my
          face, "That's kinda gross. Can you please not do that when we are
          working together? Thanks." Then I would just go back to work. I
          just would hasten to add I'm not being mean, but honest with the
          person and trying to be a little funny so he does not feel all that
          bad. This picking your nose just might be a nervous habit.

          The only typical hygine problem I have encounted with pairing is if
          someone has a cold. I know if I am feeling sick or sneezing a lot
          because of of allergies, I do not touch the keyboard until AFTER I
          have washed my hands after touching my face.

          >
          > Another question. How are story cards any different from modular or
          > functional decomposition? What do they bring to the table that
          older
          > techniques do not?
          >
          I love 4 by 6 index cards! They are perfect for writing down
          features you can complete in 3 to 5 days. They also are awesome way
          for the customer to priortize and see the ENTIRE project at once
          either as a stack, laid out on the table or pinned on the wall.
          Finally, stories must each have a test to verify they are complete.
          Most other methods I know of miss this important feature.

          >
          > Finally. Do XP projects succeed, and how many of them are there out
          > there? Are there any high profile ones?
          >
          My current project is successful. We have release one version of our
          product and another version in a week or so. Keep in mind, I am only
          doing about 70% to 80% XP, but I think you would call it XP if you
          saw it.
        • Laurent Bossavit
          ... If management decrees that XP is to be adopted, then whatever you actually end up doing, it s unlikely to be XP. Especially in the presence of demonstrated
          Message 4 of 9 , Oct 31, 2002
          • 0 Attachment
            > Nobody could stand the guy. But if management decreed that XP was to
            > be adopted, some unlucky bastard would get stuck next to him.

            If management decrees that XP is to be adopted, then whatever you
            actually end up doing, it's unlikely to be XP. Especially in the
            presence of demonstrated diffculty in dealing with "problem"
            personalities.

            > The assertion that my friend and I agreed upon was that you would
            > always find someone like this in an organisation, to varying degrees.

            Oh, if you can at least *find* them, you should be OK. ;)

            > Why pay an XP coach to come in to an organisation and give a whole
            > bunch of people advice that will be ignored?

            Because the ensuing failure can then be blamed on the people who have
            been given the advice, i.e. you and your peers.

            This is one reason why a *good* XP coach (as opposed to anyone who's
            just calling him- or herself one) will make sure that the first
            people to get advice are the people who paid for it, and that they
            pay enough for it that they are not tempted to just ignore it.

            > Are XP coaches capitalising on organisations' tendency to think
            > bringing in a coach or two will solve a heap of problems?

            What a good coach does capitalize on, and strives to develop, is the
            organization's existing aptitude at solving its own problems.

            Cheers,

            -[Morendil]-
            My reality check just bounced.
          • William Pietri
            Howdy, Luke. ... Looking over his concerns, he seems to worry that XP is a program for robots rather than a set of guidelines for smart people to adapt to
            Message 5 of 9 , Oct 31, 2002
            • 0 Attachment
              Howdy, Luke.

              On Thu, 2002-10-31 at 15:11, Luke Burton wrote:
              >
              > I thought I would raise a few of his concerns here, just to test what
              > people thought of them first. I think I made good stabs at answering a
              > lot of them, but I'm interested to hear some general discussion first.

              Looking over his concerns, he seems to worry that XP is a program for
              robots rather than a set of guidelines for smart people to adapt to
              local conditions.

              Although I'm happy to answer his questions until he passes out from
              exhaustion, I suspect he's one of those people who will never be
              convinced by words; he is imprisoned by his own verbal smarts. Perhaps
              the easiest path is just to get him to pair a few times or to get him
              involved in some planning games. If you can get him to work half as hard
              at making XP work as he has at knocking it down, he'll do fine.


              > Hitherto, working on his own, this programmer had been quite productive,
              > if anti-social.How do you explain to your managers that this highly
              > paid programmer can't participate in your project anymore?

              I'm not sure I buy this. All the really socially handicapped programmers
              I know were a big pain in the ass in a team context, whether pairing or
              not.

              > How does he fit in? The assertion that my friend and I agreed
              > upon was that you would always find someone like this in an
              > organisation, to varying degrees.

              From what I've heard, it sounds like upwards of 90% of programmers make
              the transition to XP eventually as long as they are led to it rather
              than being forced into it. In the anecdotes I've heard the programmers
              who don't make it generally are ones who are hostile to it, not ones who
              are just shy or socially inept.

              Has anybody here had to let a perfectly good and willing programmer go
              because they just couldn't learn how to pair?


              > Another question. If you pull a representative from the client in to
              > work directly with the XP team, how do you know that you haven't been
              > given someone whose presence the client can afford to miss?

              What matters is whether the person can fairly represent the needs of the
              Customer. If they are just unskilled, then frequently releases can help
              them learn quickly. If they are crazed or unable to learn, you're
              screwed no matter what process you use.

              Often, the best people to act as a Customer proxy are not the superstars
              on the customer side. When working with financial traders, we would
              often work most closely with somebody who wasn't a top trader, but was a
              kick-ass Customer. That was a win for everybody, especially the proxy,
              who suddenly had a chance to shine.

              > Another question. How are story cards any different from modular or
              > functional decomposition? What do they bring to the table that older
              > techniques do not?

              I think of those as techniques for code organization, not requirements
              organization. A linear sequence of simple stories is a technique for
              making clear what your customers want. It may have no relation to the
              structure of the code.


              > Another question. Neil Roodyn is presenting in Sydney on "Up front
              > design, why waste your time?" My friend immediately took the extreme
              > example and said "what if your first story card says 'we must be able to
              > view all records in the database'

              Ron already covered this; I heartily agree. But I thought I'd add that
              terms like "record" and "database" in stories make me nervous. I like to
              see them written in human terms. E.g.,

              * Any employee can view the current phone list from their
              computer.
              * The office manager can edit the phone list.
              * Employees can add their home numbers to the phone list.

              For reasons that I can't quite articulate, I feel that this makes it
              much less likely that the team will end up painting itself into a
              corner.

              > Why pay an XP coach to come in to an organisation and give a whole bunch
              > of people advice that will be ignored? He claims that he's seen so many
              > training people come in, do their couple of days of evangelising, then
              > off they go and everyone forgets everything they've said.

              The coach is there to help the XP team with problems. If they don't give
              a rip about adopting XP, then getting a coach is indeed a waste of time
              for everybody. If the developers want to adopt XP, then a coach can be a
              major boon. I learned XP out of the books, and like riding a bike, it's
              much harder to learn if you've never seen it done.


              It sounds like your friend has endured innumerable management-imposed
              initiatives, most of which were a buzzword-fueled waste of time. I
              sympathize with him. Point out to him that unlike most business fads
              this, XP was developed by programmers so that they could do as much
              high-quality work as possible.

              > Finally. Do XP projects succeed, and how many of them are there out
              > there? Are there any high profile ones?

              I dunno about all of that, but they do succeed.

              If you look at http://www.longbets.org/, I did that mainly as an
              XpForOne project. (The site, by the way, is more complicated than it
              looks, but most of the complexity is hidden unless you are a bettor.)
              You can check in the archives for my stats on KLOC and whatnot.

              It was done on a tight deadline with minimal resources. We have had no
              downtime, and only two bugs, despite substantial floods of traffic when
              covered in places like the New York Times and Wired.

              The two visionaries behind it (Stewart Brand and Kevin Kelly) were a
              fountain of great ideas. That's a mixed blessing on a tight budget;
              without XP's techniques for flexibility and scope management, I'm
              confident we wouldn't have gotten as far and as fast as we did.


              > Phew, that's it. Pick your favourite paragraph and chew it :)

              Heh. You should have your friend join the group. Just check with Jonas
              for the next opening on the troll schedule.

              William

              --
              brains for sale: http://scissor.com/
            • jeffgrigg63132
              ... Easy: Don t ignore them. Actually, an XP coach is pretty hard to ignore. He or she doesn t just tell you how to do something. They don t just show you
              Message 6 of 9 , Oct 31, 2002
              • 0 Attachment
                --- Luke Burton <luke@b...> wrote:
                > Why pay an XP coach to come in to an organisation and give a
                > whole bunch of people advice that will be ignored?

                Easy: Don't ignore them.


                Actually, an XP coach is pretty hard to ignore. He or she doesn't
                just tell you how to do something. They don't just show you how to
                do something. They don't just make you do it on some toy practice
                project. An XP coach will make you use XP on your real-world project
                in your real-world office, on something that will have real-world
                value to your business. That's pretty hard to ignore.

                But, of course, you could still ignore it, and abandon all the
                practices. However, assuming that you would do so, what chance does
                any other methodology, such as RUP have? (None. They're even easier
                to ignore / pervert / drift away from / etc. ;-)


                > He claims that he's seen so many training people come in, do
                > their couple of days of evangelising, then off they go and
                > everyone forgets everything they've said.

                Don't do that.
              • tranzpupy
                ... people ... would ... stuck ... Perhaps he could be fitted with one of those big collars that they put on dogs to keep them from licking their wounds... or
                Message 7 of 9 , Oct 31, 2002
                • 0 Attachment
                  --- In extremeprogramming@y..., Luke Burton <luke@b...> wrote:
                  >
                  > Good morning [1] all,
                  ><snip>
                  > Anyway, my other friend's objection to pair programming is: some
                  people
                  > just aren't suited to it. He cites an example of one programmer
                  would
                  > come into another's office and pick his nose, then roll the boogers
                  > between his fingers. Nobody could stand the guy. But if management
                  > decreed that XP was to be adopted, some unlucky bastard would get
                  stuck
                  > next to this him.

                  Perhaps he could be fitted with one of those big collars that they
                  put on dogs to keep them from licking their wounds... or glue his
                  nostrils shut with super glue... or merely set up a small shock
                  whenever he raised his hand to his face...

                  <grin>

                  Kay
                • Brian Christopher Robinson
                  ... The options you mention don t include the possibility of asking the person to stop the behavior that others don t enjoy. That seems like a logical first
                  Message 8 of 9 , Nov 1, 2002
                  • 0 Attachment
                    On Fri, 1 Nov 2002, Luke Burton wrote:

                    > Anyway, my other friend's objection to pair programming is: some people
                    > just aren't suited to it. He cites an example of one programmer would
                    > come into another's office and pick his nose, then roll the boogers
                    > between his fingers. Nobody could stand the guy. But if management
                    > decreed that XP was to be adopted, some unlucky bastard would get stuck
                    > next to this him.

                    The options you mention don't include the possibility of asking the
                    person to stop the behavior that others don't enjoy. That seems like a
                    logical first step to me. Firing him, taking him off the project, or
                    excluding him from pair programming should only be considered if he
                    can't be reasoned with.

                    > Another question. If you pull a representative from the client in to
                    > work directly with the XP team, how do you know that you haven't been
                    > given someone whose presence the client can afford to miss?

                    You will know when the "real" client is unsatisfied with the
                    requirements set forth by the proxy client. At that point you tell the
                    real client that if he wants the software you're developing to actually
                    meet his requirements he will have to devote someone with proper
                    knowledge to the project.

                    > Another question. How are story cards any different from modular or
                    > functional decomposition? What do they bring to the table that older
                    > techniques do not?

                    In many ways they're not. I think if you look at Kent's discussion of
                    cards in the 10 Actions document you might get a good idea about this
                    one.

                    > Another question. Neil Roodyn is presenting in Sydney on "Up front
                    > design, why waste your time?" My friend immediately took the extreme
                    > example and said "what if your first story card says 'we must be able to
                    > view all records in the database'. Since you haven't done any upfront
                    > design, you decide to use a hypothetical read-only operating system for
                    > speed purposes. Now your second card comes along which says 'you must be
                    > able to add records to the database'. Now thanks to no up-front design,
                    > you are stuck. You must switch operating systems to accommodate story
                    > card #2"

                    Well, there are bad decisions that programmers can make. First off,
                    without a specific speed requirement, using a fast read only system is
                    not the best choice. If I was given card #1, I would implement a
                    rudimentary way to add records to the database for testing anyway, so
                    card #2 would be a cinch.

                    > Why pay an XP coach to come in to an organisation and give a whole bunch
                    > of people advice that will be ignored? He claims that he's seen so many
                    > training people come in, do their couple of days of evangelising, then
                    > off they go and everyone forgets everything they've said. Are XP coaches
                    > capitalising on organisations' tendency to think bringing in a coach or
                    > two will solve a heap of problems?

                    You can do XP without a coach. We have been doing XP at my company for
                    around two years without a coach. I sometimes wish we had one but we
                    haven't and we do okay.

                    If you do get a coach I think it would be worth getting people
                    interested before having him come. I'd recommend trying an iteration
                    using the books only, then bringing in a coach. That way you can show
                    the coach which areas you're already good at and which he can help you
                    with the most.

                    > Finally. Do XP projects succeed, and how many of them are there out
                    > there? Are there any high profile ones?

                    My project has generally been successful. We've met the deadlines put
                    forth by our customer and produced robust software.
                  • Jonas Bengtsson
                    ... Coincidentally there are no trolls booked for this week. Just troll away! -- Best regards, Jonas I never, ever thought of myself as a businessman. I was
                    Message 9 of 9 , Nov 4, 2002
                    • 0 Attachment
                      On 2002-11-01, 04:35, William Pietri wrote:
                      > Heh. You should have your friend join the group. Just check with Jonas
                      > for the next opening on the troll schedule.

                      Coincidentally there are no trolls booked for this week. Just troll
                      away!

                      --
                      Best regards,
                      Jonas

                      I never, ever thought of myself as a businessman. I was interested in
                      creating things I would be proud of.
                      - Richard Branson
                    Your message has been successfully submitted and would be delivered to recipients shortly.