Offshore Improvements

There’s been a lot of press about offshore development—both good and bad. Book after book has touched on the issue, along with reams of magazine articles. In fact, it would be impossible for one article to tackle all the pros and cons of moving IT functions offshore. Instead, I’ll examine problems and solutions for a specific, common scenario: Software development design done in the United States and programming and unit testing conducted offshore.

Quality and Costs
I often hear managers doing offshore software development boast, “They can do it wrong four times before I hit my break-even point.”

This may be true if you’re looking only at the difference between the hourly rates of offshore and in-house programmers, but other expenses must be considered: long-distance communication, a more detailed design effort, additional and redundant testing, additional management, and potentially delayed implementation.

Much of the difficulty in offshore software development arises from the cultural and language divide. Generally, offshore companies have employees who are fluent in English, but it’s their second language. This introduces subtle differences in the meanings of words and concepts, and is further complicated by the fact that few, if any, of these offshore programmers have actually spent time in the client country.

The cultural divide often centers on defining the correct way of doing something. It may be reasonable to expect a U.S. programmer to know that you can’t put someone’s age on publicly viewed documents, but in other countries, age may be a perfectly normal data item to be shared. This is a simple and obvious example, but this and other differences creep into the resulting software and need to be factored out later.

Politeness, ironically, can further widen the cultural divide. Many U.S. companies whose projects have floundered offshore have learned that in non-Western cultures, “yes” sometimes means “maybe” or flat-out “no.” A brusque, American-style refusal is considered rude in some non-Western cultures, and an initial can-do response is often followed by a can’t-do reality that necessitates extensive rework that’s far more expensive than doing it right the first time. Misunderstandings based on cultural and communication clashes can and will drive your costs higher.

Additional Integration Cycles
As I noted, a client’s age appearing on a Web page may not be caught as an error by an offshore company during its testing cycles. This piece of data could potentially not be caught until user testing begins in the U.S.—causing significant delivery delays.

How do you mitigate this type of problem? The first line of defense is to put into place a lower-level design effort than is normally used with onsite programmers. This will be more costly than your current efforts, since your U.S. designers are paid a premium over mid-level programmers who would normally do design refinements.

The second line of defense is to send requirements with predeveloped test scripts or programs—a variation of Test Driven Development (TDD). These test scripts will help offshore programmers get it right the first time. For example, try asking for a simple Web service. First, I’ll go through the example the wrong way with a weak design and no TDD testing, and then examine the right way, with a stronger design and a TDD approach.

The Wrong Way

• The client e-mails a requirement to the offshore company: Create a Web service that returns the area of a circle when you pass it the radius of the circle. This is the entire requirement, seemingly simple enough.
• An offshore programmer writes the service, but uses the wrong formula: 2πr instead of πr². He uses a single data type to return the result.
• Unit testing is completed. The programmer checks the answer against a hand-calculated answer and decides it passes, again using the wrong formula.
• Integration testing takes place in San Diego, where a problem shows up in higher-level modules. It’s eventually traced back to the faulty formula.
• The error is called back to the offshore programming company.
• The programmer realizes that he used the wrong formula and makes the correction.
• Unit testing is repeated.
• Integration testing is restarted in San Diego.
• A bounds problem is encountered when testing very large numbers.
• Again the error is called back, the programmer changes the data type to a double, and testing restarts.

The Right Way

• The client e-mails a design to the offshore company, including what is passed to the routine and what is returned: the data types that are expected, the formula to use and the range of accepted values. Error message text is also included in the design.
• The U.S. company writes a testing program for the Web service: a series of tests for passing the minimum number, maximum number, number below minimum, number above maximum, non-numeric values, zero and negative numbers—each comparing the error response with what’s expected. This process is often done using the NUnit or JUnit programs for .NET or Java users, respectively.
• The offshore programmer writes the program and uses the testing program sent to him for unit testing. If the formulas are confused at this point, the test program will discover it very early in the process.

“The Right Way” corrects several problems:

• The formula should have been in the requirement, even though it may seem obvious.
• The data types need to be spelled out, as do the error conditions.
• The addition of the testing program written by the client company reduces errors that are turned in for integration testing at the client location.

Personal Power
When deciding on an offshore company, the personal approach is essential. An ongoing relationship with your offshore programming company can help you avoid the kinds of cultural clashes that hamper success. First, talk to several contenders to review different capabilities, rates and depth of staffing. Also, make sure they aren’t overloaded with work. If they are, they won’t be able to pay the kind of attention that your project requires.

Visit their offices—you can tell a lot about a company by just visiting it. While you’re standing in their building, you can get a more accurate feel for the operation beyond the stateside sales representative’s party line.

Plan on periodically sending your project manager to the offshore office, just to keep the relationship thriving. Remember, when all communication takes place via e-mail and video conferencing, you can’t go out and have a beer with your counterpart at the end of the day—and camaraderie can go far in crossing the cultural divide.

Have a high-quality video conferencing setup to facilitate communication. This isn’t as effective as face-to-face meetings, but it’s adequate.

Break down your programming tasks as low as possible. Offshore companies generally bill by the hour. If they don’t have tasks for their staff, they start looking for something they can work on, even if it isn’t ready. This can drive up your costs and give you almost nothing in return. If you break down the tasks into small enough increments, it will be much more difficult to cover staffing with your charge card.

Offshore sourcing of software development can save you money—if you’re careful. Here are some points to consider before moving forward with an offshore project:

• The amount of money saved is less than the difference between using offshore and in-house programmers.
• The risk of schedule delays is greater when using offshore IT services.
• The design effort required is greater and more costly.
• Have in place a Test Driven Development approach, sending test scripts with every requirement before the software is written.
• If you aren’t experienced in offshore relationships, bring in someone with international experience to help you cross the cultural divide. Whether your offshore expert is on staff or not, it’s preferable that he stop by one or two days a week as the project is started and monthly thereafter. And remember, don’t hire someone suggested by the offshore company’s sales rep.

Despite its risks, offshore development is no longer an experiment—for many companies, it’s a necessity. With a canny combination of personal and process techniques to facilitate communication and track errors early on, you can avoid disaster and make your offshore project profitable.