Snowshoe,
My conclusion from this limited experience was that these fellows did better when: a) they worked with more modern systems rather than legacy systems, and b) they were assigned mainly to programming duties rather than design and analysis.
I agree with your conclusions, and would add this also... The vast majority of all foreign programmers have no idea of the underlying business guidelines for the systems that they program. Many of them have preconceived notions of how things are (or should be) and how business flows. More often than not, they're wrong.
I was a designer/programmer/coder mostly with older COBOL systems. Just prior to early retirement, I was an Oracle database manager, and did some design and coding in the relational systems. (For the record, I prefer the older COBOL systems, which gave the designer/programmer much more flexibility in problem solving, albeit at the sacrifice of quick, easy future changes.)
When we hired outside consultants (to supplement the in-house programming teams), many were foreigners. While these guys knew the relational coding well (SQL, C++, etc.), they were nearly completely blank on the nature of our business (education), very weak on the rules of accounting, and most had never written a single line of COBOL code, so had no idea on how to migrate legacy systems written in COBOL to a relational database. To their credit and much to our amazement, they learned extremely quickly and ultimately were/are an asset to the various project teams. However, we had to spend much time documenting the older legacy systems so that they could understand the migration process. For anyone who has never had to do this, it is a very time consuming chore, with no rewards and most definitely plays havoc with your timelines on current projects. And most legacy programmers find the chore distasteful, because they of course fully understand the legacy systems and don't require the documentation of what, for them, is second nature...
Anyway, my two cents (US) worth...
KJC |
