It really depends on what level of design patterns were used. The best way
to prepare for making changes is to provide the API you expect to be able to
use. Possibly created with something like
gModeler<http://www.gskinner.com/gmodeler/app/run.html>(although there
may be a better option for as3). In a best case scenario,
you should never have to edit any of the existing classes, just extend or
compose them as needed. If the class package delivered has your expected
api, you should only have to write adapters to tweak what you need without
making risky changes to existing classes. The package should also be heavily
commented and include signatures.

It's fairly rough ground to cover since approaches to common problems can
vary and ultimately what you are paying for is one developers approach over
another. My brother was hired at a company who was already knee deep in
development with an indian firm and soon found himself teaching them and
practically holding there hand. They were charging a competitive price so he
understood his employers decision so sometimes it just comes down to
sacraficing one node of the iron triangle for another.

On Wed, Nov 5, 2008 at 10:50 AM, Merrill, Jason <
[EMAIL PROTECTED]> wrote:

> I'm going to throw a question out there to see if anyone has experienced
> something similar to this.  Didn't get any responses on Flash_Tiger.
>
> If you have ever outsourced some Actionscript work to an outside vendor,
> have you ever struggled with how to spec out how you want them to code
> it?
>
> Reason I ask is we've had bad experiences with some vendors in India in
> the past producing poor Flash/Actionscript sourcecode (we require them
> to provide sourcecode in the contract, so if need be, we can tweak minor
> things later). We've had better luck with U.S. vendors (nothing against
> India or Indians at all, that's just been our experience). So we
> decided to spec out how we would like them to code it (in general, not
> extremely specific - for example, use AS3, use external classes, comment
> the code, if they use a framework, tell us what it is, etc.). So the
> new vendor we used in India did all this (did a pretty good job with the
> final product), - they complied with our specs just fine, but they went
> overboard in the coding in my opinion. They over-coded by making the
> sourcecode EXTREMELY abstract, it was nearly impossible from looking at
> it to determine where to make minor tweaks. There is virtually no way to
> tell where to make a change, or what the change should be. They DID
> comment their code, but it's at the function-level - not at the bigger
> overall picture on how everything fits together.
>
> It's not a matter of being able to understand the code, I humbly
> consider myself a semi-near-expert (not a guru, but certainly no where
> near a novice) in Actionscript. The problem is figuring out how all the
> classes tie together to make what you see on the screen. I could figure
> it out, but it could take a very long time, and would require a lot of
> diagramming to map everything out. So instead we are having to go BACK
> to this vendor to have them make the change. I don't know if they
> over-coded because they thought that is what we wanted, that's the only
> way they knew how to tackle the project, or if they did it to ensure if
> there were ever any updates, only they would make the changes, thus
> ensuring future work (if so, pretty smart, but sneaky, which angers me).
>
> Anyway, that's the story, my general question is how do you define specs
> for a vendor to ensure you get good sourcecode back, but it's not overly
> abstracted, over-coded work?
>
> Jason Merrill
> Bank of America Instructional Technology & Media * GCIB & Staff
> Support L&LD
>
>
>
> _______________________________________________
> Flashcoders mailing list
> Flashcoders@chattyfig.figleaf.com
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>



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

Reply via email to