When offshore works - a positive sample (Part 3)

In last posting I described some constaints for offshore projects and got an interesting comment. Michael asked me about my positive experience in offshore area.

In one project, offshore, actually nearshore, saved not only money, but also increased the software qualitity. It was an embedded project in telematic area. We decided to implement multilayer architecture with Java. But we had also some constaints regarding the operating system and the CPU. We needed real time extensions of Linux. But we had another, bigger problem - there was no JVM available for this CPU and OS, so we had to provide a JVM implementation for the target platform. We decided to use the free, opensource kaffe implementation for this purpose. So we needed someone to do this work. From my perspective it was nearly "mission impossible" (I'm not a great C-expert). But we found a company in Poland called adescom. The specification was simple: "we need a working JVM for the target platform and real time linux". Non functional requirements: "performance should be great and resource consumption low". So we sent the spec and wait some weeks for the result. ...and it worked! I was pleasently surprised about the result's quality. I was only one time in Katowice (the polish city) to support the developers on the Java side and resolve some classloader problems. After some pair-programming like sessions and some pizzas, we resolved all problems. It was really a good experience. From my perspective this solution worked because:

We (development team) and not management decided to outsource some work.
The effort to define the specification was really low (actually the two sentences)
In the nearshore-company we met real experts and not "only" developers. They were really interested in implementation of this solution and had also good ideas to improve the quality.
The amount of communication was really low.
It was really easy to measure the quality of the result.

Comments:

"4. The amount of communication was really low."

In most cases the lack of (or inefficient) communication is the most significant reason for failure.

"5. It was really easy to measure the quality of the result."

Interesting. How did you actually verify that their implementation worked? Does Sun have some kind of test suite for JVM implementations?

Anyway I think that your project was an exception. It is extremely rare that you can specify requirements with two sentences, not communicate at all and easily, quickly and reliably verify the quality of the implementation.

Posted by Not a good example on July 31, 2006 at 02:54 PM CEST #

I agree with you. But see my other postings about offshore... This project WAS an exception. In all other projects the communication problems were really hard (if not impossible) to solve.

5.) We not needed the whole Java functionality, but only a subset. Our application already worked in test enviroment, so it was easy to verify the functionality (with JUnit, JunitPerf, and field tests)

It is perhaps not a good example, but one positive :-)

Posted by Adam Bien on July 31, 2006 at 03:02 PM CEST #