Vitaliy wrote:

>>> What you're saying sounds logical, but my limited experience with
>>> distributed development has for the most part been negative.
>>
>> I have largely positive experiences. But you need to adapt to the
>> situation.
> 
> What kind of projects were these (complexity, duration)? How many people 
> were involved?

>From two to 40 people; from a month to about a year for a single project to
several successive projects over several years to a continuous
relationship; desktop-style applications, multi-layer web applications
(mostly business type apps), electronic/firmware embedded projects with or
without mechanical components or PC software that go with it.


> I'm genuinely interested in hearing about your positive experiences
> (maybe you can start a separate thread?). My limited experiences with
> outsourcing involved relatively small projects, requiring no more than
> one man-month of effort.

It doesn't have to be outsourcing. I worked for a few years first as
programmer and later as project/team lead for a software house that had its
whole operation based on distributed teams, with most programmers working
at home or their own offices (independently of whether they were employees
or contractors).

So from the perspective of that software house, they didn't outsource to
the remote team members, they hired them to work remotely. The main
advantage was flexibility: you don't have to scale your premises with the
project requirements. Another advantage is that people get to work
according to their own preferences. 

(Isn't that what one of the Agile phrases says? "Build projects around
motivated individuals. Give them the environment and support they need, and
trust them to get the job done." Depending on how you listen to this, it
can sound like "you can let them work at home" :)

It takes getting used to, though, and requires some special care. Some
things that we do in face-to-face contact without thinking much about doing
it we need to do more consciously when working remotely. It's easy to get
detached.


As for outsourcing, I think it is like with anything else: it's the
relationship. The first time may not be that efficient, but it can become a
working relationship, and efficiency then can increase quite a bit. This
process is IME not that dependent on distance, even though being able to
meet every now and then definitely helps.


>> This is true, if you only take the project. I, like most other people I
>> know, don't live my projects, I work on them. I have other things to
>> care for in my life, and the most effective method for running a
>> project may clash with the most effective method of running my life. So
>> again, it's about finding the overall maximum -- just with more
>> dimensions :)
> 
> What if you already have people in the same building, what's the problem 
> then? Most companies work this way.

That's ok, but my question was what if not? As always, it's not that
relevant here what most companies do, it is relevant what this company does
:) (as is for you, of course...)

My point was that what is efficient may depend on a number of constraints
that some methodology may not take into account.


> By the way, there are examples of executing successful distributed
> projects. But you still have face-to-face conversation and theory
> building -- documentation is not enough, you need to fly one of your
> team members to Russia to explain the theory to the Russian programmers.
> Always-on video links can also be helpful. 
> 
> The problem with documentation is, some things are difficult to explain
> in writing, and some are impossible.

Well, I am working in distributed teams all the time; physical interaction
with my team members is the exception. IME pretty much everything that can
be thought of being implemented can be documented; you don't have to write,
you can draw, too, you know, or send a prototype :)  There's something
about the dynamics of a team, of course, and sometimes it is crucial to be
together. But this may just not be possible within the constraints of the
project and the team members -- so I either work around it (if possible),
or let go of the project. 

Talking about "the theory": I guess that if it is so complex that it can't
be documented, it needs to be documented (because people will forget all
kinds of details along the way :) -- and if you have people on the team
that can't understand the documentation, it's either bad or the people
shouldn't work on tasks where they have to understand "the theory". For me,
the face-to-face meeting may be a good thing to convey the spirit of the
documentation, but it's no substitute for documentation of something that's
so complex that it is considered "indocumentable".

Gerhard

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist