How expensive is offshore? (part 1)

In my last projects, project leaders, architect and designers were often FORCED to offshore the realization of a certain amount of functionality or effort. Especially european companies made strategic decisions, regardless whether current projects are suitable or not to be outsourced. I observed the projects some years and made the following assumptions:

experienced, corporate developers write instead of (Java) code, fine grained, word specifications. Because of the fine granularity the specifications often cannot be synchronized with the code
software developed by external entities (e.g) offshore companies is almost not reviewed internally. Because of deadlines and pressure, internal developers often tend to rewrite part of code (in an inofficial way), instead of refuse the iteration result.
offshore companies / outsource partners have to learn about the specific domain and customer needs. This can be a long and tedious process. Corporate developers already have the domain knowledge. They also know the customer directly (this is very efficient, but not always wished)
the technical skills of offshore partners are on average good. BUT: it is hard to set a standard like coding conventions, design decisions etc.It seems like in many offshore companies the developers work only a short period of time for one project and the change to another. It is hard in this circumstances to find a responsible developer. The idea of "shared code ownership" is also very hard to establish - no one feels responsible for a given piece of code.

I asked developers, architects, project leaders and even managers about efficient and in budget offshore projects, but I found only negative answers and samples. From my point of view: the problem here is not the offshore or outsource strategy itself, rather then the project context or category. The offshore strategy is great in case the functional and non-functional requiremens are well defined (should be bullet-proof). In most business or even problem-solving applications is especially this not given. The domain expert (often customer), is often not able to specifiy the application at fine grained level. In that cases a an agile or XP strategy is more suitable. BUT: the customer has to be involved in the development process. Now we have two possibilities to meet the requirement:

develop the software on-site (with externals partners). Can be this approach be still called "offshore"? :-)
also to "offshore" the customer or domain expert to the development team.

The second suggestion is very hard to establish :-), the first is actually not a offshore, but a kind of onsite-development.Offshore can be very efficient, in case the project domain and functional requirements are obvious. This is especially the case in technical software like: databases, application servers, JDBC drivers or technical infrastructure.
The more expert and domain knowledge is needed, the more iterations are needed to solve the problems. The communication becomes a real problem, because every iteration has some fractions which is in proportion to the distance between the domain experts and the developers. So offshore development can be very efficient, in case the developers and domain experts are sitting in the same room :-). But this is not the classical definition.

Advanced, creative and domain specific software can be often developed very efficient by internal developers. In this case the domain knowledge is much more important, than technical skills. On the other hand, straight forward, CRUD, or technical software can be easily offshored with almost no additional effort. So it is the management's responsibility to differentiate between sophisticated and "straight forward" projects. General strategies can become dangerous and expensive. The problem is not offshore itself, but the communication overhead, which makes fine grained iterations almost impossible.

In the next part I would like to discuss the maintainability of "offshore" projects and MDA and architectural/design requirements for offshore projects.
What is your experience?

Comments:

Dear Adam,

my experience with offshore is that it is difficult in cases where you require the code to have a certain structure, e.g. due to readability and maintainability of the created software. In that cases, the specifications are too fine grained so that you will arrive at the conclusion: Some things are better done than described. (taken from The Pragmatic Programmer).

So I personally have come to the conclusion that offshore makes most sense either if there is a very detailed specification already available which is the case for standards (such as JDBC as you already pointed out) or for things were you do not care about the internal structure of the code (no readability and maintainability requirements) which is only true for throw-away software, prototypes, or that sort of things.

However, many business critical software development projects normally do not fall into the categories above: they are either not a standard by themselves and usually are required to be maintainable and readable at the same time.

The solution of the problem in my opinion is to identify parts of the software that fall into the we-dont-care-about-internal-structure category or to use model driven development.

While you use model driven development, you will find out that there is almost nothing left to have it done by offshore partners except for the manual business logic code which should be better kept near to the customers as you also already stated in your post.

Communication is the most critical part when going offshore and offshoring should only be done when the strategy is defined: offshore in order to safe money (then the project will take longer in time), to get things done more quickly (then the project will become more expensive because you will have to use more manpower for communication and reviews and integration and the like). Many companies go offshore in the expecation that it will become cheaper at take at least not longer than doing it the classic way. But I personally do not see that you can get time and money performance at the same time.

What is your experience? Do companies out there go offshore for cost reasons or because they want to improve their time-to-market? Are they aware of if reducing costs it will take longer in time and when optimizing for time that it will be more expensive? I have not yet read about this kind of thing yet.

Posted by Michael on July 18, 2006 at 12:43 PM CEST #

Michael:
I will try to answer your questions in detail in the next weblog entry (is too long for a comment :-)). My general feeling is: most of the strategic decisions are "golf course driven" (GCD :-)). The initial ideas or intensions often get lost during the top-down travel through the enterprise hierarchy to the actual project/architect or developer :-).

Posted by Adam Bien on July 18, 2006 at 08:34 PM CEST #