Embedded Systems Engineering Standards Column vol 12.1 Jan-Feb 2004 Slow Boat to China?. By Chris Hills

 

have to give the usual disclaimer that that these are my own personal views and not those of the ESE Editor and publisher. or those of my employer at the time..... I now work for Phaedrus Systems Ltd!

 

There is a 75% cut down version for print in ESE. The full one is on my web site at www.phaedsys.org Which you are now reading.

 

Having fallen of the strict standards line last month I will meander again this month before coming back on-line next month. First I should wish you all a Happy and prosperous New Year. The good news is the economy is coming back up and things are improving. More so than you might think!

 

During last year I had several contractors, and some permanent staff call me to see what the market was like and what I could see on the horizon. They were in despair, one saying he did not expect to work again period. I.e. not for the next decade or so! This was because apart from the recession all embedded work was "going to India". I asked around and got some interesting feedback from many sources. The picture is not as simple or as bleak as it appeared.

 

It appeared that indeed much work was going to India because on the face of it India is much cheaper for both software and hardware but there have been problems…

 

Various problems have been related to me. All by people who don't wish to be named. No one likes to admit problems and mistakes. There are a wide range of software houses in the far east. Some were set up by large companies who simply said here is the blue print for CMM level 5 this is how you do it. This produced first-rate software houses that ran at a far lower cost than a similar European or US development team. The trouble is for every one like that: fifty less well-run places sprang up. Just like any other business these can be "not bad" to down right appalling. The other problem is interpretation of the specs…. When it is the team just down the corridor or a few miles down the road these can be sorted reasonably easily by phone and email or at actually going to see them. . Have you tried to sort out a complex problem by phone across time zones to some own who's first language is not English and whose concepts and thinking is entirely different? It's bad enough with the Americans but going the other way it is worse!

 

By all accounts a much higher level of documentation is required that is very precise. Remember things that you take for granted and "everybody knows" may be completely alien to the developers the other side of the world. This should not be a problem as I am sure all your projects are extremely well specified and documented. Also face-to-face meetings are required. This seems to be the normal practice now as the fastest way to cut through the mess that inevitably develops. Experienced companies tend to fly out early to stop the problems sooner. OK so flights are not so expensive these days but it still eats into the budget. Also you have to spend more time and effort on getting the documentation "just right" before you start…. This can cut down on flexibility and into the deadlines. The cost saving doesn't look quite so good any more.

 

Remember it is not just good documentation in the conventional sense but you have to make sure there is no room for misinterpretation by a completely different culture. I am not suggesting any one is wrong or stupid, just different. I recall a similar problem when, many years ago a wild life program about chimpanzees showed the problems with assessing the IQ of chimps. When asked where they would go in the rain the chimps "incorrectly" picked the tree rather than the house. When asked what they would eat they "incorrectly" picked the flowers not the rock (a current bun). So the chimps were giving very sensible answers as far as they were concerned but not the answer was expected. Please note I am not equating any programmers of any nationality to chimpanzees. Though I do some who eat pizzas like….

One thing that came up a couple of times is the caste system. Something I did not consider and was surprised that it was an effect at all. I was told of several cases where it had an effect. Paraphrasing: a manager of a project team was in that position because he was of the right caste and related to some one else in the company who got him the job. As a higher caste than the programmers whatever he said was law and not to be argued with even if it was clearly wrong. Thus the programmers wasted a lot of time and resources, missing deadlines knowing that what they were doing would not work. However due to the cast system they would not say anything. This has been known in UK companies in the past but hopefully is rare now. It appears less rare in India.

 

Time is another problem. I had a lesser case of this when working in Germany some years ago. A German manager asked an American sales rep if the "fortnight" delivery was a German fortnight or an American fortnight. When the sales rep asked what the difference was the German replied that a German fortnight was precisely 14 days…. In the east where time is measured in seasons and decades deadlines don't have the same sort of urgency. More to the point it will be more difficult to control from a distance. Again this sort of thing is not usually built into western project schedules in the same way but by all accounts you have to be ready to accept a very "relaxed" view of deadlines.

 

Also if you have trouble with working out when Thanksgiving and French of German holidays are you should try the Asian calendars!

 

One problem has just started to surface… It appears that most of the software houses use bright eager young graduates straight out of college and work them hard. This means that the teams whilst enthusiastic may not have the same mix of age and experience found in the UK. The word is that they tend to burn out in ten years. This is a somewhat short career. This is not a happy sort of industry it is just a high tech sweatshop. This has caused fewer people to want to do this and also salaries to rise.

Today (9 Feb, 2004) rewarding the latest edition of Computer Consultant (Dec 03/ Jan 04) there is an item discussing the annual wage inflation in India of 30-50%! This is why the inexpensive software shops are either disappearing or using staff that may not be described as software engineers over here! It also went on to say that many outsourcing projects are not delivering either the saving they promised or in some cases delivering at all.

 

This again is eroding the gap in the savings from outsourcing to the East. I was told that on one project it was getting to the point where the Indian programmers were being paid almost the same as the UK programmers on the other half of the project. That sounds fair. Same wages for the same job… but when the other costs were factored in it was realised that not only was moving the project to India not going to give "huge savings" it was actually going to cost more than developing in the UK! India is not the bargain basement the accountants hoped it would be. I think a lot of engineers could have told them that.

 

Another problem for India is that China is undercutting them! China too has it's own problems. One problem that is common with Indian is specifications. Apparently, as with India, these need to be a lot more precise and accurate. You can't assume anything. Sorting out errors is again time consuming and expensive.

 

The other problem hinted at by several people was making sure that only one sub-assembly is done at any one place. In fact I spoke to one company who has things manufactured in china who said the sanitise the information going out so that as far as possible it is not possible to work out want the hardware does. There were various suggestions that if it could be copied... So do make sure the specifications are absolutely complete but sanitised so they don't know what it does.

 

Talking of copying, in China if a company can lay hands on a copy of software and copy it they will not buy and legitimate copies. Piracy is rife though this is not surprising in many ways as in China for the last 50 years the state has owned everything and everything belongs to everyone. So where this leaves you if you need any form of ISO9000 or other validation or auditing I am not sure. Now as the company doing the contracting you may be the only party that a western court can get at to be sued. It is almost impossible to get into China to deal with the companies directly.

 

Incidentally If you do go to China under no circumstances leave your laptop on it's own and encrypt all data and documents on the hard disk.

 

This means that India and China are not the inexpensive places people thought. Yes, they can cost less but it is hard work and the rewards are nothing like as big as they once were. A lot of companies have made a success of it but, quietly, a lot of work is coming back to the UK. The problem is no one is going to admit making a mess of things also why warn the competitors? If you have had to go through the mill let them suffer too. This is why there are no names and dates etc. No one likes to admit to getting it wrong.

 

There is another, surprising, reason why work was disappearing. Since the "new" phenomenon of terrorism which "started on 9/11 2001" the US has been working to safeguard the Homeland. I have noticed that several US companies have moved their UK and European R&D back to the US. Maybe I am being a little harsh here, as I know from the newsgroups that a lot of work had left the US also heading to the Far East. Maybe it is because they now have a surplus of Engineers in the US (one estimate was over 100,000 embedded/electronics people out of work) and rates have fallen it is becoming economical to move R&D back to the US.

 

On the UK good news front Everyone TM is reporting things are getting better. Projects on hold are starting up, and not just the military ones. There are even signs that venture capital is flowing again.

 

On a standards note MISRA-C2 is virtually finished (this time). Next on the working group agenda is looking at a test suite, tool validation and software certification. Some compiler vendors are already looking at MISRA-C conformance for their libraries, certainly the header files as many customers are now working to MISRA-C. I am working on a set for the Keil C166. The other problem is how do you certify the code in your product is MISRA-C compliant without handing over the source? This is also something the MISRA-C working group will be looking at. Also I hope to have comp.lang.c.misra newsgroup running as soon as I can dot the I's and cross the t's on the paperwork so there will be an open forum for discussion.

 

For those of you who would like some light relief I did the anecdote to MISRA-C. Mistray-C! It is a first pass that I did in a quiet moment to look at what it was each MISRA-C1 rule was trying to ban. It is available on http://mistray-c.phaedsys.org any suggestions and especially example code will be welcome. Actually any comments or feedback to these columns would be welcome.

 

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988