Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Journal of nicholas (3034)

Saturday November 25, 2006
05:20 PM

doing without a TARDIS

[ #31715 ]

Dear lazyweb,
There is much outsourcing of software development, often to teams in places far flung around the world. However, my impression that is that this is usually wholesale outsourcing - i.e. entire projects or subprojects are specified and assigned to the the geographically remote team. Am I right in think that it is rare for organisations to attempt split site development of the same codebase? Does the lazyweb know of any examples of successful split site development with geographically and temporarlly remote teams? If so, what are the tricks to overcoming the obvious barriers to effective "internal" comunication?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I think the article by Alexander Cockburn that Ovid referenced to here has some things to say about distributed development, and they apply to development of perl itself.

          Linkname: Journal of Ovid (2709)
                    URL: http://use.perl.org/~Ovid/journal/30503 [perl.org]
     
  • split site development of the same codebase

    Wouldn't that fairly accurately describe a project such as ... I don't know ... Perl!?!

    I believe you have some familiarity with how that works :-)

    I'd have thought that in a commercial project, the main difference would be that a project manager would be able to step in and "make a call" in the case of conflict or disagrement.

    • From my experience in working with Perl is that being several timezones apart from the others can be a bit of a challenge at times. At least with open source, people are generally available. At work, people tend to be available only during the eight to ten hours they are expected to be there. So, if your separated by eight hours or more, you may never reach some people in the office ever. That's where I guessing where the challenge comes in.

      • You've expressed the distinction better than I was going to. In my experience volunteer developed open source (seems) to be different and therefore easier for a couple of reasons:

        • People are generally available for more hours, so lack of overlap is not such a problem
        • People are generally working on individual subsections of the code, so don't conflict (and so don't need communication to resolve that)
        • People are generally not working full time, so the sheer pace of development is slower. (Or at least, the a