I recently passed my 1 year mark building Buink Web Development and thought it is about time to address one of my biggest competitors: offshore development. 🙂
I say competitor, but I honestly don’t see it as that. Looking to the future, I hope that offshore development is my friend, not my enemy. In fact, I don’t think you’ll still be alive in this industry in 20 years if you don’t learn to leverage offshore resources (unless offshore is also made obsolete by artificial intelligence, mu ha ha ha!).
I hope that offshore development is my friend, not my enemy.
That said, offshore development is not for everyone. In this article, I’ll share some of my experiences, list the pros, list the cons (including some solutions to counter the cons), and make some recommendations to help you make the most of your development dollars.
Here is how this article is broken out:
- Pro: Come on Down, The Price is Right
- Con: Their Timezone is Sleeping On the Job
- Con: Lost in Translation
- Con: Spaghetti Code
- Con: Stolen Code
- Solution: Make Offshore Work
Pro: Come On Down, The Price Is Right
The low price of offshore development is the only “pro” that comes to mind. There may be more, but I can’t think of any.
I’ve met and interviewed lots of developers (offshore and on) and, its true, most offshore developer costs less than onshore developers. No surprises there, in fact, some charge quite a bit less; for example, the lowest hourly rate I’ve seen is $9. That is cheap! Imagine, a highly skilled developer in a distant land making less than we pay people at McDonalds. Nine dollars, however, is unusual, the range I’ve seen is from $9-$60 and the average is about $25.
“The only ‘pro’ that comes to mind is low price.”
These rates sound great, but are they too good to be true? They can be if you’re not careful.
Con: Their Timezone is Sleeping On the Job
When you’re trying to move at the speed of business, you’ll quickly realize that having a 5-12 hour delay in communication can really slow a project and even waste money. When you’re asleep, your developer is awake and vice versa.
I’ve seen the following two scenarios many times. You wake up, rub your eyes open, grab your mobile phone, and review the developers work from the night before. You realize they spent the whole day going down a “rabbit hole” of misunderstanding. You send an email clarifying something they did wrong. They wake up 12 hours later and respond with a question, which you don’t see for another 12 hours. The cycle continues! Work stops for multiple days and time is lost. Or, worse yet, they don’t clarify and spend another 8 hours going down another rabbit hole.
This cycle isn’t a product of the distance between lands. The internet and new technologies like Google Hangout, Slack, Trello, Basecamp, and others have virtually eliminated the distance between two points on planet earth, but the timezone barrier is still a serious issue.
I experienced this problem first hand with a developer not long ago, I’ll call him Victor. Our relationship was already on the rocks because he was hard to communicate with and he missed a small deadline. I gave him a second chance with a small project. I expected him to return the code in two hours, but when I woke up the next morning I found that he had billed 8 hours and still hadn’t delivered the code. He had all kinds of questions and I quickly realized he was trying to make changes on the wrong code base. No wonder he was confused about my instructions. Had we been on the same timezone, he could have easily reached out and I could have followed up. Instead, he spent all night spinning his wheels.
“The timezone barrier is still a serious issue”
The only solution I’ve found to fix this con is to require the offshore developer to work in my timezone. They won’t always do that and sometimes they’ll make promises they don’t keep, but if they do, it will save you a lot of time and money. If they don’t, just consider your true cost of offshore development at something like $40/hr and not the sticker price of $25/hr.
Con: Lost in Translation
As I’ve said in previous articles, development specifications are hard to communicate EVEN to native English typers and readers. When you add in the language barrier, you may find it impossible to communicate.
Notice, I specified typing and not speaking. Speaking English is important, but if a developer can’t type quickly, they can’t code quickly. It sounds simple, but it is often overlooked. Coding is typing; and typing in English will always be harder for non-native speakers.
Reading is also critical. Your developer needs to be able to easily comprehend the project specifications. In addition, they’ll need good reading skills to find help with bugs and features. When a developer hits a snag, a quick search of the internet often results in a solution. Most of the time, someone has written an article about a feature you’re trying to implement. If a developer can’t read and understand quickly, they’ll likely be re-inventing the wheel with every new feature.
The truth is, I’ve never met an offshore developer that types and reads as well as a native English developer, and even some native developers struggle. 🙂 You just have to understand that this is going to be an issue. The question is, how much of an issue. Are they twice as slow? If so, the true cost of offshore development is looking to be closer to $80/hr.
“Coding is typing; and typing in English will always be harder for non-native speakers.”
The best you can do is try to asses their English skills and avoid those who have trouble. You’ll realize really quickly if a developer is avoiding email communication and opting for conversations via Skype instead. This is a red flag. I try to force them to communicate everything via email and chat. If I notice some big grammar errors, the kind where you can’t even understand what they’re saying, then I usually don’t move forward.
In addition to screening their typing and reading skills, you must also realize that they’re going to misunderstand some things and they’ll waste money in the first or second rabbit hole. As you can imagine, things get out of hand very quickly.
Con: Spaghetti Code
I have yet to work with an offshore developer whose deliverables were significantly more valuable than that of an onshore developer. I’m not saying they aren’t out there, but I’m still on the lookout. In my experience (which isn’t trivial) they aren’t much cheaper.
For example, I’ve talked about the first project I sent offshore in earlier posts, but I’ll summarize it here again. It was a custom WordPress site. When I took over the code it was filled with all types of security flaws, they had hacked the WordPress core (making it impossible to update), and there was almost no structure/organization/architecture to the code. I’ve heard other people talk about “spaghetti code” and that is exactly what this looked like. From a user perspective, the site looked great, but from a developer perspective, it was a mess.
Even Victor, who I mentioned previously, delivered code (albeit late) that on the surface looked good but had to be re-coded in some aspects. Did his code add value to the project? Yes, but not without exception. Even though his rate was lower than my other onshore developers, his code ended up costing about the same or more.
“From a developer perspective, it was a mess.”
The only solution to this con is that you have to have an experienced developer review all offshore code. Just because it looks like it is working, doesn’t mean it is.
I’m sure I’ll mention this again, but I highly recommend you track code changes (via Git) and require all code changes to be packaged into small, feature related groups (called pull requests). These pull requests should be reviewed by an experienced developer you trust (like an onshore developer you hire as a lead).
Con: Stolen Code
This con is only hearsay, in other words, I haven’t experienced it myself. I include it here because I could totally see this being an issue.
I was out to lunch with a client recently, we’ll call him Zuck. He had me act as a developer lead on a project with a short timeline. I brought in several contractors to speed up the process. I mentioned to him that one of the developers was from Kiev, Ukraine and he said he was glad that I wasn’t working with anyone from India. He told me how he’d worked with several in the past and questions their ethics. “Sometimes,” he said, “they’ll just hack someone else’s code and package it up for you instead of developing it themselves.”
I didn’t dig into Zuck’s claim, but I take his word for it. I’m not saying that India is somehow worse than anywhere else, but the rule of law isn’t the same in many other countries. The risk of getting sued by a client is drastically less for offshore developers than for us onshore. Offshore developers don’t operate under the same rules we do, and as a result, I can imagine there is less incentive to write honest code.
Luckily, the solution that prevents spaghetti code will also solve this con. Hire a developer lead like Zuck! I can’t stress it enough; you should require developers to track code changes (via Git) and package code changes into small, feature related groups (called pull requests). Then, have each pull request reviewed by an experienced developer.
Solution: Make Offshore Work
So, with only one pro and several cons, you may be wondering why I started this article hoping that offshore development would be my friend in the future. Well, you have to admit the price is very nice, if you can figure out how to prevent the cons.
Some of the cons are easier to solve than others. Timezone and communication issues are difficult, but through some trial and error with different offshore developers, most businesses can overcome these cons. Just be prepared to loose some time and money in the trial and error process.
It is, however, much harder to asses coding skills, both before hiring and while on the job, unless you are a developer yourself. For this reason, I don’t recommend overseas development for anyone who is not a developer. There are just too many phonies. There are too many overseas developers charging high rates and delivering substandard results.
If you’re not a developer, the only way I’d recommend you use overseas developers is if you hire an onshore lead developer you trust. This lead developer will review all code changes, review progress based on the number of hours worked, and make decisions about the effectiveness of overseas resources.
“Hire a developer lead like Zuck!”
I have several clients, including Zuck, who use my services to lead a team of developers. Some have existing developers they’ve worked with for a while and they want me to take over and make sure things are going as planned. Others want me use developers I’ve worked with in the past. Either way, you’re better off letting me worry about timezone, communication, and skills assessment.
What do you think? I’m sure I missed something, so please share your comments below!
