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

IDEs, Pair Programming, Pragmatic Thinking and Learning

Expand Messages
  • Steve Berczuk
    The combination of having recently finished reading Andy Hunt s Excellent book, Pragmatic Thinking and Learning, and recently joining a team where we are
    Message 1 of 26 , Jan 24, 2009
    • 0 Attachment
      The combination of having recently finished reading Andy Hunt's
      Excellent book, Pragmatic Thinking and Learning, and recently joining
      a team where we are (mostly successfully) using 2 different IDEs (IDEA
      and Eclipse) led me to think about the question of standardization and
      how much makes sense.

      I tend to think that if some developers are highly productive on one
      tool it might not make sense to have everyone use the same tool for
      the sake of conformity Andy Hunt says something like this in Ch 2). --
      this assumes that you can configure each IDE to work with the same
      style settings, generate project settings from the same build scripts
      etc.. (and this is pretty much true... and in some cases tools can
      read each others configs.)

      What I was wondering is: how does doing Pair Programming affect this?
      When I was on a project that did full time pair programming we all
      used the same IDE. I'm thinking that if you are strict about the
      Driver/Navigator role, having multiple IDEs would not be that bad...
      and there is a class of basic operations where the differences are
      similar. But this is hypothetical.

      Has anyone worked on a project that used Pair Programming and also did
      not have a standard IDE? (or has anyone thought about this scenario?)

      Thanks!

      Steve


      --
      Steve Berczuk | steve@... | http://www.berczuk.com
      SCM Patterns: Effective Teamwork, Practical Integration
      www.scmpatterns.com
    • Nina Niskanen
      In my current project, we don t really pair formally , but if someone has a problem, someone works together with them on their machine to make things work.
      Message 2 of 26 , Jan 24, 2009
      • 0 Attachment
        In my current project, we don't really pair "formally", but if someone
        has a problem, someone works together with them on their machine to
        make things work. With regards to IDE's we have the same combination
        as you do, IDEA and Eclipse. We also have different operating systems,
        Some have Ubuntu Linux, some have Mac's and the rest have Windows. At
        least when the pairing happens very occasionally it takes time to find
        one's bearing and it's not very effective. I do expect that would go
        away to some degree if we paired more often, but not completely.

        Nina

        2009/1/25 Steve Berczuk <steve.berczuk@...>:
        > The combination of having recently finished reading Andy Hunt's
        > Excellent book, Pragmatic Thinking and Learning, and recently joining
        > a team where we are (mostly successfully) using 2 different IDEs (IDEA
        > and Eclipse) led me to think about the question of standardization and
        > how much makes sense.
        >
        > I tend to think that if some developers are highly productive on one
        > tool it might not make sense to have everyone use the same tool for
        > the sake of conformity Andy Hunt says something like this in Ch 2). --
        > this assumes that you can configure each IDE to work with the same
        > style settings, generate project settings from the same build scripts
        > etc.. (and this is pretty much true... and in some cases tools can
        > read each others configs.)
        >
        > What I was wondering is: how does doing Pair Programming affect this?
        > When I was on a project that did full time pair programming we all
        > used the same IDE. I'm thinking that if you are strict about the
        > Driver/Navigator role, having multiple IDEs would not be that bad...
        > and there is a class of basic operations where the differences are
        > similar. But this is hypothetical.
        >
        > Has anyone worked on a project that used Pair Programming and also did
        > not have a standard IDE? (or has anyone thought about this scenario?)
        >
        > Thanks!
        >
        > Steve
        >
        > --
        > Steve Berczuk | steve@... | http://www.berczuk.com
        > SCM Patterns: Effective Teamwork, Practical Integration
        > www.scmpatterns.com
        >
        >



        --
        I reject your reality and substitute my own.
      • D. André Dhondt
        ... Yes. We end up all becoming proficient in all the IDEs. Maybe I drive more in my preferred IDE, but we still swap driver/navigator roles frequently. At
        Message 3 of 26 , Jan 25, 2009
        • 0 Attachment
          >Has anyone worked on a project that used Pair Programming and also did
          >not have a standard IDE?

          Yes. We end up all becoming proficient in all the IDEs. Maybe I drive more
          in my preferred IDE, but we still swap driver/navigator roles frequently.
          At my last post, I ended up knowing all the keyboard shortcuts for Eclipse
          and VS.Net. At my current position, we use the same IDE but multiple
          operating systems. There are good business reasons for these configs... and
          so we learn to work around it. Not necessarily the easiest, but it may be
          simplest thing that could possibly work.

          On Sun, Jan 25, 2009 at 12:21 AM, Steve Berczuk <steve.berczuk@...>wrote:

          > The combination of having recently finished reading Andy Hunt's
          > Excellent book, Pragmatic Thinking and Learning, and recently joining
          > a team where we are (mostly successfully) using 2 different IDEs (IDEA
          > and Eclipse) led me to think about the question of standardization and
          > how much makes sense.
          >
          > I tend to think that if some developers are highly productive on one
          > tool it might not make sense to have everyone use the same tool for
          > the sake of conformity Andy Hunt says something like this in Ch 2). --
          > this assumes that you can configure each IDE to work with the same
          > style settings, generate project settings from the same build scripts
          > etc.. (and this is pretty much true... and in some cases tools can
          > read each others configs.)
          >
          > What I was wondering is: how does doing Pair Programming affect this?
          > When I was on a project that did full time pair programming we all
          > used the same IDE. I'm thinking that if you are strict about the
          > Driver/Navigator role, having multiple IDEs would not be that bad...
          > and there is a class of basic operations where the differences are
          > similar. But this is hypothetical.
          >
          > Has anyone worked on a project that used Pair Programming and also did
          > not have a standard IDE? (or has anyone thought about this scenario?)
          >
          > Thanks!
          >
          > Steve
          >
          > --
          > Steve Berczuk | steve@... <steve%40berczuk.com> |
          > http://www.berczuk.com
          > SCM Patterns: Effective Teamwork, Practical Integration
          > www.scmpatterns.com
          >
          >



          --
          D. André Dhondt
          mobile: 001 33 671 034 984


          [Non-text portions of this message have been removed]
        • Adam Sroka
          ... Interesting question. I think it is worth considering that there are some practices with regard to tools and equipment that lend themselves better to pair
          Message 4 of 26 , Jan 26, 2009
          • 0 Attachment
            On Sat, Jan 24, 2009 at 3:21 PM, Steve Berczuk <steve.berczuk@...> wrote:
            > The combination of having recently finished reading Andy Hunt's
            > Excellent book, Pragmatic Thinking and Learning, and recently joining
            > a team where we are (mostly successfully) using 2 different IDEs (IDEA
            > and Eclipse) led me to think about the question of standardization and
            > how much makes sense.
            >
            > I tend to think that if some developers are highly productive on one
            > tool it might not make sense to have everyone use the same tool for
            > the sake of conformity Andy Hunt says something like this in Ch 2). --
            > this assumes that you can configure each IDE to work with the same
            > style settings, generate project settings from the same build scripts
            > etc.. (and this is pretty much true... and in some cases tools can
            > read each others configs.)
            >
            > What I was wondering is: how does doing Pair Programming affect this?
            > When I was on a project that did full time pair programming we all
            > used the same IDE. I'm thinking that if you are strict about the
            > Driver/Navigator role, having multiple IDEs would not be that bad...
            > and there is a class of basic operations where the differences are
            > similar. But this is hypothetical.
            >
            > Has anyone worked on a project that used Pair Programming and also did
            > not have a standard IDE? (or has anyone thought about this scenario?)
            >

            Interesting question. I think it is worth considering that there are
            some practices with regard to tools and equipment that lend themselves
            better to pair programming.

            I have worked in environments where no one "owned" any machine. The
            developer workstations were high-end machines with dual monitors. They
            were built from a standard image with a set of tools that everyone
            could use, and each of us had a network login.

            This setup seemed to work very well for promiscuous pairing. Early in
            the project we were all getting used to the tools, but we were also
            getting used to the project and working together as a team. A few
            iterations in we were very comfortable and we switched pairs at least
            twice a day.

            I have also worked in a few different places where every developer had
            their own personal laptop, and pairing was "encouraged." In these
            environments most developers had highly customized setups. Not
            everyone used the same configuration, or the same IDE, or even the
            same OS.

            It could make pairing very difficult. For example, if I am used to
            emacs and another developer uses vi, our pairing sessions may be
            initially quite painful as I get used to working in my partner's
            environment. In practice this seems to make working with a new person
            difficult and changing pairs or beginning to pair in the first place
            quite a bit more uncomfortable.

            Additionally, it seems that the main advantage people claim for these
            highly customized environments is that it increases productivity. I
            have a couple of thoughts about that:

            1) At best this means individual productivity and not pair or team
            productivity. If I am more productive in my highly customized
            environment then I am, by corollary, less productive in someone
            else's.

            2) There is a cost involved in setting up a customized environment. In
            my experience developers may spend an entire day or two configuring a
            new machine to their individual specifications. I would be curious to
            find out whether this cost was actually less than the cost to learn to
            use a common configuration.

            3) It is my belief that the great degree of customization available in
            many modern IDEs is a sign of their poor usability. There is something
            to be said for keeping simple things simple and following some sort of
            convention.
          • Tim Ottinger
            ... You end up having to use whatever is on the screen. In python, we had Emacs, Vim, and a few other tools floating around, and it wasn t too bad. Most of
            Message 5 of 26 , Jan 26, 2009
            • 0 Attachment
              > What I was wondering is: how does doing Pair Programming affect this?
              > When I was on a project that did full time pair programming we all
              > used the same IDE. I'm thinking that if you are strict about the
              > Driver/Navigator role, having multiple IDEs would not be that bad...
              > and there is a class of basic operations where the differences are
              > similar. But this is hypothetical.
              >
              > Has anyone worked on a project that used Pair Programming and also did
              > not have a standard IDE?


              You end up having to use whatever is on the screen. In python, we had Emacs, Vim, and a few other tools floating around, and it wasn't too bad. Most of the time you do a "let me show you" short turn at the keyboard, it's straightforward delete/type stuff. But most people became reasonable novices in one and experts in one of the others.

              OTOH, I've been at a *most* dysfunctional shop where everyone had their own tools, and worked from different OSs on the same mounted file system. Taken to an extreme (maybe a dozen or more editors on two operating systems) it becomes madness. You end up switching editing environments and that slows things down.

              If the editors are quick-loading and work reasonably well, you are down to refactoring support. That really matters when you're doing some heavy lifting kinds of refactoring.

              Tim Ottinger
              http://agileotter.blogspot.com/
            • Tim Ottinger
              ... Conversely, we can learn tricks from others that will improve our own productivity, and we can share that across the team through pairing. ... Conversely,
              Message 6 of 26 , Jan 26, 2009
              • 0 Attachment
                > Additionally, it seems that the main advantage people claim for these
                > highly customized environments is that it increases productivity. I
                > have a couple of thoughts about that:
                >
                > 1) At best this means individual productivity and not pair or team
                > productivity. If I am more productive in my highly customized
                > environment then I am, by corollary, less productive in someone
                > else's.

                Conversely, we can learn tricks from others that will improve our own productivity, and we can share that across the team through pairing.

                > 2) There is a cost involved in setting up a customized environment. In
                > my experience developers may spend an entire day or two configuring a
                > new machine to their individual specifications. I would be curious to
                > find out whether this cost was actually less than the cost to learn to
                > use a common configuration.

                Conversely, I have worked with a developer who claimed to have used vi for 15 years, but was only using it in insert mode (think: crummy version of notepad) and never learned *any* of the features or plugins. I have to wonder about someone who doesn't at least show interest and curiosity in a tool they've used for 15 years. I was a better vimmer at 15 days.

                But in the case of people finding useful ways to use their environment, and then letting the change ripple through the group, it's not bad.

                However, changing standard key bindings or having them be different from the rest of the team is indeed a hurdle. If I remapped my vim keyboard, not even other vim users would be able to navigate with it. Why slam the door on pairing that way?

                > 3) It is my belief that the great degree of customization available in
                > many modern IDEs is a sign of their poor usability. There is something
                > to be said for keeping simple things simple and following some sort of
                > convention.

                I would think it was a sign of good design. They didn't hard-code things and so there is flexibility. But convention and simplicity are very simple agile ideals too, aren't they?

                I am mostly with you. Just wanted to avoid an echo chamber.

                There is no evolution without mutation. In IDE usage, I become a fan of intelligent design by the group: someone decides that there can be a smarter way of working, and the team adopts it. Conformity can be a value, ease of pair programming is a value, and greater fluidity of programming is a value.

                Teamwork is an odd combination of submission and contribution. That's why some people don't do it well.

                Tim


                Tim Ottinger
                http://agileotter.blogspot.com/
              • Jeff Langr
                ... I deliberately avoid remapping keys on my own laptop anymore for this reason, sticking with the defaults. I used to try to get some small number of
                Message 7 of 26 , Jan 26, 2009
                • 0 Attachment
                  > However, changing standard key bindings or having them be different from
                  > the rest of the team is indeed a hurdle. If I remapped my vim keyboard,
                  > not even other vim users would be able to navigate with it. Why slam the
                  > door on pairing that way?

                  I deliberately avoid remapping keys on my own laptop anymore for this
                  reason, sticking with the defaults. I used to try to get some small number
                  of functions in synch, e.g. consistently using ctrl-f for find and ctrl-r
                  for replace. But then I struggled anytime I paired, particularly in that
                  place you and I both know where there are over 10 different editors/IDEs
                  in use for one language.

                  (Now I get to remember that ctrl-f is page forward in vi, repeat find in
                  TextPad, find/replace in IDEA and Eclipse, find in Notepad++ and most
                  Microsoft editors, cursor right (I think) in Emacs, ...)

                  Couldn't there be a solution, though, that allows the IDE to quickly pull
                  down and switch to your key bindings as you take the keyboard? Seems like
                  a nice plugin for someone to build; it could even get to the point of
                  supporting multiple IDEs.

                  > Teamwork is an odd combination of submission and contribution. That's why
                  > some people don't do it well.

                  That's a great point (though the phrase "give and take" sounds nicer to
                  me). One of the first things I'll push with a new team is a coding
                  standards meeting, in which they have an hour to derive something they'll
                  agree on. It's not so much about the standards as about getting them to
                  start figuring out how to move forward together as a team. It also lets me
                  quickly spot the problem children (e.g. those who insist their crap code
                  doesn't stink and then refuse to go along with what the rest of the team
                  wants).

                  Jeff
                • Brad Appleton
                  ... This is actually how Ive learned a number of different IDE s and text-editors (and how I first learned Emacs). I had plenty of experience in the early
                  Message 8 of 26 , Jan 26, 2009
                  • 0 Attachment
                    Steve Berczuk wrote:
                    > Has anyone worked on a project that used Pair Programming and also did
                    > not have a standard IDE? (or has anyone thought about this scenario?)

                    This is actually how Ive learned a number of different IDE's and
                    text-editors (and how I first learned Emacs).

                    I had plenty of experience in the early nineties and even in the
                    eighties of doing at least part (if not all) of a task with two folks in
                    front of the same computer + screen + keyboard at the same time.

                    Whoever was "driving" got to use their editor/IDE of choice. When you
                    swapped roles, you potentially swapped IDE's/editors. Note this was
                    easier in the days of (X)terminals (be it VAX/VMS, or Unix, or whatever)
                    where both our IDE's could be easily accessed from either person's
                    "terminal". If you liked the other person's IDE or were interested in it
                    enough to try and learn it, then you could do that to. (Though I'm not
                    sure if it changed the effectiveness of the pairing upon the quality of
                    the result)

                    With different folks having their IDEs/editors locally installed on
                    private storage not accessible to other "nodes" on the network, it can
                    be harder.

                    --
                    Brad Appleton <brad {AT} bradapp.net>
                    Agile CM Environments (http://blog.bradapp.net/)
                    & Software CM Patterns (www.scmpatterns.com)
                    "And miles to go before I sleep" -- Robert Frost
                  • Steve Berczuk
                    ... So, it sounds like it s possible to day that Pairing and IDE preferences can go together. The next question I have is: Do you put IDE configurations
                    Message 9 of 26 , Jan 27, 2009
                    • 0 Attachment
                      On Mon, Jan 26, 2009 at 4:35 PM, Brad Appleton <Brad.Appleton@...> wrote:
                      > Steve Berczuk wrote:
                      >> Has anyone worked on a project that used Pair Programming and also did
                      >> not have a standard IDE? (or has anyone thought about this scenario?)
                      >
                      > This is actually how Ive learned a number of different IDE's and
                      > text-editors (and how I first learned Emacs).
                      >
                      > I had plenty of experience in the early nineties and even in the
                      > eighties of doing at least part (if not all) of a task with two folks in
                      > front of the same computer + screen + keyboard at the same time.
                      >
                      > Whoever was "driving" got to use their editor/IDE of choice. When you
                      > swapped roles, you potentially swapped IDE's/editors. Note this was
                      > easier in the days of (X)terminals (be it VAX/VMS, or Unix, or whatever)
                      > where both our IDE's could be easily accessed from either person's
                      > "terminal". If you liked the other person's IDE or were interested in it
                      > enough to try and learn it, then you could do that to. (Though I'm not
                      > sure if it changed the effectiveness of the pairing upon the quality of
                      > the result)
                      So, it sounds like it's possible to day that Pairing and IDE
                      preferences can go together.
                      The next question I have is: Do you put IDE configurations (.projects,
                      .settings, .classpath, .iml, .ipr files etc)? Or you you repeatedly
                      generate them from the build files or use IDE integration tool that
                      create IDe config files from the build files.?

                      I know that eclipse and Idea work well with maven POM files (mostly).

                      The advantage I hear about people checking in IDE files is that it
                      makes it easier for people to get working. The disadvantages are that
                      you can get out of sych and not know it. (and there is no CI system
                      for the IDE files.

                      Having IDEs in version control means that you often have to stay in
                      synch in terms of tool specific plugins (Concrete example for eclipse+
                      maven: using the m2eclipse plugin means that you have project files
                      that require that plugin)..

                      My tendency is to treat most IDE files as derived artifacts and
                      regenerate then rather than check them in, but is that too much
                      overhead in people's experience?

                      Thanks !

                      Steve


                      --
                      Steve Berczuk | steve@... | http://www.berczuk.com
                      SCM Patterns: Effective Teamwork, Practical Integration
                      www.scmpatterns.com
                    • D. André Dhondt
                      ... At my current post, I spend almost no time with IDE config. At the last job, it was more significant. I only automate things when I m getting sick of
                      Message 10 of 26 , Jan 27, 2009
                      • 0 Attachment
                        >My tendency is to treat most IDE files as derived artifacts and
                        >regenerate then rather than check them in, but is that too much
                        >overhead in people's experience?
                        At my current post, I spend almost no time with IDE config. At the last
                        job, it was more significant. I only automate things when I'm getting sick
                        of doing things manually... so last time I did throw some of this in SVN,
                        this time I don't. I chose the simplest thing that could possibly work (was
                        easier to throw this in svn than to generate it, and didn't seem to cause
                        any problems).


                        [Non-text portions of this message have been removed]
                      • George Dinwiddie
                        ... With Eclipse (and derivatives) I checkin the .project and .classpath files since those allow the IDE to build the project. (Generally, ant is used for the
                        Message 11 of 26 , Jan 27, 2009
                        • 0 Attachment
                          Steve Berczuk wrote:
                          > The next question I have is: Do you put IDE configurations (.projects,
                          > .settings, .classpath, .iml, .ipr files etc)?

                          With Eclipse (and derivatives) I checkin the .project and .classpath
                          files since those allow the IDE to build the project. (Generally, ant
                          is used for the reference build, but there's plenty of advantage to
                          working with the IDE build during TDD.) I don't checkin things like IDE
                          settings, since those may be individual taste, even though most people
                          leave them pretty vanilla.

                          - George

                          --
                          ----------------------------------------------------------------------
                          * George Dinwiddie * http://blog.gdinwiddie.com
                          Software Development http://www.idiacomputing.com
                          Consultant and Coach http://www.agilemaryland.org
                          ----------------------------------------------------------------------
                        • Charlie Poole
                          Hi All, I have a project (some of you use it) which can be built using a NAnt script, or with Visual Studio (3 versions). It can also be built with #Develop or
                          Message 12 of 26 , Jan 27, 2009
                          • 0 Attachment
                            Hi All,

                            I have a project (some of you use it) which can be built
                            using a NAnt script, or with Visual Studio (3 versions).
                            It can also be built with #Develop or MonoDevelop, but
                            both of those use VS2005 format, so that's less of an
                            issue.

                            I'd love to simply maintain a list of files per project and
                            just generate the IDE files as I need them. Of course, I
                            can do this with some level of effort using perl or ruby
                            or name-your-favorite scripting language.

                            But it would really be cool to learn that something like
                            this already exists. Does anyone know of something?

                            Charlie
                          • Steve Freeman
                            Given that this is the XP list (and not a generic Agile list), my preference is that all development environments are the same. Once settled it becomes one
                            Message 13 of 26 , Jan 28, 2009
                            • 0 Attachment
                              Given that this is the XP list (and not a generic Agile list), my
                              preference is that all development environments are the same. Once
                              settled it becomes one less thing to think about so I can focus on the
                              real work. Partly this is about focus and reducing opportunities for
                              mistakes, and partly this is about a social declaration that this is a
                              team.

                              In the Java world that would have to be Eclipse or Idea (maybe
                              NetBeans is catching up nowadays) because of the browsing and
                              refactoring support. Their strengths differ but both are plenty good
                              enough to get the work done.

                              I prefer to check in the config files because I've wasted too much
                              time fixing problems that turned out to be configuration differences.
                              I'm prepared to sacrifice a lot of control to get consistency across
                              the team, particularly for things like plugins. If I want to do
                              personal work, I might set up another instance for that. At the
                              extreme, I know of teams that put their dev environment in a VMWare
                              image so there's no question (particularly useful for Windows
                              programming).

                              S.

                              On 27 Jan 2009, at 18:59, Steve Berczuk wrote:

                              > On Mon, Jan 26, 2009 at 4:35 PM, Brad Appleton <Brad.Appleton@...
                              > > wrote:
                              >> Steve Berczuk wrote:
                              >>> Has anyone worked on a project that used Pair Programming and also
                              >>> did
                              >>> not have a standard IDE? (or has anyone thought about this
                              >>> scenario?)
                              >>
                              > The next question I have is: Do you put IDE configurations (.projects,
                              > .settings, .classpath, .iml, .ipr files etc)? Or you you repeatedly
                              > generate them from the build files or use IDE integration tool that
                              > create IDe config files from the build files.?
                              >
                              > I know that eclipse and Idea work well with maven POM files (mostly).
                              >
                              > The advantage I hear about people checking in IDE files is that it
                              > makes it easier for people to get working. The disadvantages are that
                              > you can get out of sych and not know it. (and there is no CI system
                              > for the IDE files.
                              >
                              > Having IDEs in version control means that you often have to stay in
                              > synch in terms of tool specific plugins (Concrete example for eclipse+
                              > maven: using the m2eclipse plugin means that you have project files
                              > that require that plugin)..
                              >
                              > My tendency is to treat most IDE files as derived artifacts and
                              > regenerate then rather than check them in, but is that too much
                              > overhead in people's experience?
                              >
                              > Thanks !
                              >
                              > Steve
                              >
                              >
                              > --
                              > Steve Berczuk | steve@... | http://www.berczuk.com
                              > SCM Patterns: Effective Teamwork, Practical Integration
                              > www.scmpatterns.com

                              Steve Freeman
                              http://www.mockobjects.com

                              Winner of the Agile Alliance Gordon Pask award 2006
                            • Brad Appleton
                              ... First off, I think we are (for this conversation) interested ONLY in IDE configuration settings that impact how we will build+test (integrate). I try to
                              Message 14 of 26 , Jan 28, 2009
                              • 0 Attachment
                                Steve Berczuk wrote:
                                > The next question I have is: Do you put IDE configurations (.projects,
                                > .settings, .classpath, .iml, .ipr files etc)? Or you you repeatedly
                                > generate them from the build files or use IDE integration tool that
                                > create IDe config files from the build files.?

                                First off, I think we are (for this conversation) interested ONLY in IDE
                                configuration settings that impact how we will build+test (integrate).

                                I try to keep configuration settings for "the build system" separate
                                from configuration-settings for IDEs. When there is no single standard
                                IDE being used by the team, then "the build system" typically includes
                                whatever extra mechanisms and/or "abstractions" I have to add to make it
                                IDE independent (in addition to whatever build tool(s) I am using, such
                                as make, ANT, Maven, etc.)

                                So I explicitly try to "separate concerns" here, and define an interface
                                (or input format) for any such information to be specified to "the build
                                system" and defaulted/inherited from the environment or IDE.

                                I allow, and encourage those using the same IDE to share+synch their
                                configuration settings. They might even check them into version control.
                                But I try to make sure that *integration* *builds* do not depend on
                                them, and do not use the IDE to do the build. They do need to know about
                                whatever programs must be used to read the code and generate exectable
                                or intermediate results. This would include not only compilers, but also
                                any code-generators (including HTML/XML if necessary), static-analyzers
                                or code-checkers (or code-smell detectors :-) and of course linkers and
                                libraries and loaders, etc.

                                This means any IDE configurations arent coupled to the version of the
                                project in the codeline, and doesnt need to use the same tags/labels. If
                                they choose to version those things and "release" common configurations
                                amongst themselves, it doesnt have to be project specific, and even if
                                they choose to do so, it doesnt impact the integration build.

                                --
                                Brad Appleton <brad {AT} bradapp.net>
                                Agile CM Environments (http://blog.bradapp.net/)
                                & Software CM Patterns (www.scmpatterns.com)
                                "And miles to go before I sleep" -- Robert Frost
                              • Jeff Langr
                                ... Greetings Steve, That s normally my preference, and those are good reasons. It does run the risk of being insensitive to those with legitimate physical
                                Message 15 of 26 , Jan 29, 2009
                                • 0 Attachment
                                  > Given that this is the XP list (and not a generic Agile list), my
                                  > preference is that all development environments are the same. Once
                                  > settled it becomes one less thing to think about so I can focus on the
                                  > real work. Partly this is about focus and reducing opportunities for
                                  > mistakes, and partly this is about a social declaration that this is a
                                  > team.

                                  Greetings Steve,

                                  That's normally my preference, and those are good reasons. It does run the
                                  risk of being insensitive to those with legitimate physical needs for
                                  customization to their development environment. I think there is some
                                  value in investing in enhancing IDEs to support rapid configuration
                                  switching (by pulling down profiles).

                                  Jeff L.
                                • Jeff Grigg
                                  ... Oracle JDeveloper! ;- (Well no, I ve never actually used it. ;-) I hear that NetBeans is good these days; much better than when I last used it. ...
                                  Message 16 of 26 , Jan 29, 2009
                                  • 0 Attachment
                                    --- Steve Freeman <smgfreeman@...> wrote:
                                    > In the Java world that would have to be Eclipse or Idea
                                    > (maybe NetBeans is catching up nowadays) [...]

                                    Oracle JDeveloper!
                                    ;->
                                    (Well no, I've never actually used it. ;-)

                                    I hear that NetBeans is good these days; much better than when I last
                                    used it.

                                    > I prefer to check in the config files [...].
                                    > I'm prepared to sacrifice a lot of control to get
                                    > consistency across the team, [...]

                                    Dittos on all of that.

                                    Also, it's been my experience that the IDEs aren't all the same:
                                    There are plenty of edge cases to trip over. For example...

                                    o You really expect to get three independently developed code
                                    formatters to produce the same result every time? HA!

                                    ["Related" Note: I've known some source control systems to produce
                                    differently formatted code from the vendor's command line and GUI
                                    tools! Now that was a PAIN!]

                                    o I've had plenty of problems with JUnit issues across runtimes:
                                    It's bad enough that my IDE and ant use different test collectors
                                    (different strategies and different results if you're not careful!)
                                    But in my experience, the IDEs don't exactly match either. (Maybe
                                    that's improved in the past few years, but I was BURNED by it before,
                                    so I'm a bit more cautious now.)


                                    And from a different direction...
                                    I find pair switching much easier when all the machines are exactly
                                    the same -- no machine "owned" by anyone -- no real per-user login or
                                    logout either.
                                  • MasaKevin Maeda
                                    I totally agree. At one place I worked there was one developer who refused to switch to Eclipse, which everybody else was using, and that created lots of
                                    Message 17 of 26 , Jan 29, 2009
                                    • 0 Attachment
                                      I totally agree. At one place I worked there was one developer who refused to switch to Eclipse, which everybody else was using, and that created lots of friction. There was not valid reason to not unify, other than the developer didn't want to learn Eclipse. Unfortunately the manager didn't put his stick on the ground and the problem continued for months up until the time I left that company.

                                      This will be a bump on the road until better integration between IDEs is possible.

                                      Masa



                                      > Given that this is the XP list (and not a generic Agile list), my

                                      > preference is that all development environments are the same. Once

                                      > settled it becomes one less thing to think about so I can focus on the

                                      > real work. Partly this is about focus and reducing opportunities for

                                      > mistakes, and partly this is about a social declaration that this is a

                                      > team.



                                      >Greetings Steve,


                                      >That's normally my preference, and those are good reasons. It does run the

                                      >risk of being insensitive to those with legitimate physical needs for

                                      >customization to their development environment. I think there is some

                                      >value in investing in enhancing IDEs to support rapid configuration

                                      >switching (by pulling down profiles).


                                      >Jeff L.








                                      [Non-text portions of this message have been removed]
                                    • simmonspa
                                      Just to give an alternative view ... Steve raises some good points in favour of a single IDE environment - a situation for which I would definately strive, and
                                      Message 18 of 26 , Jan 30, 2009
                                      • 0 Attachment
                                        Just to give an alternative view ...

                                        Steve raises some good points in favour of a single IDE environment -
                                        a situation for which I would definately strive, and accept along the
                                        way the pain of converting die-hard Eclipsese or Intellijese. Though
                                        in a team that is pairing much of the time, shouldn't peer pressure
                                        push towards a single IDE environment?

                                        Since many teams work in a real-world scenario of individually-owned
                                        machines, in my experience I have found it workable to have different
                                        IDEs - both IDE configs were committed to source control. Typically,
                                        configs only change when adding a 3rd party jar or other build change,
                                        which in a reasonably mature project is perfectly manageable.

                                        The team I lead from which I take this experience was of 4 developers
                                        growing to 8. We paired the majority of the time, and swapping
                                        between IDEs was not particularly difficult, and in fact this helped
                                        bridge the knowledge gap of those in each camp.

                                        Code formatting? we found formatting changes were consistent,
                                        occasionally tripping us up but no more so than someone just breaking
                                        their env.

                                        Junit and code coverage tools didn't really prove problematic, cruise
                                        control (at that time) ran our builds and the discipline was to update
                                        and run tests prior to commit.

                                        In fact we were able to use strengths in each IDE - eg: eclipse had a
                                        better subversion merge facility, whereas intellij had a great UML
                                        class diagramming plugin tool for instant analysis in a visual way.

                                        So I beg to differ, I think two IDE envs works and allows the
                                        developers to choose their most comfortable working env. At some
                                        point natural forces may lead to one or the other. As team lead or
                                        agile coach I recommend you watch for signs of conflict within the
                                        team or complications in IDE config, be ready to make a partially
                                        unpopular decision for the greater good of the team.

                                        -- Paul Simmons
                                      • Tim Ottinger
                                        Right. If you have people who just won t play, you have a problem. This is also a language issue. If you re in Java, going with eclipse or netbeans or idea
                                        Message 19 of 26 , Jan 30, 2009
                                        • 0 Attachment
                                          Right. If you have people who just won't play, you have a problem.

                                          This is also a language issue. If you're in Java, going with eclipse
                                          or netbeans or idea is a good idea, and there's not much reason to
                                          have three or four of them. In C#, you're probably using VS.NET or
                                          else MonoDevelop.

                                          When you're in text editors, it's a bit more work. It's easier if
                                          everyone either agrees on a single editor (emacs, vim, whatever) or
                                          if they agree to work on multiple editors. Teams can decide. With
                                          Python, for instance, it doesn't matter as much. If you have something
                                          that doesn't crash a lot and uses BicycleRepairMan for refactoring,
                                          you're pretty much golden.

                                          Do you have multiple platforms, though? Mac v. Windows v. Linux is a
                                          bigger issue sometimes. If you're all using bash and the same editor
                                          at relatively similar release levels, it's not too bad. Eclipse is
                                          a great equalizer here.

                                          But as with the cited example, if someone crosses their arms and
                                          stamps their feet then you're in trouble. If they won't at least
                                          try to expand their options or won't "condescend" to using the
                                          tools that mere humans on their teams use, then you don't have
                                          and editor problem.

                                          Tim Ottinger
                                          http://agileotter.blogspot.com/



                                          ----- Original Message ----
                                          > From: MasaKevin Maeda <masakmaeda@...>
                                          > To: extremeprogramming@yahoogroups.com
                                          > Sent: Thursday, January 29, 2009 8:38:02 PM
                                          > Subject: [XP] Re: IDEs, Pair Programming, Pragmatic Thinking and Learning
                                          >
                                          >
                                          > I totally agree. At one place I worked there was one developer who refused to
                                          > switch to Eclipse, which everybody else was using, and that created lots of
                                          > friction. There was not valid reason to not unify, other than the developer
                                          > didn't want to learn Eclipse. Unfortunately the manager didn't put his stick on
                                          > the ground and the problem continued for months up until the time I left that
                                          > company.
                                          >
                                          > This will be a bump on the road until better integration between IDEs is
                                          > possible.
                                          >
                                          > Masa
                                          >
                                          >
                                          >
                                          > > Given that this is the XP list (and not a generic Agile list), my
                                          >
                                          > > preference is that all development environments are the same. Once
                                          >
                                          > > settled it becomes one less thing to think about so I can focus on the
                                          >
                                          > > real work. Partly this is about focus and reducing opportunities for
                                          >
                                          > > mistakes, and partly this is about a social declaration that this is a
                                          >
                                          > > team.
                                          >
                                          >
                                          >
                                          > >Greetings Steve,
                                          >
                                          >
                                          > >That's normally my preference, and those are good reasons. It does run the
                                          >
                                          > >risk of being insensitive to those with legitimate physical needs for
                                          >
                                          > >customization to their development environment. I think there is some
                                          >
                                          > >value in investing in enhancing IDEs to support rapid configuration
                                          >
                                          > >switching (by pulling down profiles).
                                          >
                                          >
                                          > >Jeff L.
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          > [Non-text portions of this message have been removed]
                                          >
                                          >
                                          > ------------------------------------
                                          >
                                          > To Post a message, send it to: extremeprogramming@...
                                          >
                                          > To Unsubscribe, send a blank message to:
                                          > extremeprogramming-unsubscribe@...
                                          >
                                          > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                          >
                                          >
                                          >
                                        • Brad Appleton
                                          ... Interesting ... the above makes the case for treating standardizing on an IDE to be basically an extension of the need for a common coding standard for
                                          Message 20 of 26 , Feb 1, 2009
                                          • 0 Attachment
                                            Steve Freeman wrote:
                                            > Given that this is the XP list (and not a generic Agile list), my
                                            > preference is that all development environments are the same. Once
                                            > settled it becomes one less thing to think about so I can focus on the
                                            > real work. Partly this is about focus and reducing opportunities for
                                            > mistakes, and partly this is about a social declaration that this is a
                                            > team.

                                            Interesting ... the above makes the case for treating "standardizing on
                                            an IDE" to be basically an extension of the need for a common "coding
                                            standard" for the team

                                            --
                                            Brad Appleton <brad {AT} bradapp.net>
                                            Agile CM Environments (http://blog.bradapp.net/)
                                            & Software CM Patterns (www.scmpatterns.com)
                                            "And miles to go before I sleep" -- Robert Frost
                                          • Adam Sroka
                                            ... I think that it depends very much on the language. If we are working in a common scripting language and the issue is, I like vi, he likes emacs, But
                                            Message 21 of 26 , Feb 1, 2009
                                            • 0 Attachment
                                              On Sun, Feb 1, 2009 at 6:53 AM, Brad Appleton <Brad.Appleton@...> wrote:
                                              > Steve Freeman wrote:
                                              >> Given that this is the XP list (and not a generic Agile list), my
                                              >> preference is that all development environments are the same. Once
                                              >> settled it becomes one less thing to think about so I can focus on the
                                              >> real work. Partly this is about focus and reducing opportunities for
                                              >> mistakes, and partly this is about a social declaration that this is a
                                              >> team.
                                              >
                                              > Interesting ... the above makes the case for treating "standardizing on
                                              > an IDE" to be basically an extension of the need for a common "coding
                                              > standard" for the team
                                              >

                                              I think that it depends very much on the language. If we are working
                                              in a common "scripting" language and the issue is, "I like vi, he
                                              likes emacs," But both work equally well then I think this can be
                                              worked out by the pairs at each pairing session. If we are developing
                                              in a language like Java or C#, or even Smalltalk, where the tools are
                                              very much a part of how we think about and approach the code then it
                                              seems worthwhile to come to a decision as a team and stick with it.
                                              For many environments some combination of the two might be appropriate
                                              (i.e. agree on some tools that are material to how we approach the
                                              code, allow for personal preferences when it seems less likely to have
                                              an impact.)
                                            • Steve Berczuk
                                              ... This is an interesting question: how much conformity is necessary to have the team be effective, and at what point does conformity discourage the team to
                                              Message 22 of 26 , Feb 2, 2009
                                              • 0 Attachment
                                                On Thu, Jan 29, 2009 at 3:15 PM, Jeff Langr <jeff@...> wrote:
                                                >> Given that this is the XP list (and not a generic Agile list), my
                                                >> preference is that all development environments are the same. Once
                                                >> settled it becomes one less thing to think about so I can focus on the
                                                >> real work. Partly this is about focus and reducing opportunities for
                                                >> mistakes, and partly this is about a social declaration that this is a
                                                >> team.
                                                >
                                                > Greetings Steve,
                                                >
                                                > That's normally my preference, and those are good reasons. It does run the
                                                > risk of being insensitive to those with legitimate physical needs for
                                                > customization to their development environment. I think there is some
                                                > value in investing in enhancing IDEs to support rapid configuration
                                                > switching (by pulling down profiles).
                                                >

                                                This is an interesting question: how much conformity is necessary to
                                                have the team be effective, and at what point does conformity
                                                discourage the team to avoid learning new things... ? This is still
                                                an issue when using one IDE: you still need to standardize in a common
                                                tool set right down to all of the plugins, else you risk either
                                                breaking someone else's configuration or needing to take extra steps
                                                to NOT use the checked in configs.

                                                (As a concrete example: consider a project using maven and eclipse:
                                                the m2-eclipse plugin works well but if you're using it, someone who
                                                is not can't use your IDE files.... Is that important? )

                                                Ideally I tend to prefer generating configs from the build scripts and
                                                not rely on checked in IDE configs. (even if you pick an IDE...) this
                                                seems consistent with the Integration Build being the definition of
                                                "it works."


                                                Steve

                                                --
                                                Steve Berczuk | steve@... | http://www.berczuk.com
                                                SCM Patterns: Effective Teamwork, Practical Integration
                                                www.scmpatterns.com
                                              • Charlie Poole
                                                Hi Steve, ... That s the first thing a team has to decide when setting up a coding standard: how much to standardize. I favor a pretty lean standard but some
                                                Message 23 of 26 , Feb 2, 2009
                                                • 0 Attachment
                                                  Hi Steve,

                                                  > On Thu, Jan 29, 2009 at 3:15 PM, Jeff Langr
                                                  > This is an interesting question: how much conformity is
                                                  > necessary to have the team be effective, and at what point
                                                  > does conformity discourage the team to avoid learning new
                                                  > things... ?

                                                  That's the first thing a team has to decide when setting
                                                  up a coding standard: how much to standardize. I favor
                                                  a pretty lean standard but some teams establish quite a
                                                  lot of structure.

                                                  > This is still an issue when using one IDE: you
                                                  > still need to standardize in a common tool set right down to
                                                  > all of the plugins, else you risk either breaking someone
                                                  > else's configuration or needing to take extra steps to NOT
                                                  > use the checked in configs.

                                                  Most IDEs I use separate project structure from personal settings.
                                                  Personal settings usually are not checked in. To the extent that
                                                  this is not possible, I'd say the IDE is at fault.

                                                  Charlie

                                                  > (As a concrete example: consider a project using maven and eclipse:
                                                  > the m2-eclipse plugin works well but if you're using it,
                                                  > someone who is not can't use your IDE files.... Is that important? )
                                                  >
                                                  > Ideally I tend to prefer generating configs from the build
                                                  > scripts and not rely on checked in IDE configs. (even if you
                                                  > pick an IDE...) this seems consistent with the Integration
                                                  > Build being the definition of "it works."
                                                  >
                                                  >
                                                  > Steve
                                                  >
                                                  > --
                                                  > Steve Berczuk | steve@... | http://www.berczuk.com
                                                  > SCM Patterns: Effective Teamwork, Practical Integration
                                                  > www.scmpatterns.com
                                                  >
                                                  > ------------------------------------
                                                  >
                                                  > To Post a message, send it to: extremeprogramming@...
                                                  >
                                                  > To Unsubscribe, send a blank message to:
                                                  > extremeprogramming-unsubscribe@...
                                                  >
                                                  > ad-free courtesy of objectmentor.comYahoo! Groups Links
                                                  >
                                                  >
                                                  >
                                                  >
                                                • John A. De Goes
                                                  ... This is a really great thing about UNA: everything is split into My and Team . If you add a Team Tool, then it s accessible to all members of the team.
                                                  Message 24 of 26 , Feb 2, 2009
                                                  • 0 Attachment
                                                    On Feb 2, 2009, at 9:18 AM, Steve Berczuk wrote:
                                                    > This is an interesting question: how much conformity is necessary to
                                                    > have the team be effective, and at what point does conformity
                                                    > discourage the team to avoid learning new things... ? This is still
                                                    > an issue when using one IDE: you still need to standardize in a common
                                                    > tool set right down to all of the plugins, else you risk either
                                                    > breaking someone else's configuration or needing to take extra steps
                                                    > to NOT use the checked in configs.
                                                    >


                                                    This is a really great thing about UNA: everything is split into "My"
                                                    and "Team". If you add a Team Tool, then it's accessible to all
                                                    members of the team. If you add a "My" tool, then it's accessible just
                                                    to you. You can drag & drop a tool from "My" to "Team" or visa versa.
                                                    So you get the personalization that every developer wants, but also
                                                    the standardization that the team needs, and the flexibility to
                                                    fluidly promote personal customizations to the team.

                                                    I've yet to see any other tool take that approach. Tools are too
                                                    focused around the individual to give much care for the needs of the
                                                    team.

                                                    Regards,

                                                    John A. De Goes
                                                    N-BRAIN, Inc.
                                                    The Evolution of Collaboration

                                                    http://www.n-brain.net | 877-376-2724 x 101
                                                  • Steve Freeman
                                                    Hi Paul, So maybe everyone using two IDEs is a special case of everyone using the same one? I ve often run both over the same directory to get the advantages
                                                    Message 25 of 26 , Feb 3, 2009
                                                    • 0 Attachment
                                                      Hi Paul,

                                                      So maybe everyone using two IDEs is a special case of everyone using
                                                      the same one? I've often run both over the same directory to get the
                                                      advantages of each.

                                                      S.

                                                      On 30 Jan 2009, at 09:47, simmonspa wrote:
                                                      > So I beg to differ, I think two IDE envs works and allows the
                                                      > developers to choose their most comfortable working env. At some
                                                      > point natural forces may lead to one or the other. As team lead or
                                                      > agile coach I recommend you watch for signs of conflict within the
                                                      > team or complications in IDE config, be ready to make a partially
                                                      > unpopular decision for the greater good of the team.

                                                      Steve Freeman
                                                      http://www.mockobjects.com

                                                      Winner of the Agile Alliance Gordon Pask award 2006
                                                    • Adam Sroka
                                                      ... Sometimes the tool itself provides a solution. For example, recent version of IDEA allow importing/exporting Eclipse .project files. So, you could
                                                      Message 26 of 26 , Feb 3, 2009
                                                      • 0 Attachment
                                                        On Tue, Feb 3, 2009 at 1:38 PM, Steve Freeman <smgfreeman@...> wrote:
                                                        > Hi Paul,
                                                        >
                                                        > So maybe everyone using two IDEs is a special case of everyone using
                                                        > the same one? I've often run both over the same directory to get the
                                                        > advantages of each.
                                                        >

                                                        Sometimes the tool itself provides a solution. For example, recent
                                                        version of IDEA allow importing/exporting Eclipse .project files. So,
                                                        you could "standardize" on Eclipse and still get away with using IDEA
                                                        (With just a little bit of pain that seems to be decreasing with each
                                                        IDEA release.)
                                                      Your message has been successfully submitted and would be delivered to recipients shortly.