Wednesday, May 27, 2009

About to provide a new snapshot release for components4oaw

Good news, we are about to release a new snapshot release for the adapter to Enterprise Architect and openArchitectureWare.

Ueli is working on new features for statemachines. I do the release management (getting angry with maven as usual). I still have to work on switching to a normal eclipse update site and hope to manage the transition soon. For news on the release check here on the blog or have a look at components4oaw. I hope I will be done by this weekend and you can change to a pre-release of version 1.7.0

By the way: we are always very grateful for feature requests and bug reports.

Friday, May 15, 2009

9 reasons why offshoring projects are bound to fail

If there is an economic turn-down or crisis at the moment, it will surely do one thing: foster interest in offshoring projects for all the wrong reasons. Reason number one, being the desire to cut down software development costs. After the first wave of offshoring projects and the lessons learned by many, I think it is time to highlight again the reasons for failure in blue eyed decisions for offshoring. From 2000-2003 I had been in Bangalore, India and led a development centre for a German client. The impressions listed below are based on this subjective experience and talk to friends and IT developers I meet as a consultant for IT companies. Many of the reasons have been told before, but I have the feeling that they cannot be told to often.

1. Germans don't speaks English
Looking at the success of American and English companies with offshore projects: I wonder: - why are others successful whereas "we/Germans" fail? The first language might be a reason. Oddly enough, when I posted the article to a number of Indian friends, they all concluded that Indians are not very good in speaking or learning German. An issue I would never have thought off - nor expected. Having more than 20 languages listed as languages which enjoy official support by the India Government, Indians tend to be, by and large, wizards in mastering languages. However - I was talking about the ability of the average German to express his/her thoughts clearly and unambiguously in English. Many projects suffer from a failure in project communication. Replacing your native language with a foreign language does not help. I think it is to easy to assume, that only because English is taught in schools, we can also use it professionally at a level which is required to get the job done.

2. Implicit colonial attitude
Many project members look at their offshoring team members with the attitude of a 19th century colonial officer or missionary zealot. Or both. It is easy to find a scapegoat for project problems with that attitude. During my review process for this blog entry an Indian friend told me the following:
I would expand on this point, because it is so important but rarely understood. I agree with you on the point but my own experience with the difficulties in getting this idea across to people even in London for example, makes me feel that crucial idea must be well laid out.
Some people highlight that soft skills are a key factor in making offshoring projects a success. But soft skills are not a tool where you coach people into doing what you want to do them, they are not a tool to interpret a wobbly head shake if it is a yes or no, and neither are they a tool to amuse yourself about the Indian ability to say "understood" if according to our world nothing is clear. If anything, soft skills are the tool to question yourself what it is exactly that makes you "white" (and if you actually like that). They should address your cultural heritage directly, because many of the conflicts arise because of you.


3. All hail the waterfall model
If "we" need to do all the brain work, and them the boilerplate code, GUI frontends, the patching up - it makes sense to send a document over the ocean which contains all the analysis and design before the implementation can start. Hail the waterfall model! It does not work when you sit next door to your analysts, architects and designers - why should it work with a 1000 mile gap in between?

4. The lousy cost of living equals lousy project costs myth
Whenever I hear about off shoring projects, the main driving factor is the desire to reduce costs. Why after all are countries like India so attractive for German companies? Globalization in this context is not a market force which opens new markets for products, but opens new markets for a workforce which has a considerably smaller salary. The comparison in the costs of living is pretty fast equalled to the amount of potential savings for the projects. What is most often neglected in projection costs comparisons and success stories are the substantially increased costs in communication, travel, lawyers, standstills due to different time zones etc. Some of these problems are problems were e.g. American companies are indefinitely better than Germans. Americans are used to different time zones, have a much more multicultural society, are excelling in telephone conferences. We suck at most of these.

5. Who cares if the source code is in German?
Well everyone in your project cares. Have you ever tried to make sense out of Hindi class names? Despite of this, very often the old projects which are ready for maintenance and fixing are being offshored. Exactly those projects which have not been adapted to English as the main documentation and code language. You will have to get someone to a) understand the legacy code, the b) domain and translate the c) non-existing, outdated documentation and d) fix the spaghetti code. If you are done, you probably will already have fixed the problems yourself.

6. The "Oh, hello - who are you?" effect, also known as the good guy left the project syndrome
Personnel fluctuation was a big problem in India, I do not know how much it changed, but I cannot blame anyone for acting like a private version of Homo Economicus. After all, international companies throw around the money to lure people to their company and the next offer used to be just a step away from the freshly signed contract. On the other hand I think the model of comparing programming costs to costs of living is flawed. At least each clever programmer will easily find out, that a line of code which is easily shipped to any destination in the world is truly global and can command a price which is global. So why would anyone code for 1 Rupee if he can make a buck instead? Welcome to a flat world.

7. Mirror, mirror upon the wall, who is the fairest manager of them all?
Offshoring decisions are management decisions. Managers communicate their decisions. Managers are tempted to look good, after all their career depends on making right decisions. I tend to believe that this is the reason why we seldom hear about offshoring failures. Having lived in India I heard from the projects that were taken back. But not from the managers, but from the employees who contributed to new offshoring projects.

8. A plan is a plan is a plan
Plan to avoid the mistakes listed above. Certificates, Add more... Quote from Web: "The problem is to identify the right supplier and even then it takes a lot of work to get the ODC settled and integrated in clients processes. Certificates like CMMI, ISO or SPICE show the suppliers professional orientation, but much more has to be done do successfully integrate the ODC." etc. elaborate.

9. Put your own reason here - leave a comment if you agree or don't.

Reasons for success:

  • Patience: it took us about two years to become remotely successful, to establish best practices and procedures, to build domain knowledge.
  • Agile processes: everything was agile. If it did not work, we would change it. Every single process, every rule, every everything. We were two small companies, and could afford that (or had to endure it?).
  • On-site German speaker (on a local salary): Most of the time I was the only German speaking person within the workforce, and it helped a lot to smooth the transition.
  • Small is beautiful: we made tasks extremely small, since no amount of communication would prevent us from having misunderstandings. Working code led to realizations on both sides.
  • Dedication: My colleagues were the most dedicated bunch of people I ever worked with.
  • We did not exist to save money: Well, at least not primarily. We did exist to enable a company to increase its workforce.
  • Use the domain experts. Some time after I left the company tables turned (a little bit) and the company brought a system to the indian market which they had previously developed together with their German partner. Why is this important. It shows a true partnership and lets each partner excell in the qualities they are good at. If you outsource - outsource Research and Development, not just what you think is the boring part of software developments. Most companies I know of use the knowledge of their local partners in order to bring products to the Indian market, which are adapted to it, brought to it by people who understand the culture etc

Postscript: I had been thinking about this already for quite awhile - the current status of this entry is a draft. Not all the arguments have been polished, some are basically just ideas, but I simply wanted to go ahead.

With gratitude I would like to thank Ray Ayyar, George Kurian and Aditya Dev Sood for their helpful comments and contributions.

Thursday, May 14, 2009

Rephrase this

I tremendously enjoy taking quotes which move me and translate them to the realm of software development -  the domain in which I happen to work. The quote above had been taken from popshot, a magazine about poetry. Here is my variation (I guess it is still a bit lame):
Most developers ignore most architects because most architects ignore most developers
Got your own quote? Leave it as a comment.

Wednesday, May 13, 2009

Providing custom images for the outline view in Xtext/TMF pt 2

I recently installed the M7 build of Xtext and had to make some minor tweaks to get my code running. Doing that, I discovered a simpler way to achieve what I described in

The API either changed slightly, or it make a mistake, but the correct version now looks like this:

public class AnalysisLabelProvider extends DefaultLabelProvider {

 public String image(Actor actor) {
  String image = (actor.isSystem() ? "Node.gif" : "Actor.gif");
  return image;

 public String image(UseCase useCase) {
  return "UseCase.gif";

 public String image(Information information) {
  return "Class.gif";

 public String image(Analysis analysis) {
  return "Model.gif";

 public String image(Issue issue) {
  return "Comment.gif";

 public String image(Step step) {
  return "StructuredActivityNode.gif";

The path to the directory "/icons/ vanished. It is now a default, which can also be configured using guice. BTW, another very nice feature of the new milestone release is the new template mechanism. Read about it in the documentation, it is really easy to use.

Tuesday, May 12, 2009

Xtext M7 released

While I had been on holidays hiking in Sweden Xtext M7 was released. It is brimful of interesting new features and includes many bugfixes. Get the news here: