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