🚀 go-pugleaf

http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=97;

New World Order

From Distributed Development
Vol. 1, No. 9 - December/January 2003-2004 
by Edward Grossman, Editor, Queue

Outsourcing development means distributed development�and that means
trouble for the unprepared.

It seems that wherever you turn these days you read another headline
about the increasing popularity of outsourcing software development.
On a whim, I stopped by Google's news page where a search of
"outsourcing software development" produced eight stories on the first
page written in the last 24 hours (with the remaining two not
significantly older than that). No surprise, the headlines include
such frenzied folly as "outsourcing craze," "job fears," and the
latest entrant�"backlash." That last one is enough to trip my sensors
that global software development outsourcing is a cemented new feature
of the landscape. Once there's a backlash to something, you know it
has fully arrived.

This is the new world order: software development on a global scale.
As is almost always the case, this doesn't mean the entire technical
arm of a corporation breaking off and floating across an ocean in one
clean clump, but rather numerous small teams here and there "sharing
the pain" across time zones. Nowadays it's not atypical to have
multiple teams on multiple continents working on the same project.
It's not just financial pressures that come to bear and break
developers into teams. The sheer size�raw lines of code�of many of
today's projects means they're just too big for one group to handle on
its own. And whether teams are spread across a campus or across
multiple continents, distributed development affects the way that we
write code.

How does this affect software development? How do we deal with it?
Well, true to our mission, ACM Queue isn't going to answer any of
those questions. Instead, we've put together a collection of articles
on the topic that will help you reach answers of your own while facing
the technical, and sometimes not-so-technical, challenges of
developing software in a distributed environment.

First up we have Mike Turnlund, a director of engineering for a little
company you might know, Cisco. Mike has taken stock of all past
lessons learned as a way to explore what's hard about multi-team,
multi-site development. Tool selection, architecture decisions, Mike's
covered it.

Then we've got an insightful piece, "The Sun Never Sets on Distributed
Development," by Ken Coar, director of the Apache Foundation�and you
know managing the Apache project means managing a distributed
development process.

Of course this begs the question, if distributed development is so
hard, why aren't there better tools for it? Why can't we attach this
instant message to that line of code as a comment? Well, Li-Te Cheng
and crew from IBM ask the hard questions, and report on their findings
in "Building Collaboration into IDEs."

Judy and Gary Olson from the University of Michigan round out our
special report and dig at what is far too often the root of the
problems you'll face in distributed development: culture clashes. Read
their "Culture Surprises in Remote Software Development Teams" and get
a new perspective.

No issue of Queue would be complete without one of our interviews, and
this month we've done a distributed interview. For this, the West
Coast's Tony Wasserman, principal at Software Methods and Tools, rings
up East Coast rep Steve Hagan, head of Oracle's New England
Development Center in Nashua, New Hampshire, to see how Oracle handles
the new world order.

Despite the all-encompassing nature of distributed development and the
way it does (or soon will) affect us all, we managed to scare up a
couple of great articles on other topics for this issue. If you've
ever wanted to debug binary, don't miss James Whittaker and Herbert
Thompson's "Black Box Debugging." And then there's Gordon Bell�yes,
the Gordon Bell�with a self-diagnostic for vaporware-producing
businesses. Does your company qualify?

I might add that Eric Allman is particularly curmudgeonly in this
month's Curmudgeon column, "The Economics of Spam." Enjoy!
Q 

EDWARD GROSSMAN is responsible for Queue, so blame him if you don't
like it. In earlier incarnations he was a development project manager
at a still-in-business dot-com and a closet coder (his parents still
don't know�"Our son Ed? Oy, he works with computers, doing
something").