Hi there!

Sorry to be late to the discussion. I've been in both sides and I have
to say it's pretty damn difficult to get it right. Very, very
difficult.

If you are the one outsourcing (sending work outside) you usually do
it either because you don't have the money or you don't have the time
(which is money). My experience is that actual savings are much, much
less than you would expect.

Some notes:

* Code reviews take time (that you don't have, that's why you
outsource). But if you only review at the end of the project, be ready
for surprises.
* Common sense is definitely NOT the same all over the world. Is not
even in the same country, no matter which country you choose. So don't
expect people to solve the same "common sense" situations as you
would.
* The recipe to avoid common-sense-solving situations is writing a
detailed specification. But writing detailed specs takes VERY LONG
time (that again, by definition, you don't have) plus is very boring.
* Time and cultural differences ARE a bigger deal than you might
initially think.
* Maintaining someone else's code is probably 2x times more difficult
than your own code.
* I think it's very difficult to make people feel *your* problems as
*their* problems. Say something has to be changed quickly for whatever
the reason. If the developer is by your side, he/she will see your
face, your tension and he/she will be much more empathetic and
probably feel much more involved. Trying to express that very same
feeling to someone 10.000 miles away is not always easy.

Don't want to extend me much more. To sum up my experience I'd say
that it's NOT worth it _unless_ you are big company with resources
dedicated to establish the workflow and closely follow up the work in
progress.

Cheers!

Juan

On Thu, Nov 6, 2008 at 3:44 PM, Merrill, Jason
<[EMAIL PROTECTED]> wrote:
>
>>>I agree with Joel; your best bet is to provide a highly detailed
>>>design spec with complete API, and also provide guidance on what
>>>components to extend, etc. The downside is that it takes a lot of time
>>>to do all of this work, and depending on your particular situation, it
>>>may be unrealistic.
>
> Yeah, had done that, but not in great detail.  An API would have been
> too much.  The project was a learning game, and in my mind I couldn't
> justify spending a huge amount of time writing very detailed design
> specs, because that could take almost as much time to think about and
> write as it would be to sit down build the game.  I'm very much in favor
> of abstraction, but they took abstraction way too far, and really to the
> extreme in my opinion, where the benefits of abstraction are completely
> lost.
>
> Thanks everyone, I'm definitely going to insist on more frequent code
> reviews with them.  I guess I put too much faith in them last time! :)
>
> Jason
>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>



-- 
Juan Delgado - Zárate
http://zarate.tv
http://dandolachapa.com
http://loqueyosede.com

_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to