Column: Year 2000 conversions offer career opportunity

The Year 2000 used to be a long way away. It used to be looked at as a kind of end-of-the-world date, when some sort of higher power was expected to come down and save us all from the environmental and social problems we were busy creating in the meantime.

The Year 2000 used to be a long way away. It used to be looked at as a kind of end-of-the-world date, when some sort of higher power was expected to come down and save us all from the environmental and social problems we were busy creating in the meantime.

It may yet mean the end of the world--for businesses which have done little or nothing about the date field problem in their legacy systems.

So programmers who can take care of the date field problem are going to be very busy--they’ll probably already be raking it in, right?

Well, er, not really.

No one is doing anything much at the moment. Hey, we’ve got a few years left yet; plenty of time.

Well, that depends on the size of your problem. Let’s face it, from October 1 it is just 1187 days away and counting until the moment when system clocks all over the world change from Dec 31, 1999, to Jan 1, 2000, or from 99 to 00 if businesses don’t bother to check out if they have a problem or not--or their solution has not been tested and fails.

One company in the US that is congratulating itself on starting early still has 10 person years left of work to do before the big day.

And the problem isn’t just for those who still have big iron--there are potential problems in many desktop and client-server applications too--many of those have also been written with two-digit date fields and many users are not bothering to test them to find out if they are year 2000 compliant or not.

At risk are home-grown applications that were built using products such as IBM’s VisualAge or Microsoft’s Visual Basic, Visual C++ or Visual FoxPro development environments, where developers created their own date-related code instead of using the year-2000 compliant date sets supplied by vendors.

Older versions of shrink-wrapped spreadsheet, accounting and financial software are also high on the potential problem list.

For example, date-related fields can cause problems in spreadsheet macros which issue forecasts beyond 2000. Or if an insurance policy is due for renewal in 2001, an errant program might recognise the last two digits of that year as 1901 and throw the policy out.

The year 2000 check shouldn’t stop at the applications. Because applications de-pend on the operating system and its associated file system for handling dates, users should check to make sure operating system date functions are year 2000-compliant. According to Microsoft, all of its Windows platforms are year 2000-aware. IBM officials says OS/2 should also be safe.

With all this work out there, are programmers being hired?

Not according to a consultant at Wilson White Associates.

“I’ve seen absolutely no demand--for sale or rent. There is no one saying ‘I’m really good and I can crack this’ and there’s no one saying ‘I need this’. The issue is not being really addressed. There seem to be two camps at the moment--those who figure they have heaps of time and probably won’t start doing anything until 1998-99 and those who are doing nothing at all and will end up dead as dodos.

“The problems will be with legacy applications, systems like ICL VME and VMS, Pick Systems and older DOS applications--specialist programmers with these skills will be in demand. But not yet, it is just not an issue but it will become an issue in 1999. And it will be bigger than a lot of people realise.”

Nick Cardwell of Itec Recruitment is finding the same situation.

“I’ve read a lot of hype about it but had nobody coming to me for any programmers.

“I think you have to look at it in terms of New Zealand being a much smaller market than say New York. And there may be overseas organisations doing the work for the subsidiaries here. There has just been no demand for programmers for year 2000 projects.”

In the US and UK, year 2000 programmers with specialist skills are already in demand as companies start to realise the magnitude of the task they have to carry out to get their systems into a year 2000 compliant state. In some cases in America, Assembler programmers have been able to up their hourly rate to $US75 and COBOL programmers are in short enough supply to be able to ask for $US80,000 to $US100,000 for a conversion.

Join the newsletter!

Error: Please check your email address.
Show Comments

Market Place

[]