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.
- 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 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?