DevSmart

Engineering Success Offshore

Best practices for ensuring a productive outsourcing experience.

You don't have to be a management guru to know that outsourcing development to an offshore team can be a risky proposition. Poor collaboration is an issue in any team effort, but when that team spans geographic, linguistic and cultural borders, the stakes go up in a big way. Unless you manage things carefully, the cost savings expected from an offshore operation can quickly evaporate.

In my experience as lead architect in the development of an enterprise-scale ASP.NET C# application for a global financial institution, I focused closely on smoothly integrating onshore and offshore development. Here are some of the methods and techniques that have proven successful -- both in maximizing ROI and minimizing risk -- in our working relationship with the offshore team.

Daily Dialog
Naturally, communication across the entire team is essential. E-mail, documentation and project plans are all useful and necessary. An implemented process of guidance for testing and tracking defects, such as that promoted by Microsoft Visual Studio Team System, also goes a long way to keep everyone in touch. But live verbal conversation between team members still ranks as the most effective means for staying connected.

Time zone differences can make this difficult. Being located on the east coast of the United States at Greenwich Mean Time -05:00 creates a ten-plus hour barrier between us and the offshore team in India at GMT +05:30. Each day begins at 8:00 a.m. Eastern time with a dial-in phone conference with the offshore team, which is just ending its day at 6:30 p.m. When appropriate, we augment these calls with a LiveMeeting session, so all participants can view a shared desktop.

We consider this daily verbal dialog (which averages 30 to 60 minutes) to be a vital part of our process, in which requirements, design and general issues are openly discussed and the project is kept on-track. For locations further west in the United States where greater time zone barriers can make daily conference calls impractical, a good idea is to implement a call every other day, alternating the time so that the burden of meeting very early or very late is shared fairly between teams.

Plain English
The culture gap is another important issue. Fluency levels in English tend to vary, as do accents. Use of slang and metaphors can confuse even the most fluent non-native speakers, so be careful to avoid them both verbally and in writing. You'll also need extra patience when communicating, using carefully worded language and clear enunciation.

It's not unusual for foreign contractors to be reticent about speaking up. So make a point to reach out and solicit confirmation and response during your conference calls. Follow these guidelines, and not only will you boost morale, but you'll find that the communications gap will narrow over time.

Coherent Framework
One of the first goals I set out to achieve was to improve application architecture by applying proven patterns and practices. The allure for hiring more developers at lower cost by outsourcing must be tempered by the reality that offshore companies draw on a very large pool of developers with varying levels of skill and experience.

In our case, a large number of bright developers provided the muscle for writing a lot of code that successfully implemented key functionality. What was lacking, I found, was a coherent application framework. We needed to leverage the advantages of object-oriented design, yet inheritance and polymorphism were practically non-existent in the code the offshore team produced. Predictably, we ended up with a lot of duplicated and difficult to maintain code.

To resolve the issue, I was charged with shepherding the object model moving forward, designing an infrastructure of base classes and interfaces for the offshore team to run with and extend horizontally with concrete functionality.

DevTube
In our case, we needed more than conference calls to get our offshore developers working with the newly minted object model. So instead of just telling them how to implement concrete classes we opted to show them, by recording video tutorials of the process. A third-party product, like Camtasia Studio, can capture your on-screen activities to a file, which can then be included as part of your formal documentation set under source control. By having the offshore team view the videos and then discuss them in our daily conference calls, we were able to efficiently get everyone on the same page. The result: The team delivered all derived classes in advance of the release deadline.

A team is a team, no matter how large, dispersed or diverse. But for offshored projects, there's no doubt that the margin for error is reduced. By employing techniques like these, you can ensure that your distributed development effort goes more smoothly.
comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube