I have some opinions of my own, and some anecdotes from friends and colleagues, but I'd love to hear more insight from fellow developers.
Thanks!
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. :-)
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.
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!!
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.
- 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.
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.
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.