Letters to the Editor

Readers speak out about offshore Java development

Emails began flooding our inboxes almost immediately after we published Loren Siebert's article "Take Java Offshore." Though many readers appreciated Siebert's insights, some developers, especially those in the US, don't agree with Siebert's outsourcing strategies. To present both sides of the picture more fairly, we're publishing some of our readers' own experiences with offshore outsourcing in this month's Letters to the Editor.

'Take Java offshore'

Loren Siebert

Loren,

Your article contains a number of interesting points and comparisons. However, I would expect an article for a large publication to be more even-handed.

I have worked with two separate offshore development teams, and they fit right into the bell curve of the local teams I have worked with. One was exceptional technically, but quite inflexible about requirements changes. The other presented a good technical image, but couldn't write good code. I know because I reviewed all the code from both projects.

Some statements from your article such as:

"Over the course of a year, your project team may experience 100 percent turnover or more, and yet continue to gain momentum as though they had been together all along."

a nd

"Your Java project may require only five engineers, but you'll get the collective experience of the dozens or hundreds of engineers across the company."

present a rose-colored image that may represent the very tip of the curve, but certainly does not correspond with my experiences or those of my peers and coworkers for offshore or local teams.

Some topics that may create a more level view are:

  1. Offshore teams tend to use technology for technology's sake. Most companies are in business to make money, not to pay geeks to experiment with all the latest and coolest stuff. My experience with offshore teams (which also applies to most locals) is that the solution ends up much more complicated than necessary.
  2. You mention this, but only briefly: the time it takes to document everything locally eats significantly into the cost savings of using an offshore team.
  3. The inflexibility of the "over-the-wall" approach means that you can receive software that meets requirements, but isn't the software you wanted.
  4. Documentation written by nonnative English speakers must often be rewritten.

In conclusion, offshore developers aren't superheroes, and offshore development suffers from many of the same issues that plague large upfront development.

Greg Moulliet

Greg, Thank you for reading the article and taking time to comment on it. Most of that article's content came from my own experience using offshore teams. It's certainly possible that I have been unusually fortunate in my experiences, causing me to paint what you call a rose-colored image. As I continue to gain experience with offshore development, I suspect that I will be able to present a more even-handed story. To address some of your points: I agree completely with your concern about offshore teams using technology for technology's sake. This behavior is latent in the breasts of all software engineers throughout the world. It's a bug and a feature. You are right, I should have been clearer about documentation time. I would never recommend outsourcing the business documents (technical specs, functional specs, and so on) to an offshore team. I doubt that there are any cost savings to be had here, so it should be kept in-house. Regarding your third point, I have heard those words quoted to me by several people now, and I must say that they just don't jive with my experiences at all. I suspect the big difference here lies in how the offshore team bills you for work completed. If it's billed on a per-person rate, then you should have all the flexibility you need. If you decide halfway through the spreadsheet project that you want a word processor instead, your offshore team will gladly keep billing you until you get what you want. But if an offshore team bids on a firm fixed-price project, then you are subject to all the inflexibilities that firm fixed-price projects have locally. Your fourth point is a good one. If your relationship with the outsourcing supplier is a short one, or if for some reason you decide to take the code back in-house, you may have some redocumentation problems. Loren Siebert

Loren,

I run a small development company in South Africa. I have noticed that the U.S. seems to outsource to India, Russia, and so on, but not too much to South Africa. The United Kingdom sends some work down here, but it seems that the South African talent just moves to England.

As a person who seeks to persuade U.S. companies to outsource to South Africa, I was wondering if you could offer any tips in regards to that direction.

Your article indicated the pros of outsourcing, but didn't specify how those companies can find foreign companies to outsource to, or how foreign companies can market themselves.

Bruce Lowe

Bruce, You can find outsourcing suppliers all over the place -- Yahoo has a category full of them, and a Google search will get you more than you can possibly investigate. Outsourcing development firms market themselves in a number of traditional ways (advertising, conferences), but they also do direct emailing and cold calling to generate leads. It can be overwhelming and that's why I advocate leveraging an existing relationship whenever possible. Referrals go a long way in the outsourcing development market. Good luck, Loren Siebert

More readers respond to Loren's article:

I question the value of outsourcing application development and note a few problems with outsourcing that were not mentioned.

Due to the recent changes in the U.S. economy, corporations have been forced to reduce the number of nonessential projects. That leaves us with only essential projects, most of which are likely to contain intellectual property and techniques valuable to the corporation. I wonder how many corporations are willing to part with this intellectual property so that foreign developers can work with it? The security aspect seems extremely difficult to manage -- how do you know where your intellectual property is going once you release it into the hands of outside developers?

In addition to security, I also wonder about the creative problem-solving skills of foreign developers. I highly doubt that universities in India or Russia provide their students with a focus on creative thinking in the same manner as U.S. universities. Rather, they focus more on book knowledge (I know this to be the case in many European schools). Most highly skilled students tend to leave their homelands in search of better locations, such as the U.S.

As a developer and a manager, I have never seen a project come across my desk that I would outsource. In most cases software that is a candidate for outsourcing is probably already available from a software vendor.

Anthony Eden

I generally agree with the misconceptions that Loren notes, but I do see conflicts in some advantages.

I don't agree that costs are low. Add the hourly rate (which is not always 0), your telephone bill, other communication bills, and possible onsite visits from offshore developers. Compare the cost with the productivity (especially during crisis situations). Your best bet is to keep development local.

I do agree that you can add headcount quickly. But the productivity is questionable.

Another common mistake that companies make (which is why we are seeing so many layoffs currently) is to bring/assign too many people on a project than necessary (since the labor is cheap). That creates chaos. Also because people in countries like India jump around to different companies (on average, they stay only for a year), there is always a learning curve involved throughout the year.

GE

This article did a great job of highlighting offshore development benefits. One point Loren missed was that some of the top offshore development companies in India are moving up the value chain. They already have achieved the highest certification (CMM Level5) and now have a talent pool not only experienced in technical knowledge, but also business-domain knowledge and software management techniques.

Vivek Bakshi

I can only speak from experience when I tell you that offshore development has led to a glut in mediocre developers both here and abroad. As a former Java/Smalltalk developer and now a director of technology, I simply will not use offshore developers. Why would I undercut my own salary potential? Also, average to awesome developers are available right here in the good ole U.S. of A. So I urge anyone interested in using offshore developers to use it as a last resort. If the talent cannot be found locally, then by all means, have at it. Sure you might save a couple of dollars, but at what expense?

Kevin J. Citron