-----Original Message-----
From: Thomas Lunde <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: February 21, 1999 4:19 PM
Subject: Re: [GKD] Training Y2K Specialists
>
>Dear Henry:
>
>Thanks for your in-depth response. I guess what I hear you saying is that
>Y2K personnel are highly specialized and that there is no army of
unemployed
>that could be mobilized to provide manpower.
>
>Chris Reuss responded in another post:
>
>India has them, for instance. India is one of the main profiteers of the
>y2k
>business. According to the Indian association of software producers
>(Nasscom),
>India has y2k orders in the volume of more than 2 billion dollars, and
>demand
>is still bigger than supply.
>
>Thomas:
>
>Now these two answers neatly bracket my dilema. Henry is saying, as have
>others, it is tough to solve and requires a broad range of expertise and
the
>side effects of mistakes may be just as bad as the original problem. On
the
>other hand, I get, it's already taken care of, it's no big deal and by the
>way, we can send the problem offshore to India as they understand
>(apparently) all our languages and our networks and our business models
>better or at least as well as anyone in North America.
>
>Henry wrote:
>
>>- the changes to datebases I referred to earlier do not happen in
>>isolation. Databases can be used by tens, hundreds or even thousands
>>of other programs and changes must be carefully planned and coordinated.
>
>Thomas:
>
>Now I don't have to be an expert to understand this paragragph. And it's
>not hard to see how complex accessing data bases must be and how difficult
>it would be to fix if all that data got scrambled in some way. So, it
seems
>to me that turning that over to programmers a half a world away and
trusting
>them to solve it is the highest form of irresponsibility. After they
finish
>the job, will there be anyone left on our side who can understand all the
>changes they have made or in the worst case, if they fuck it up, do we
still
>have the talent to change it back or forward to a system that works.
>
>Now, I'm sort of a simple guy who fixes washing machines for a living.
It's
>not rocket science but it is amazingly more complex than most would think.
>It requires all the skills - diagnosis - which can often be wrong -
>replacement of parts - which may stress other parts of the system -
external
>factors such as water pressure or wiring problems, etc and etc. Though one
>can go through a 6 month or year course, I can assure you that the variety
>and complexity of the problems you can run into boggle the mind. And this
>is in a very simple system of electro-mechanical design. Because I fix
>broken things, I have a healthy respect for the difficulties of even simple
>problems and I am far from re-assured about the confident tone we are taken
>to this world wide problem.
>
>So, with great persistence, I'm still stuck at my original question. Do we
>have the manpower with the expertise to do the job and if so, what would
>constitute proof? The fact that there does not seem to be much demand for
>Y2K specialists is very suspect given the amounts of money, complexity and
>variety of systems affected and the potential downside if we do not get it
>all fixed. It's easy to have opinions but I'm looking for a few facts. I
>have yet to read a little story of a complete Y2K fix. From analysis,
>diagnosis, repair, testing and final result in terms of manpower and money,
>for even a small company or government dept.
>
>Respectfully,
>
>Thomas Lunde
>
>
>
>Subject: Re: [GKD] Training Y2K Specialists
>
>
>>Good morning all
>>
>>I have been following the debate on training people to fix y2k
>>problems and the apparent lack of success in doing this with some
>>interest.
>>
>>It seems that once again we have people debating an issue about
>>which they have only limited or theoretical knowledge.
>>
>>The reasons that it has not been possible to train droves of staff
>>are many and varied and in my view include at least the following:
>>
>>- fixing the problem in most cases does not involve just changing a
>>few lines of code. In many cases database files must be changed and
>>output layouts modified.
>>
>>Since these outputs are in many cases very specific in nature, fields
>>on forms, data in EDI files, etc, care must be taken with every change.
>>
>>- not all systems that will be effected are what might be thought of
>>as traditional business systems. Many are complex interrelated
>>systems which cannot be changed in isolation. An understanding of the
>>whole process is very often required. With early programming
>>techniques it was much easier to make changes to individual
>>programmes, but that is not true any more.
>>
>>- the changes to datebases I referred to earlier do not happen in
>>isolation. Databases can be used by tens, hundreds or even thousands
>>of other programs and changes must be carefully planned and coordinated.
>>
>>- in the non business systems arena the problems are often much more
>>complex since the date field may play no critical role in the actual
>>function performed by the program but its correct handling is key. I
>>am thinking of equipment used to monitor and drive other activeties
>>such as Numerically Controlled Equipment, data logging systems and of
>>course the whole embedded system cess pool.
>>
>>- there is a huge number of programming languages out there. A
>>single shop, my University for example, may use many different
>>languages for example. For us Natural, Java, Basic, SAS, CSP and a
>>whole host of other less used such as Cobol, Delphi, Fortran, etc are
>>all required just to run the show. This excludes the databases Adabas
>>C & D, Sybase, SGLServer, ESSBASE etc.
>>
>>And then of course come the academic users with their miscellaneous
>>collection of tools.
>>
>>All of these run in a mixture of operating systems and hardware such
>>as our VM/esa and Solaris plus a host of MicroSnear operating
>>systems.
>>
>>While I know that there is more Cobol code created every day than any
>>other language, the bulk of this is generated code. It cannot be
>>fixed by working at code level, hence the lower than expected demand
>>for Cobol programmers, but must be fixed by people who understand the
>>business as descibed in the generation tool used.
>>
>>
>>For anybody, and we looked at it, to train unsophisticated people to
>>do y2k fixing is just not on. The basic mechanical skills yes, but the
>>conceptual ones are much more difficult.
>>
>>Another, and I except rather paternlistic view, is that to train
>>people as y2k fixers who will not later be able to develop into full
>>time programmers because of their lack of aptitude, is not helpful.
>>In fact under SA labour law it is likely to get an employer into very
>>serious labour problems.
>>
>>Anyway those are my pragmatic thoughts on why there has been less
>>success than anticipated in mass training, for what its worth.
>>
>>PS I don't know what happened to the Blair Initiative into mass
>>training in the UK but I suspect it died quietly. Anyone know?
>>
>>Cheers
>>
>>Henry
>>"The old Chinese curse appears to be upon us,
>> we live in interesting times!"
>>=====================================================================
>>Subscribe to the IT Digest, an information resource from Wits Univ.
>>Send e-Mail to [EMAIL PROTECTED] with SUBSCRIBE ITDIGEST
>>and {your_user_id} in the body followed by END on the next line.
>>----------------------------------------------------------------------
>>Henry C Watermeyer 'Phone +27-11-716-3260/8000
>>Director - Computer & Network services Fax +27-11-339-1225
>>University of the Witwatersrand, Johannesburg
>>P/Bag 3, Wits 2050, South Africa mobile +27-(0)82-800-8862
>> //SunSITE.Wits.ac.za //WWW.Wits.ac.za
>>======================================================================
>>
>>
>>
>
