Here is the view from the other side - I am an Indian, and I work for a big offshoring company and I have been working for the same client for last 8 years.

If you want quality, you can do the following - 1. Insist on interviewing each and everyone personally that they will put in the team. This will help you and also help people like me, in the past I had interviewed people for my team and rejected them but the managers always overrode me. 2. Do code review. 3. Make sure you have at least one or two guys in the team who are good communicators. This is very very important. Also to be absolutely safe, you may insist on someone who has lived a bit in United States, this will help you.

Believe me when I say we want to do good work and we work hard and some of us are even competent. :-) But whatever good was there is being demoralized and strangled by management and business realities.

I hope I don't get downvoted to oblivion. :-)

Not sure if you want the question answered, or your own conclusions confirmed.

There's no one answer to this, so the usual "it depends". What is your current development workflow? What is the application? the framework? etc

In general, if you can break the project up small enough pieces, off shoring can be successful. There's no reason why the quality has to be lower; these discussions tend to bring out people's prejudices. However, I think this requires an active technical project manager to deal with the process, and you'll likely do a good amount of work locally.

What doesn't work is the idea that you can feed a project description to an off-shore company and expect the same end product only cheaper (without significant headache in the middle, and even then it may not matter). This seems to be the typical model.

No. The biggest issue is the language barrier. Subtle language nuances that you never considered become very apparent. Compounded by the time difference that is typical, expect to be waking early, staying late, and/or waiting until the next day to get something done. I'd rather have one good programmer next to me than a team of five offshore.

I have hired and worked with "offshore" developers even though in a big corporate. Is it effective ? That depends on what your goals are. In our case, the goal was not to have the "best" or "crème de la crème" but just someone enough who can work with knowledge BAs and PMs onshore and get the job done. Cost: $10,000 per headcount/year.

At one point of time, my boss will ask me to interview a bunch of developers together. yes, like 7-8 in one room with teleconference. Goal is to select 2-3 out of them. Guess what was the most important criteria ? Communication skills!!

It can definitely work, but it has to be done right.

1) Don't go through the big firms with a flashy list of clients. The businesses practices many of these firms use are designed to extract value from you rather than provide value to you. There are good ones that are trustworthy, but you probably can't afford them.

2) Recruit and build your own team of handpicked developers. Once you have a couple of really good ones, use them to recruit their other talented friends.

3) Pick a country with a smaller time zone difference. Ideally you want to have some overlap where you can sync up early in the morning or at the end of the day.

4) Expect to fly out a few times to spin up the team and get them going. And even afterwards, expect to fly the devs in for a week or so every quarter. This is a good idea even with a distributed team within the US.

5) Treat offshoring as way to reach more talent, not particularly as a way to get cheaper talent. If you go in with that attitude, you'll find better quality devs and achieve your goals more easily.

My short experience is the following:

- offshore or no offshore, scattered teams will have a lot more communication problems (= waste of time, requirements not fulfilled, etc)

- if you outsource a product, you will eventually get something that looks like what you asked. As soon as you throw it to prod, publish or whatever applies, you will find many unexpected problems. These problems usually are identified much earlier if you develop in-house. Possible explanations: Quick questions could have flagged those issues, but because teams are in different timezones, probably those questions got lost in a "todo.txt" somewhere.

- if you have to outsource, I recommend that you have people in your main office actually working with the remote team (doing the same tasks - e.g. coding). This way you know the quality of the product from the inside, how good are the people developing it, how extensible it is, etc.

Imo, it makes sense to offshore concretely defined software tasks not part of your core infrastructure framework.

For example, if you need to research a new API, I would offshore that task in it's old self contained project.

When the results come back, your developers can learn from the research and spend the time integrating that work into the project.

For myself personally, I use fiverr.com to outsource a bunch of small tasks I don't have time with. Since I am more of a backend software guy, I tend to source weird javascript and css problems. Occasionally I would outsource some small Ruby work.

Cost of employee time might be lower, but cost of just about everything else is the same or higher. More training & quality control is necessary.

People keep doing it. I think the question is, does the lower prices compensate for the potential issues (remote, potential language issues, etc.) ?

Your CEO is like 10 years too late on this one, companies who offshored or outsourced mostly brought those projects back internal since. The companies that were successful got there by starting a development office in the country they wanted to ship work to, that's the only way to do quality control long-term. I've seen companies with less than $3M in revenue do it and then rent the team out to other people for projects. The contract outsourcing teams that were good realized how few of them there were, and then like any good American tech worker those teams raised their price. So the "myriad benefits" are: cost cutting by scraping the bottom of the barrel and accepting that in 3 years you'll have to pay an expensive grown up to redo it...and that's it.

If your CEO is bound and determined to warp you back to 2005, it helps to understand what you are renting when you contract tasks out. If you get a team of 10 people there's: one great coder, one pretty great coder, and 8 random shlubs they grabbed off the street. This absolutely includes contract development teams in the United States. The two good coders are the only ones you will be able to communicate with before you sign a contract. The money you pay them (cost: 1 good coder x10) goes straight to paying the two good guys and then the contracting company makes their margins off underpaying the 8 shlubs. Note none of these are management, project management, or anything else. At best one of the two guys is a Lead Developer but that isn't management.

So in order to do it effectively, you have to have an extra manager in your location whose entire job is to manage the offshore/outsourced team directly. Not a project manager, a literal manager of software engineers. He absolutely has to be able to do weekly code reviews because the two good guys aren't going to do it for the 8 other guys who need it. He has to watch that each of the 8 guys are doing work, checking in their own code (some of them will have their sister do it because that's how they got through college), and you have to have language in the contract where this in-house manager can jettison anyone who can't keep up. The price of that guy needs to be factored into the 'cost' side of the cost/benefit, along with the regular project manager and tech executive time at your end. These people will work twice as hard communicating everything twice to the remote team.

At this point you should be thinking "why don't I just hire this theoretical Managing Developer and then give him two mid-senior recs in-house and let them do the project themselves?"

You can try to offload trivial coding tasks to them but palidanx is right, do not dump infrastructure, foundational tech, or release engineering on them. They will screw it up and in the process they will screw up all your in-house people's work, too.