The Hidden Costs of Offshoring Your Software Development

It looks good on paper, I know.

You’ve got software that needs to be built. You’ve got a very constrained budget. You’d like to use full-time employees or contract with a local company to get it done, but you look at that $130-an-hour price tag compared to that $30-an-hour price tag from an offshore company, and no other choice seems to make sense.

There are good offshore companies out there, and offshoring your software development may be the right choice for you. But a wise business decision looks beyond the simple cost of acquisition.

Just because you have five million dollars doesn’t mean you should buy a five-million-dollar house; there are utility costs, property taxes, insurance, maintenance costs, and all sorts of other expenses that should factor into your decision. When it comes to offshoring, you may find there are several other costs hiding in that hourly rate difference.

Lack of overlap

We have found that teams with less than four hours overlap have trouble adhering to any of the agile principles, never mind producing a quality product in a reasonable amount of time.

—Chaos to Successful Distributed Agile Teams, Rothman and Kilby, p. 25

When thinking about offshoring, you need to think about how much shared work time you will have with the offshore team. Shared work time is essential to communicating valuable information, getting answers, resolving issues, and establishing ways of working together that flow smoothly.

Even leaving aside the challenges to being agile, just simply working efficiently and effectively together in a timely manner to any extent is greatly hampered if you have low or no shared hours with your team.

I’m currently working with a client in the United States who initially used a team from India to build their MVP. They had an hour a day of overlap - 6 p.m. to 7 p.m. Central time. What they ran into was that many issues with a new product were virtually impossible to resolve in an hour of conversation or emails (that also got answered at non-overlapping times). A requested change might take a week to get fully understood and delivered, and this was their primary motivator to switch to a domestic firm. They simply could not absorb the costs of every adjustment taking a week, and when you’re building a brand new product, those adjustments are numerous!

This factor can be overcome to a large extent by choosing a firm in a country with a timezone closer to yours. For example, a United States company might have high overlap with a firm in Mexico or decent overlap with Eastern Europe or Western Africa.

But however you deal with it, the lack of overlap is a significant hidden cost as it eats into not only response time, but also simply settling into patterns of working that flow efficiently on a day-to-day basis.

Need for direction

When you have teams where communication and feedback can happen quickly, you don’t need to define every detail upfront. You can specify the outcomes you’re wanting, let the team design what they think is best, get your feedback on it, and adjust to that feedback. This can happen relatively quickly.

When offshoring, there is quite a bit of lag time between seeing something, giving feedback, having that feedback understood, seeing an adjustment, and giving feedback on that adjustment. If you’re standing at my desk while I build your app, we can quickly crank out exactly the screens you want. The more separation we get, the more overhead gets baked into that process.

Because of this, organizations have learned that they often need to define everything in exhaustive detail that they hand over to an offshore team. Imagine this scenario:

You tell an offshore team that you need a button to be added to a screen. When their day starts, they email you asking what color it should be. When your day starts, you email them it should be red. On their day, they add a red button. On your day, you see the red is too dark, and you ask them to make it a brighter red. On their day, they change the shade. You see it the next day. And so on.

And that’s an unrealistically simple example. Imagine the same exchange happening over complex business rules or tricky UX problems. It could take a week just to get that red color right. How long will it take to get your pricing rules right?

Because of this, companies have to define everything they need in exhaustive detail so there’s no room for ambiguity, and that is a huge cost.

One client I worked with spent a year and (very) slightly under one million dollars exhaustively documenting their requirements, and by the time they were done, much of their work was already out of date and had to be reconfirmed as development progressed. Would your hourly rate savings have made that effort worth it?

And that’s just the cost of getting the details defined upfront. As I noted, most of those details ended up being wrong (as extensively detailed up-front plans tend to be) and rehashed anyway, incurring even more costs.

It's true that some organizations work this way with their onshore developers, too. But we'd normally think of that as a less-than-ideal way of working with people who can get quick feedback. With offshore developers, it's almost a required way of working, though.

Bad news

At one client, a developer who used to work offshore told me that, in his country, software development paid so much better than what most people made that people were very reluctant to expose that they needed help or that the job wasn’t going well. Some people even lied completely about being software developers, hoping they could stay employed for a few months and save up some good money before they were found out.

Now, I live in the United States, and I can tell you this tendency is a problem everywhere. It doesn’t magically vanish just because you use domestic developers. Many organizations of all kinds unintentionally have cultures of fear where people don’t want to reveal bad news or advertise their own struggles.

However, when you go offshore, you have to think about the cultural and economic forces that shape the people and the firm you work with. I have had offshore developers keep totally silent about project problems or misdirect me even when asked direct questions. These were not bad or unethical people—they were people afraid of what might happen if I thought they weren’t up to snuff and what that would mean for their lives, which could be very different than what it might mean in your country.

The cost of hidden problems is usually a time bomb. You don’t find out until it is either too late or far more expensive or risky to deal with them. You may not find out that the team is months behind until two weeks before the deadline. Even something as simple as not understanding a requirement may be something you simply aren’t told about and don’t realize until that requirement has been coded (or overlooked).

This really comes down to creating cultures of safety and trust, and as I said, this is an issue domestically as well as in all countries. But it could be an uphill climb trying to create that culture with teams overseas.

Code quality

I actually don’t think this is much of an issue in the decision to offshore.

That may sound crazy. Usually, when you talk to someone who has had a negative experience with offshoring, this comes up. “We had to redo so much of what they did,” and so on.

I don’t deny that there is a common refrain here. I don’t doubt those experiences.

However, most code produced domestically isn’t very good, either. Most of the organizations I hear tell me that “code quality” was an issue in their experience aren’t producing code that’s much better. In fact, at least one of those organizations criticized code produced offshore that, upon review, was actually better than their in-house developers were producing.

So, before you let code quality sway your decision, I’d recommend having some specific thoughts on what your domestic developers would have done differently and the benefits you would have gotten from that approach.

Having said that, one potential cost difference here is that, whatever your practices are to bake quality into your code, they are exponentially harder to do when you bring an offshore team into the equation.

Pair/mob programming is that much more difficult since it is happening remotely and often in very different time zones. It may even be impossible. If you do code reviews, those reviews are often very asynchronous with long periods of time passing between the review recommendations and the revisions. And I have heard more than one domestic architect talk about their reluctance to insist an offshore team’s code get shaped up when the amount of revisions and back-and-forth would be great.

Should you still do it?

I can’t answer that question for you. My development firm is in the United States, and we charge rates that are competitive in this country but are far, far more expensive than virtually any offshore company would charge. The hourly rate savings are enormous with offshoring, and I can’t pretend they’re not.

But go into the decision armed with information. The hourly rate is just one stream of costs that goes into software development. Before you decide to use an offshore software development company, make sure you’re going to come out ahead in the long run.