Would you like off/near-shore with your fries sir?

Today almost every investment bank I’ve worked for (10+ at the last count) has ventured down the off-shore/near-shore route - be it Glasgow, Europe, India or Asia.  It’s easy to see the cost justification.  However, it’s harder to understand the actual impact to development when part or all of the implementation team is at a different location from the project manager/team leader/on-shore team members.  If the off/near-shore team has no understanding of a trading floor, or the requirements and demands of a trader, how can they hope to deliver the correct business solution? 

From where I sit, off/near shore development requires more management than square mile projects.  What red flag issues should you look out for on a project that has part of the implementation team off/near-shore?  Here’s my list:

• Over engineering of the solution - often highlighted by the complexity of the code base and time it takes to track down and fix issues.
• Lack of sensible XP practices:
• Automated build
  • Unit tests
  • Test environment
  • Coding standards
• No delivery
• Prototype only delivery
• Lack of communication with on-shore team
• No sense of “drive” to deliver a solution
• Empire building
• Information hiding from the on-shore team.
• Under engineering - fundamental failure to understand and code for scalability and threads

Don’t get me wrong, not every off/near shore development incur pain, most work seamlessly and deliver business solution to the trading desk.

~ by mdavey on August 15, 2007.