I have hesitated on posting this for quite some time because I know it’s going to invite some vitriol from a few folks – but it’s simply my experience with offshore development.
Finding and hiring development companies who know what they are doing is a challenging proposition. Even harder, if the vendor is offshore or offers “onshore” project management, there are numerous barriers to success. Over my career, I’ve personally experienced these challenges, so I’m sharing my thoughts on them with you to help you avoid the pain.
Ah, the details… Many companies want to pass off a project without going into the details. With no agreed understanding of functionality or presentation, vendors can underestimate how long it will take to complete projects. Ultimately, that can lead to increased costs and missed deadlines.
Time Differences in Offshore Development
Working across time zones is a challenge. There is nearly always a substantial time difference between clients and offshore vendors. I hear of companies where managers get up super early or work well into the evening to coordinate with offshore teams. A question asked one day gets answered on the next day. It can drag on development time far beyond the original estimate.
Resource Availability and Timing
An outsource relationship works best when the vendor can be available when the need arises. Make sure the vendor will be responsive to your requests using tools like Service Level Agreements (SLAs) — make sure you’re not left standing on the sidewalk watching your bus drive away. I’ve had offshore development projects where we were “the new project”. During that time, we got lots of attention. Toward the end, our star didn’t shine as brightly, and we were serviced quite slowly.
Quality of Communication
The quality and quantity of communication needed for managing offshore development projects is often underestimated. Language barriers frequently come into play too. While the expectation may be that you’ve outsourced the project, you have also added overhead on your side to communicate clearly, frequently and quickly.
Working from different countries can mean losing control over information shared with an offshore vendor. Valuable data could be re-purposed or used without your approval (or knowledge). Variations in international laws may leave you less recourse and could be cost prohibitive to pursue.
Quality of the Software
I’ve seen some UGLY user interfaces created by offshore development companies. Standards aren’t necessarily the same as we’re accustomed to in the U.S. Even worse, I’ve seen entire 1.0 code bases thrown away for a 2.0 (onshore) re-write. One reason: too many shortcuts (hey, it worked) without consideration for extensibility. I’ve also taken over projects with some horrific functionality under the hood (e.g., no indexes on a big database – smoke ’em if you got ’em to find a record in the system). I wouldn’t attribute that to poor communication – that’s poor standards by the vendor, only determined later by another vendor looking to improve things.
Testing outsourced projects is more difficult than with an in-house or onshore project. If you find a problem, you have to coordinate error reporting with the vendor. They may not be able to reproduce the issue in their environment. Again, onshore work is challenging enough, and offshore work is far more difficult because of all the areas already described.
The trade-off for offshore vs. onshore development is typically budget. Onshore may seem to cost more. What seems cost-effective can be cost-ineffective, but you have a better chance in the longer term by working with someone nearby…