80. Offshore Follies

Dazzled by lower labor rates, the executives launch an offshore development scheme that increases the complexity of communication among development sites.

One of the most reliable ways to elicit a debate among software managers is to bring up the topic of offshore development. Over the past fifteen years, the use of offshore software development and support teams has gone from fringe fad to industry staple, while remaining controversial. Some managers see offshore development as the inevitable path forward, while others see it as a desperate move by clueless cost-cutters. Still others see it as a potentially useful tool that brings with it significant but surmountable challenges. What just about everyone can agree on is that there are many ways for offshore development to go horribly wrong.

Here are a few of our favorite executive epiphanies that doomed the offshore adventures that followed:

• “From now on, when attrition occurs onshore, you will have to hire the replacement person in Franz Josef Land.”

• “It looks like we underestimated the amount of work required to complete the portlet component. I hear that there are three developers in Andorra who are not busy for the next two months. Let’s have them help the team here with that.”

• “Wow, the schedule for the next release looks really tight. The only way we can get enough developers on it is by going offshore. That will help us finish sooner.”

These statements reveal a lack of appreciation for the high cost of inter-site communication and inter-site iteration. Allocating work to sites almost randomly (as attrition occurs, for example) greatly increases the minimum required bandwidth between the sites. Similarly, if the manager from whom a first-line employee receives task assignments and feedback is at another site, the frequency and intensity of communication required between the sites are substantially increased.

The underlying principle here is nothing new. To control the complexity of a system, we have long been taught to partition the system, to minimize the complexity of interfaces among its major subcomponents. The same concept applies to the design of work flow in a development team. If the team includes groups of people who are in multiple locations—especially if some are in distant time zones—the stakes are raised considerably. We want to reduce the requirement for frequent, high-bandwidth communication and iteration across oceans. We want to avoid this:

How will you know if you’ve fallen into an offshore folly? Look for symptoms like these:

• Daily meetings at 6:00 A.M. (or 8:00 P.M.) throughout the development cycle so developers in both locations can sync up with each other.

• Three people onshore trying to manage the work of two developers offshore.

• First-line employees whose direct manager is more than four time zones away.

• An offshore site that does feature development work for six products, but ships nothing itself.

Having said all this, we do not want to discourage you from making use of offshore development resources. We have had success with offshore partners since the early 1990s. To make the most of their potential, consider this advice from the grizzled:

1. Iterate locally. Whenever possible, assign to a single site—either onshore or offshore—phases of the work that require rapid iteration.

2. Recognize that your first few uses of the offshore development model will take longer than they would have if you had done them onshore. Teams need time to develop the new muscles on which successful offshore development relies.

3. Realize that your offshore teams are not different from your onshore teams, in most ways. They want challenging, meaningful work to do. The labor markets in most offshore centers have become extremely competitive. Top software engineers in these markets have choices. They gravitate toward exciting work that gives them an opportunity to advance their skills. They flee from maintenance-only sweatshops.

4. Foster the purpose of each site. Sites need souls. While there are lots of factors that separate healthy sites from unhealthy ones, vibrant sites are usually characterized by a specific mission. They build a specific product or system, or a significant, nameable part of a larger product or system. Conversely, sites that contain many miscellaneous development and support teams with no specific shared purpose often exhibit low energy and low morale. When chartering an offshore development site, think first of how your teams will identify with the site’s mission.

These steps, especially the last, can help you avoid onshore follies as well.