Offshoring: does it ever work?

Blatant plug: What you want is near-shoring. Canadian development shops and remote Canadian developers are like "Mexicans with sweaters." Lower cost-of-living, we have our family's health care taken care of while we work on your start-up, and our subsidized universities churn out a steady stream of new grads.

Add in the fact that we speak English (even if our spelling has idiosyncrasies like "cheque," "colour," and "centre"), the ease of flying back and forth, and the fact that we work in the same bloody time zone...

And one more thing: Major Canadian cities like Toronto and Vancouver are an incredible melting pot of cultures, so you can find people who speak English and French, Hindi, Mandarin, Cantonese, Greek, Spanish, or whatever else you may need as you build out your Global empire.

If you must go remote or outsource, I suggest looking North of the 49th before you look in South-East Asia.

Well, I can speak about the problems from the other side of the fence :)

Someone said on this thread that offshore works only when you give a very detailed specification of the project.

The biggest problem problem I'm facing every day is not having a way to get answers to my questions. There are many layers of intermediaries that filter out information and delay the answers. I do have to deliver the project and I can't always wait days or weeks every time I have a question. Most of the times I have to assume that you want a certain solution and implement it my way. Unfortunately, it's not always the desired one.

I can give you an example: someone wanted a payment system implemented but they missed giving me the library used by the payment processor. I had to wait few days to be able to get the library from them, only to find out that they gave me the wrong one (32bit instead of 64 bit)... and so on. There are many many little things like this that take time and could have been solved very easily through a phone call (or even an e-mail).

I'm not a junior, a have 10 years of experience (not all of the working offshore) and I can do your job pretty well... I know how to do it, but I have to know what you want. That's a part of the reason why you sometimes have to give very detailed specifications, not because of me but because of the people between you and me that don't do their job.

Not all companies do this though, some of them get it right. Daily scrums with everybody involved speaking on the phone help a lot. Giving me a way to talk directly to a competent person, also helps. Sometimes a simple yes/no answer makes a huge difference. When we start a new big project it helps to work on the same office, even for a few days. Don't be cheap, it may be cheaper to work with me but it's not that cheap, remember that I can very easily move to a different company or even country (and I'm not talking about the salary, but about everything else).

Yes. If you know what you want, can explain it simply, and it can be done simply and repeatedly, offshoring works quite well. It's far cheaper than doing it in-house.

However, if you miss any of the above, it's going to be a nightmare. The 'repeatedly' part is the key to making it cheap. 1-off solutions are cheaper in-house because of all the design work. Things that can be done repeatedly (like webscraping different sites) can be off-shored with great success, especially if you do the first couple in-house and create a good framework, and then just ask the offshore-company to repeat your success with like tasks.

It works very well if you establish a true partnership.

Our local employees do the design, strategy, and thought leadership. An on-site team from our partner sit face-to-face with us to be sure we have mutual understandings and good communication. The offshore teams do a variety of work, from coding, to system administration, to basic tech support.

I would not try to offshore just one project, or just one task. It took a couple years to smooth out how we work together... in the end, it works well for us.

(much lower day rate)

IMHO This is a key wrong assumption here. After many yrs in this business i am still surprised how many ppl fail to realize this simple fact. Project is doomed when they hire Indian Developers for $5/hour

Good developers charge premium anywhere! Local market of talents! Great developers are always busy and if you are happy to find someone cheap and available right now you are under serious risk. Of course there is cost of living factor but its not x5-x10 times savings! In fact cost of living in some parts of US is already lower than somewhere in Europe.

So lack of talent and high demand in one place will always continue to drive outsourcing to other places (both off- and inside US). Yes, it works

The question asks "Do mediocre programmers EVER create good software?"

The answer to that is no, but it really has nothing to do with offshoring. If you're going to go outside of the country to find cheaper talent, you should be looking for talent--just cheaper.

I've had brilliant results with a firm with developers Poland. It's not as cheap per man-hour as, say, India, but the results are great. I'm sure it's just a matter of some firms being better than others.

The keys as far as I can tell: - Developers should be managed by other developers. - You need frequent communication. Webex, IM, a ticketing system, and e-mail all have a place. - You have to have good people. This is the hard part in any country. You need to look for quality developers who happen to be cheaper due to their location.

As someone who managed off-shore projects, I think this model can be made to work only if the coding part is offshore. The design part would have to be done on-shore in a majority of cases. The problem with outsourcing design is that you may not have people who understand the business or the dynamics of the environment they are designing for.

It does work. More than you think.

The companies that are successful in outsourcing are not looking to get high quality software done cheap. They're looking for someone to take the burden of the whole process of developing software from the ground up from their basic (but vast and hairy) requirements.

This means, having a system in place to make sure every requirement that was specified was tracked and accounted for from some functional specification document right through the final UI pages and test cases. It means having a system in place so that when QA discovers that requirement 4.3.1 doesn't have any test cases specified, they know exactly who was in charge of that and how it slipped through.

Boring and insipid? Yes. That's exactly why they're successful.

The successful outsourcing companies excel at this type of thing. That's why it's important that they get ISO certified and CMM Level-whatever. Those achievements are not there to fool customers into thinking it will result in better software. It's there to tell the customer that we have a process and mechanism in place for dealing with your complex requirements.

All the offshoring failures come from doing a quick calculation of your developer's time vs the time of a developer in India and then thinking you're saving money by offloading the work.

Wow, I posted that question on SO two years ago. Didn't expect to see it near the top of HN.

FWIW I still think effective offshoring is really hard.

I've had extremely good experience 'offshoring', but I have one criteria: we meet in person and I spend time with them in their own environment so I understand what challenges are to be faced.

Also, it has to be said: constant communication. It won't work without constant communication, preferably in real-time (email is good for specs and bugs but IM/voice is the only way to make sure you are on the same page). I wouldn't recommend offshoring if saving money is your primary goal - good, long-term work comes from being invested in the project financially.

Additionally it helps that we consider ourselves friends. We get on, to the level of being able to go out for a drink with each other and keep updated about our personal lives. Even just asking about the local weather is an important indicator that you recognize each other as people. I met with the people I wanted to work with and established strong relationships over time. I continue to work with them as we're all invested and familiar with the tech at hand.

If your perception of offshoring is "lets hire developers in country X and save 40% because developers make 40% less there." Then the answer is NO. Even if you can find the perfect employees that will do great work for 40% less it is only a matter of time before they will find better paying jobs, and that turnover will kill your 40% savings.

Its depend; sometime it works and sometime it won't. In 2009-2010 India has done somewhere around $75 billion business with 18% growth and these numbers say it works for some people.

There are certain downsize of offshore development like communication, cultural differences etc.

From my personal experience, hard as hell (read: failed). Though companies can successfully do it, absolutely. I met one company that was 1 block away that had really impressive operations. They were supposed to be the offshore branch for a European company but the European company essentially disappeared and they were running the entire thing offshore with a couple marketing staff left in Europe. All the knowledge and experience ended up transferring entirely to the offshore operation. A few of the top managers moved over and they are recognized as one of the top companies in their industry. I wish I had more time there to learn what they did and how they managed it, sadly, I didn't.

It doesn't work because this is what happens.

You're working for your mid-sized company, a couple hundred employees, and they had just a great 2010. The parent company is willing to invest in further growth, and at the top-level growth means headcount, headcount, headcount.

So they hire a couple dozen people with titles like "product manager" and "business analyst" and the tech project pipeline, already stuffed to begin with, becomes completely ridiculous. HR's hitting the phones/Craigslist/Linkedin to fill those developer positions, but they're just not having much luck. Of course they're not going to have luck. Google's in a "War for Talent," and if they're having trouble finding people, what does your rinky-dink shop really have to offer? For years you've suggested the guerilla-warfare approach to recruiting -- open source some of your most useful code, go to local college campuses and start some sort of internship/startup program -- but it's fallen on deaf ears so you've given up on pushing those ideas for awhile.

Eventually some executive or another gets the idea to try and offshore some of the work. You're not worried that they're going to take your jobs; in fact, you know it's going to catastrophically fail. Being at a smallish company allows certain economies of scale to work. For example: you don't have much in the way of things like "requirement documents," because you regularly engage with the business. You don't have "coding standards," but you can have discussions with the engineering team about things to standardize whenever you want. And you know there's no prayer of things like this scaling to an offshore resource, so you're mostly just wondering how to avoid getting blamed when it fails.

Your company talks with some firm in India and suddenly you need to get up at 7AM to phone screen some candidates. While all their resumes had a delightful HR keyword soup of languages they knew like "C/C++ Java Ruby Rails Scala AJAX," apparently "English" isn't one of them. Eventually you get tired of waking up at 7AM though, and you find one that speaks passable English and seems to know what he's talking about, so you say bring this guy on.

The problems mount almost immediately. The offshore contractor is on site for 4 weeks and you have him work on a practically trivial project, and while it technically works, the code quality is so poor that you have no idea how the fuck it even compiled. So now he's two weeks into his 4 weeks on site, and you're torn between rejecting his code and him spending another two weeks learning where the fuck his 'tab' character on his keyboard is, or doing something actually useful. You're under pressure to get some utilization out of this guy, so you put his terrible code into production, convincing yourself that's it's isolated enough to likely not need any maintenance anyway.

The guy goes back to India and now he gets his first project he works on remotely. You get your usual four sentence e-mail for your "requirement document," so you have to spend a bunch of extra time fleshing it out so this guy can actually write some relevant code. You hear nothing for 3 days, no questions at all, so you're a little concerned. And then suddenly you get an e-mail saying he's done, except you look at his code, and you WISH syntax formatting was the only problem with it. It seems he completely misunderstood everything, and even what he did write doesn't even work, and so you exchange an agonizing set of e-mails with him. The conversation you'd have with any engineer about misunderstood requirements that would take 15 minutes now takes two weeks because every question and answer is on a 12-hour time delay.

Finally, after 3-6 months of this, if you were smart you documented all the difficulties you had, your efforts to make it work, and you have a long discussion with your manager. Your boss appreciates the feedback, tells you that working with him isn't your responsibility anymore, and you can finally go back to working on your own projects instead of babysitting this guy.

And you're having lunch with some engineers in another team next week, and one of them says, "yeah, they're looking into bringing on some offshore help for us," and all you can do is sigh pityingly.

The only way it can work is if the person managing the source of work knows exactly what they're looking for. If the project manager can read and recognize what a well coded project looks like, then the model can work. But often the only thing that matters (especially to the type who would immediately want to outsource) is the end result.

A friend of mine tried outsourcing an e-commerce site to somewhere in India from freelance.com or one of those sites to save a little time and money for a project he said he could do for someone. He had absolutely no programming experience and didn't believe my "you get what you pay for" type attitude. A week or two and a few hundred dollars later he was all excited about how he was able to "manage" the developer and get everything done. Within a week the site was offline, completely destroyed by a script hacker exploiting some weakness in an out of date version of osCommerce. I think he just had to learn that lesson for himself though.

The success of offshoring depends on your definition of success and your reasons for doing it in the first place.

If you're looking to get more done for close to the same amount of cash then you're more likely to succeed than someone who wants to reduce costs as much as possible. There's no trick to getting it right, but it's really easy to slip up and get it wrong.

Offshoring is an economic phenomenon involving organizations that only know how to measure their IT effectiveness using cost.

Personal experience is that I've never seen it work, but that's only from my own sample set.

Have also seen a lot of "in-shoring" activity, where consultants are brought in to try and rebuild after a disastrous outsourcing scenario where agreed to service levels could not be maintained.

I've been horrified at the skill level of outsourced resources, not just technically, but chronic deficits in communication, planning and analysis skills.

It feels to me like a big Ponzi scheme that in the end costs clients more, but wish I had more data to back up this assertion.

I have seen some offshore people that are skilled let down but unskilled managers that have been brought into manage IT from other industries, such as manufacturing. Or, offshoring teams put into a skapegoat role by clients that couldn't fix their own problems.

I'm currently off-shoring the development of my startup to India and it’s been working out great, but it took a lot of trial and error - kissed a lot of proverbial frogs so to speak.

Here’s my experience and if this helps someone gain a better handle on how to deal with the issue, great! The first time I looked to off-shore my development, I went with traditional off-shore development providers and was severely disappointed. The developers I found had big firm coding experience – having worked on projects for Goog, Msft etc and probably could build software on a consulting basis but just didn't get "startup" development. They needed a defined set of requirements within which they could work and needed for those requirements not to change. You can forget about pivoting. This "big-company, back-office" mentality obviously won't work for startups. They don't understand agile software development and are terrible with communication. And by communication I don't mean English, that’s usually not the issue; the issue is their approach to communication with a team - closing the loop on emails, replying in a timely manner (or doing anything in a timely manner for that matter) and addressing all the issues you communicate with them.

After spending time with 2-3 different teams I changed my approach and started searching for people who were passionate about and contributed to open-source, were active on forums, on Twitter & Fb, and were excited about working on my idea – as opposed to guys wanting to make money from a consulting gig. I found my current developer through such a search and so far it’s been great. There have been some hiccups, but I daresay these aren't issues that would have cropped up even with a team located stateside.

So I’m running a distributed company and it’s working out to be very cost-effective - which was the reason I started down this path in the first place. Anyways this is my experience. I may be one of the lucky few; but I do believe that you can find folks with a mentality suited to startups. And if you do, the cost savings are worth the pain.

A large number of programmers in silicon valley come from India, Russia etc. So if you say that offshoring doesn't work are you saying that the only good foreign programmers work in the US, and all of those working overseas are no good?

Of course not.

Offshoring definitely does work. I manage 45 staff in 9 countries and it's a matter of hiring the right people.

Hiring a company from India to just handle the entire development for you is highly unlikely to work.

Hiring staff directly, only looking for top talent, with staff working from home, and picking the very best of the best can work, and can be a fraction of the cost of hiring staff in the valley. It's very hard to compete with Google and Facebook when trying to hire top talent, so why compete? The Internet allows you to hire in any city and any country, so why limit yourself to one area?

Hire on skills not on geographic location.

More than offshoring (as outsourcing) I think I would be smarter to hire remotely. At that point doesn't really matter where you hire as long as you hire smart people who you'd hire even if they were local. In this way you can get top developers at a lower rate.

You should only offshore a mature product that's past its prime and just needs maintenance programmers to keep it alive and prevent it from blowing up. Any code changes will be bug fixes only and you won't be enhancing this product much.

For such products, the controls to keep bad code from getting release should have been put in place long before the teams were offshored.

When you're building a startup, your product won't resemble a product that is ready for offshoring. You'll be constantly iterating, rebuilding deployment infrastructure, and will need to respond quickly in case of catastrophic failure.

My experience is it can work well if you give complete responsibility over to the remote group, regardless of location, it doesn't matter if they are a building away or 8 time zones away.

One big distinguishing factor between success and failure can be - who does the requirements? Allowing the same company who is going to code, to get the requirements part done is asking for a bad product, no matter where your development takes place, period! In all off-shoring projects that I have seen, successful ones had requirements done by the client, and having a client liaison work on a day to day basis with an on-shore tech lead from the off-shore company ... (too complicated?)

Yes. A great example is Beanstalk. The following interview might be of interest.

http://mixergy.com/beanstalk-bootstrapped-run-virtually-gene...

From the interview...

Andrew: Where in the country or where in the world are your people?

Chris: Let’s see. I always have to think about this. There are nine of us total. We have people in Ukraine, Germany, Serbia, Bulgaria, and Russia.

I just used vworker on a project. Wasn't absolutely perfect, but was pretty good value for money. I'm happy with the result, and now I have an ongoing relationship with the developer.

offshoring has worked wonderfully for my employer, details in an older comment: http://news.ycombinator.com/item?id=1879786

like literally everything else, the trick is doing it right

I can't speak from experience, but my perspective is that offshoring works great when what you're offshoring is the building of machine tools, toys, furniture, computer components and even whole computers, cars, etc.

I'm sure apple, for instance, spends a lot of time making sure that foxconn builds the iPhone right. But Apple is not offshoring the software or the design of the iPhone.

For whatever reason, software development is a competitive advantage that the US has.... for the time being.

I've worked with people from india, pakistan, and former soviet block countries as programmers. They can be great programmers, but the best results seem to be when they come here and work with american teams.

Which is why we need to get visa reform and let american businesses hire the people they need.

I think that the offshoring of this work is driven more by not being able to import sufficient engineers than by anything else.