Why does offshore produce such a bad code?

Recently a good friend of mine asked me

Why does offshore produce such a bad code?

This is not the first time I was asked this question, not to mention myself asking this question. I knew the answer for this question for the last several years, but I did not know how to make change it.

These are my findings.

Most of big consulting companies which I worked with, which includes (call me if you need company names) among others, impose offshore developers onto the project. It means that if you are an on-site technical manager you are given the offshore developers. You are not allowed to screen resumes of developers or pick the developer you want. People are given to you. No wonder they are referred to as ‘resources’; a blind headcount to meet the project plant requirement for full time employees. I do not want to say that individual developers are bad; however, I have a handful of jokes about the questions I was asked by offshore developers whom I asked to be ultimately removed from the project. Even though offshore developers are ‘cheap’ per hour, a non-qualified offshore developer can cost the customer a lot of money via late code deliveries and poor code quality.

For the second reason I will use the same cliché. Most of big consulting companies, which is probably better versed as, most offshore development managers wish to present their development unit as a black box. You throw a functional design onto them, they tell when it will be built and tested and… offshore vanishes into thin air. Any request as to the progress comes back as ‘WIP’. Any code check in the database returns empty results because the offshore development manager claims that they have a local copy of the database. The delivery date comes and goes, and a couple of days later the offshore development manager presents you with something that is claimed to be fully tested code written according to the specification. The reality is… well… we need to start the real build now.

I am sure the story is familiar to many onsite technical managers. It fully describes ‘Why’ offshore development is difficult. The true question is how to make it work.

I happen to work with an offshore model for one of our European customers where I was perceived as an offshore developer (I live in USA). This is the approach I tried to implement which proved to work quite well. A functional consultant throws a functional design to me and I give back the dates when I think the code will be ready. I write the technical design and post it to the central storage for reviews. Then I start coding. This is a quiet time that lasts several days. However, as soon as I have a piece of code that somehow meets the requirements of the functional design, I claim to the functional consultant that code is written. How much time have I spent?.. Maybe 25% of the time allocated to development. The next week or two (depending on the complexity of the design) are nightmare. Functional designer logs one defect after another, even basic tests break, I am called all kind of names… I keep my head down and keep on coding. One week passes, and tests start completing as desired. Functional consultant finds bits and pieces which he/she overlooked and I add it to the code. By the time the time allocated for coding and functional testing passed, the code is in perfect stage, functional consultant is happy with results, and I am being petted on my shoulder for delivering high quality code on time.

This approach does require a level of maturity from both developer and tester. One of the most difficult parts is that bugs, or defects, are natural part of a software development. This is not evil, this is good. This is something which drives average software to perfection. I am always saying that if not a single defect is caught during the first test, then the defect is so deep in the code that it will take many tests to uncover. It also requires a level of patience on the tester’s side as well as understanding that the first cut of software is very raw. So raw that even the developer did not run a single full test scenario. However, from the customer stand point, such approach delivers the solution on time and with quality.

We, at Premiertec, apply this approach not only to Oracle eBusiness Suite projects. Even on short term engagements, like an Oracle ADF custom development project which ran for just over a month, we did bi-weekly customer presentations of the solution not to mention daily code checks and numerous internal demos. This was a remarkable project where the customer was in the United Kingdom, solution architect in USA, and the development team in our near-shore development center in Ukraine.

This was my answer to the question my good friend asked me.