With over 6 years of experience in environments predominated by the offshoring of the software development this post is about some observations around how not to offshore your software development.
My first experience with offshoring was as a developer whose projects were being off-shored to India due to cost and the corporate strategy. This brief engagement of only a view months gave insight into the promises being made to the client during the handover phase, and then the subsequent failure to deliver on these promises in the months thereafter.
A year later and in a new job I was to become the client in the offshoring world. This led to a roller coaster 5 years. During these 5 years I was fortunate to make many trips to India and formed many friendships.
We have started to bring our Software Development back in house due to a number of reasons, and so here are my observations on how NOT to offshore your software development.
Don’t offshore if you simply want a managed service offshore to replace local developers. And if you think that you don’t need to take an interest in who is working in your ODC, then definitely do not offshore.
You still need to value your local technical resources. Just because you are offshoring your development it does not mean your technical head count can be reduced to zero. You should never abdicate responsibility for your software and intellectual property. Hands on architects are still important to steer the ship and a small team of developers should work hand in hand with the offshore team using continuous integration tools.
You will most likely be replacing your experienced “expensive” local resource with a “cheap” graduate. You might think you can still get 5 of these grads for your one local resource before it becomes more expensive. That is until your resource count is through the roof and changes are taking longer than ever. And quality is not where it should be.
The offshore team are the people that are going to become custodians of your software and intellectual property. You will be spending many hours with them in telephone calls, Skype calls or instant messaging sessions. Not only, must you be able to communicate with them effectively, culture and language are a barrier, but they must have the same perspective as you when it comes to quality.
Don’t offshore if you are going to manage the projects using a waterfall methodology. You might think one of the draw cards for going offshore is the level to which the vendor complies with CCMI. Unless you and your offshore vendor are going to collaborate on the outputs from the CMMI process it is essentially a waste of time and only gets done for the sake of being done. You essentially end up with lots of process adding very little value.
You as the client need to aggressively investigate how to break down barriers and have rapid feedback cycles. The confusion caused by language and culture cannot be eliminated by writing wordy documents with pretty UML diagrams and throwing them over a wall. And then thinking because you are having status updates every other day and you’re tracking all your tasks in a big project plan, that your project will be a success. Quite the contrary, it will be a failure. Rapid feedback, constant communication and actively participating in the development are the only ways to ensure that you are truly getting what you want.
Agile and Scrum should be used to break down these barriers but it takes considerable effort, on both sides, to get it right.
Continuous Integration and code quality
If you cannot deploy continuously into, at least, a test environment, and you have no view of the quality of the code, then do not offshore.
You have to utilise techniques such as continuous integration to minimise feedback loops. You must be deploying working code into your testing environment at least once a day. You must have some form of code coverage to quantify the quality of your code. And you, as a client, must show interest in these reports and understand them.
Your code is an asset, not in the number of lines but rather the business value or intellectual property it represents. It is much easier, quicker and “less risky” to copy and duplicate a piece of code, than appropriately refactor the code for reuse, because the short term testing impact is minimised.
Keep track of your code coverage reports. Is the number of unit tests increasing, are the violations decreasing, is the number of lines of code decreasing? But this does not replace you being hands on when developing your software.
Would a surgeon work on a patient with blunt knives, I think not. So why should developers work with blunt tools, below spec pc’s, outdated IDE’s or poor connectivity. If you as the client are not going to make sure that the developers are as efficient as possible then do not offshore.
Make sure appropriate infrastructure is available for development and communication purposes. The offshore developers should be part of your network; they must be able to develop using any local resource as if they were on your network. And make sure the lines between you and your offshore partner are robust and fast.
On my first trip to India, I could not believe the archaic pc’s and IDE’s the ODC was using to develop Java code. Couple this with poor link between them and us it was not wonder these guys were working ridiculous hours to get projects finished. They were just so inefficient and it was never raised as an issue.
If you are not going to make an effort to understand and bridge the cultural gap, then do not offshore.
One of the obvious differences can be represented using Hofstede’s Power Distance. Using India as an example, which has a high cultural Power Distance and South Africa, which has a lower Power Distance indicator, developers expect managers to make decisions and are uncomfortable when making discretionary decisions. Comparing this to a South African where developers are typically expected to be self-reliant and make decisions.
You have to constantly work on tactics to bridge this gap and to confirm that you are indeed bridging the gap. Tactics include always getting the offshore team to repeat their understanding to you. Having rotating members of the offshore team onsite also allows for the teams to get to know each other and make sure you make regular trips to your ODC. Experiencing each other’s cultures first hand is the best way I found to bridge the gap, and to create friendships.
So in closing, if you still have to worry about the people, the development methodologies, continuous integration and code quality, the tooling and the cultural issues, do you still want to offshore your software development? Offshoring does work, but do not underestimate the effort required by all parties involved.