Onsite Designer: I think we have Class A, B and C with so and so relationships and methods. This is what they should do. Ok great, I have a design I will send it to you offshore folks and you can code it up.
Offshore Programmer: Ok. Sure. It sounds great.
And so ends the design briefing conversation. Team of offshore developers receive the design and start implementing it. Halfway through coding, a design anamoly pops up. Offshore developer A discusses it with offshore developer B. “How is this going to work? I don’t understand why the design has so and so relationship laid out. This doesn’t look like its going to work.”
Its 10 AM in Shanghai(or Bangalore, or Moscow).
Offshore developers continue their discussions and come to a possible work-around. What do they do now?
1. Send out an email to the onsite designer explaining everything and do nothing further for the day.
2. Wake up the designer this very moment and have a telephone discussion.
3. Make the proposed change, send out an email explaining the rationale and keep working through the code.
4. Code up the design as stated with the obvious bug in it.
Here is what typically might happen, depending on the type of offshore organization:
1. Send out an email to the onsite designer explaining everything and do nothing further for the day: An outsourced project to a CMM level x company. Developers do nothing till they have all the changes outlined and documented on a few dead trees.
2. Wake up the designer this very moment and have a telephone discussion: This scenario will not happen. Ok, will happen very rarely. Offshore programmers do not call their counterparts at home. Even if the outsourced company has onsite people who maybe called, they will not call the clients at home either.
3. Make the proposed change, send out an email explaining the rationale and keep working through the code: Offshore branch of the parent company. Everyone belongs to the same organization with offshore developers having some flexibility in terms of what changes they can make. This is bound to piss-off the onsite designer, who will try hard to protect his/her turf. Ok maybe its an organization with peace loving people, who are working together to build a great product. Still, the very notion of separation of design versus coding activities will be a constant source of conflict.
4. Code up the design as stated with the obvious bug in it: An outsourced project being done by a team of relatively inexperienced team who are developing in a culture that does not foster taking initiatives. They do what they are told. Period.
This entry was written by , posted on October 28, 2005 at 12:15 pm, filed under Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.