Why do companies hire programmers from the U.S. and Western Europe when they can hire programmers remotely from India, China, and the Philippines for a lower price?
- Filimon, studied at Technical University of Bucharest, Romania
There was a outsourcing trend to use Indians about five years ago. it is gone mainly for the following reasons:
1)The output was often poor, in house IT people had to correct errors and code provided by Indian companies.
2) Indian companies won bids by quoting very low prices, then they were unable to complete the work at the price stated, as costs were higher or they had no specialists to do the work. I was contacted once by an Indian IT company to work on their project in Switzerland. They offered me a pitiful day rate, then pestered me for a week to accept their offer. I had to block their number to get rid of them. Some colleagues had similar experiences with Indian IT companies. They win bids by quoting low prices then hunt for IT people to work on their projects for very poor wages/rates.
3) Eastern Europe especially Romania. Poland, Slovakia has even better programmers, all speaking good English and other European languages, and the time difference is maximum +2 hours from GMT. They are well trained, speak European languages (which Indians don’t, they only speak English), provide good value for money and live in the proximity, so they are a better option than Indians. Eastern Europe now is the main IT outsourcer of Western Europe.
Ryan Mattes, 20 years writing software
I work for a company that makes quite a lot of money cleaning up the messes from offshore development. Quite a lot of small, 3-person shop work too.
It's not a matter of better or worse programmers, it's a matter of better or worse processes, documentation, communication, understanding business requirements, and planning for the future as a partner. We don't just take jobs for money, we take an interest in our clients, understand their culture, learn their business, understand what their pain points are, get to know their budget cycles, and work with them for the long term. Of course it costs more in the short term.
When we bid on a project and they say "this other small shop/outsourcer/my nephew says they can do it for half the cost in half the time" we say, "good luck!" and show them the door. They end up paying 3 or more times as much as we originally bid, and have an inferior product, because all they hired was a developer, and what they needed was a team that was willing to learn their business.
Better than half of those clients come back within a year and tell us they made a huge mistake and ask if we can help. Of course we can, but it often means throwing away their outsourced solution and starting again from "what does your company do?"
Remember, it takes more than just a good developer to turn business process into software. It takes architects, engineers, business analysts, programmers, art directors, and project managers, working together as a team, with the common goal of making that business and its customers happy.
Our hourly rate may be double or triple what small shops and offshore developers charge, but we get the right job done, the first time, on time, and on budget, and there's a lot to be said for that. Offshore developers can never promise that, because when there's trouble, I can show up at your office and walk you through it. I can spend evenings on site learning your back end systems. I can go have drinks with your IT guys and find out where the real bottlenecks are. I can sit with you in person with a whiteboard until I understand how your business operates, so that we both understand what the real requirements are. There is no replacement for a good, local developer.
Let me offer a perspective of somebody "on the other side"...
I work for a small development team in Eastern Europe (Serbia) and I can honestly say that we don't get work because we are cheaper (even though we are), but because we get things done.
We are very proactive in gathering requirements (a lot of GoToMeeting, Skype, draft specifications going through iterations etc.), our codebase is clean, reusable, well documented (in English), thoroughly unit-tested, thoroughly manual-tested by our QA team, and meant to last for years.
And more than one time, we have been in a situation to clean-up the mess made by other people, both "eastern" and "western". It was not a matter of price, it was a matter of customers getting a usable system.
So, if you love programming, go for it! Ultimately, it won't matter whether you are somewhat cheaper or not... what will matter is your ability to get things done!
Krystian Cybulski, Entrepreneur, web app developer since the prior century
Many companies do hire programmers remotely. Many don’t. There are many reasons. Here are ones that I’ve experienced personally, both from a contractor and corporate perspective.
- timezone difference makes collaboration more difficult
- if the tools and culture is not set up for remote work, working efficiently with remote workers will be difficult
- cultural differences
I’ll focus on the last one some more, as it is nuanced. A developer’s skills are only part of the story. Different developers work better in certain environments than others. I have found that working with people from other countries is more difficult as there are cultural differences. Sometimes, these are a big enough problem where they prevent good work. I’ve had a chance to work with people abroad who were excellent at what they did and also fit in culturally. Unfortunately, I’ve also had many instances where the developer may have been skilled, but culturally did not fit.
I will post some personal experiences of the difficulties I’ve had working with people from certain regions.
I was born in Poland and have spent the majority of my life in the US. I am now living in Poland again, and am working remotely. I have had a chance to work with developers in Poland, Ukraine, and Russia. I’ve found that developers from Eastern Europe are great at writing software to specifications, but have difficulty thinking of solutions that will work well from the user’s perspective. In situations where specs are vague or non-existent, they have a difficult producing usable software. They can be stubborn and very rule-oriented. This can get in the way of developing good software.
I found that Indian devs I’ve worked with abroad, when asked about something, the answer is always a “yes”, and almost never “no”, “maybe” or “I don’t know”. Most Indian developers I’ve worked with always promised a lot but often could not deliver. I’ve found that even when traveling in India and asking for directions, I will be told incorrect ones, but not once have I heard “I don’t know.” I’ve spoken to Indian colleagues in the US about it. They explained to me that it’s about saving face. They told me that what is said is just as important as how it is said, and that to them it is obvious when someone is saying “yes” but means “no” (or giving false directions to hide the fact they don’t know). While I respect other cultures, I find this behavior difficult and frustrating. It gets in the way of building good software, as a significant effort needs to be put on figuring out what the developer really means.
When hiring abroad, there are costs which are not easily captured in the hourly rate. When hiring for a remote position, I do not care where you are based. However, I do care that you will be a contributing member of a team and that you will fit culturally. I will continue to work with developers in different countries,good engineers are expensive, regardless of where they’re based.
Andrey Ryazanov, Product Manager in NYC FinTech
Let me take a stab at this from a Product Manager (presently FinTech) perspective.
As others have mentioned in previous posts, there is more to being a good developer than just speaking english and costing less. The most valuable things that I've found with the various teams that I've worked with (onshore and offshore) in the past, are the intangibles.
While it's certainly possible to manage a remote development team, the fact of the matter is that you're never going to get results that are quite as good as having one on-location with your stakeholders and product team.
While you're working on very simple projects and systems, remote work is great - however at some point in a company's lifecycle, those simple systems need to mature and then be maintained for the long haul. You can present people with all of the powerpoint decks, JIRA tickets and emails you want, but developers (at least senior developers) need to truly understand the company and its future direction in order to make good technical and architectural decisions for what teams are building.
That's not to say that offshoring is a bad solution - it's not. There are plenty of companies which don't have the need for complex, easy-to-maintain or change systems for whom the concept of offshoring is perfect - or which are just starting out and can't afford local talent. The last company that I worked at had great success (and some failures) building a custom (fairly basic) CRM system with an offshore team in India. Even my current company began its life with offshored software development talent. At the same time, there came a point in the company's maturity where it could no longer to afford to cut corners on software development because any competitor which had a local dev team would outpace us in a matter of months.
Justen Robertson, freelance full-stack developer at Toptal
There are plenty of situations where overseas programmers are a great fit, but here are a few things on the "con" list when making a decision to hire/contract overseas.
- timezone issues - when you're working with tight deadlines or with a team that does a lot of constant, direct communication (e.g. in the planning phases of a project or in a small agile shop), sometimes the 6-12 hour loop between business hours on opposite sides of the world is too long to wait for feedback.
- face time - some clients and managers just want face-to-face communication. Personally I'm comfortable communicating via email only, but other personality types need to see you and speak to you in person. Lack of real-time, in-person communication can cause a lot of friction and miscommunication with these folks.
- cultural differences - building rapport among team members is more difficult the fewer points of reference they share. There are also some jobs where cultural awareness is important. Suppose you're working on content that is culturally aligned (say, a local politician or country music star's website) - it's easier for someone with a different background to be oblivious to issues that are obvious to locals.
On the darker side of things, there's rank racism and nationalism, but people who hold those kinds of beliefs aren't the type of people I like to work for.
On a personal note, I have had very positive experiences working with developers from other countries, including India, Israel, Brazil, Germany, the UK, and Australia, just off the top of my head.
Jillian Tayeh, Tech Recruiter at Condé Nast
Many companies will begin by outsourcing or using freelancers because it can save some time initially - you have a whole team "boxed" and ready to go. It is also incredibly hard and time consuming to build a great internal team so if something needs to get done immediately, freelance or overseas teams may be the only viable option. Over time, however, having an in house team becomes preferable for a number of reasons:
- everyone is working in the same/similar time zone which can ease communication
- it's easier to make quick decisions about products and execute when you can address a whole team or a few individuals in person rather than having to set up a google hangout or skype with your overseas team
- you know that the team you hire is 100% focused on your company versus freelancers that may have their time split between several clients
- you can create an internal culture that allows for engineers and designers to think creatively about the business problems and be more involved in the day to day updates about the direction of the company and company goals
- longer term projects may exceed the amount of time a contractor can commit to