From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1116ece181be1aea X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-09-08 14:14:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!newsfeed.mathworks.com!wn13feed!wn11feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3F5CF12A.6060608@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Is the Writing on the Wall for Ada? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.34.139.183 X-Complaints-To: abuse@comcast.net X-Trace: rwcrnsc54 1063055679 24.34.139.183 (Mon, 08 Sep 2003 21:14:39 GMT) NNTP-Posting-Date: Mon, 08 Sep 2003 21:14:39 GMT Organization: Comcast Online Date: Mon, 08 Sep 2003 21:14:39 GMT Xref: archiver1.google.com comp.lang.ada:42294 Date: 2003-09-08T21:14:39+00:00 List-Id: Alexander Kopilovitch wrote: > Do you think that those software engineers in China and India will be cheap > (and easily available in arbirary quantities) forever? Think about 7-10 years > ahead. Don't forget some projects need quite long maintenance - and Ada is > oriented mainly at those projects. (I am going to say some pretty nasty sounding things, but they all have to do with external factors and experience. I know from experience that there are bright, modivated, and well educated people everywhere. But that matters less than you might think.) The idea of exporting Software Engineering jobs seems great on paper, but it never works in practice. It actually turns out that with low enough telecommunications costs, exporting support jobs and other roles that require people skills is easier. The problem is that Software Engineering is not amenable to classroom teaching. No, that is not right. Programming can be taught in the classroom, not well, but since most good programmers are mostly self-taught anyway, it is not a big deal. The classroom provides at best certification. But with true Software Engineering, which is not about programming, you have to have three things: easy access to computer hardware while learning to program, a mentor, and the experience of working on a large, difficult project with competant people early in your career. This environment has not been available in the third world, and in fact most of the old second world until recently. When will there be enough software engineers available for mentoring? I don't know, but in my career I have mentored perhaps seven or eight individuals. Two were almost instantly capable of mentoring others on their own. The others? Some of them did not have the personality for mentoring. But for the rest, I have to describe it in the old craft idiom, because software engineering should be treated as a craft, since it clearly is one. As I said two of the best who learned software engineering from me were clearly going to reach master status soon. The others were journeymen. Could they eventually become masters? I think so, but it was going to take a decade or more. So as far as I am concerned, it is possible for someone to become a master of software engineering without the gift for teaching. But it is tough, because teaching is really one of the key skills needed for the job. Part of what a software engineer--as opposed to a programmer with the same title--does is develop a style which is appropriate for the type of job being done, and then teaching that style to the rest of the team. I am not talking about indentation, variable naming and the like. That is just detail. I am talking about real software architecture, designing a system which will satisfy the requirements and also be something that humans who maintain or use the system will enjoy. (Enjoy is a much higher standard than "be comfortable with." But it is one of the signs of a good system architecture. Now this doesn't say that someone in India or Pakistan can't develop a style which people in the United States will be comfortable with. It is just that the inevitable culture clash between the people on the project in the US and the foreign development team will create additional problems. (And if the only people on the project in the US are managers, that clash will probably cause insurmountable problems.) So what does work, and I have seen it work, is for a software engineer from India or whereever to become Americanized (or Europeanized) and serve as a buffer and interface between the two part of the project. So the net result is that the cases where I have seen the process working, you wind up with, say, a joint Indian and American development team, and the team members go to the extra? effort to learn one another's culture. Otherwise you can wind up with a system bought and paid for, where you literally have to send your staff abroad for training in how to use it. That doesn't save much money. And yes, when I try to explain this to most managers, it is like explaining the color red to a blind man. You would think that by now everyone would have had experience with foreign interfaces to understand the issue. But most managers for some reason seem to accept their inability to program their VCRs without understanding why the interface is that bad. (I have used well designed VCRs, but they were designed and built as studio equipment by people who had experience working in a studio environment...) -- Robert I. Eachus "As far as I'm concerned, war always means failure." -- Jacques Chirac, President of France "As far as France is concerned, you're right." -- Rush Limbaugh