By Gary Flood, editor of Software Futures, our sister publication
When you read these words, it’ll be February 1996. To put that in a perspective that might cause you a minor spasm of panic: there are less than 210 weekends left before the end of the century. The Year 2000 will start on a Saturday, which is probably very good news. Because you will be spending between now and that Friday night, December 31st, 1999, spending vast amounts of time and development dollars combing through code. And no, you won’t be re-engineering, re-developing or re-vamping. You’ll be engaged in a simple, desperate drive to stop your company – and maybe your country – breaking its neck on the banana slip of the infamous Year 2000 problem. Say what? You probably know the routine by now, but you decided to forget about it until third quarter of 99. It goes like this: When a lot ofbusiness computer applications were first deployed, in the 1960s (some were rolled out in the 1950s!), space was at a premium, and languages like Cobol typically stored dates in a truncated fashion. Thus programmers quickly became habituated to writing date routines in the form 01-01-96, or MM-DD-YY. That works fine until programs start having to compute around dates that cross (bi-directionally, remember!) century boundaries. This began to happen to some companies in the insurance industry in the mid- 1980s. Because of course there’s no CC for 19 or 20 in a lot of those (now buried? lost? still active?) system calls. So when we deal with 2000 do the two zeros indicate to the computer that it is 1900, 2000, undefined, or an error condition? Well, could be any of the above, right? So slowly but surely there’s been a rising sense of danger in some quarters as organizations begin to fearfully wonder if they’re going to be presented with some Godawful headaches around the turn of the century to do with century invalidity. These problems range from the trivial to the catastrophic. You’ve probably already heard the ones about sweet little old ladies of 104 being invited to kindergarten because the local school records system sees they were born in 88 (only it was 1888, not 1988!). Then there’s the weird danger of things like planes not taking off because computers thrash in panic at the discovery that they haven’t been serviced in 100 years. Then there’ll be headline stories about customers being presented with a hundred years’ worth of unpaid interest on their credit card bills, or perhaps more happily, a hundred years of unearned interest on their savings. Going up the scale of danger, how about old folks not being sent urgent age-related medical screening reminders, because they’re too young? How would you feel if your Dad doesn’t get his prostate test in time because of some dumb hospital program that thinks he should be being fixed for braces instead? And then there’s the danger that companies will screw up their financial health by non-payment or over-payment or mispayment-payment or whatever.
Sobering thoughts for before midnight
The Gartner Group’s Bruce Hall has said in all seriousness that less than half of US companies are likely to be century compliant by the year 2000. Ed Yourdon (in Application Development Strategies, June 1995) produced a quite sobering account of some of the time-line problems. Last year – though you may have been unaware of it – many five year financial forecast programs failed. This year, we’ll have (at least) some five year driver license expiration problems in the US. Next year, look for insurance policy crashes; the year after, credit-card expiration snafus; the year after that, purchase order and one-year contract bugs; and the millennium will herald the start of those age calculation errors that the press will so enjoy writing (remember all those $10m telephone bill stories we thought we’d lived down in the Seventies?). More startlingly – Gartner has done some calculations based on the amount of Cobol out there (no-one really knows – 50 billion lines in production use, according to IDC, wi
th 80% of all code written in the language?) and the industry average cost of fixing lines of code (at least $1.50). It’s seriously predicting a global IT spend on the Year 2000 problem of anywhere between $300bn to $600bn. The lowest figure anyone can come up with is $17.5bn for the US alone. If you want to cross-check with some other ways of putting a metric on all this proposed work, Gartner’s minimum suggested resource allocation is 24 people working for one full year. And also please bear in mind that since you’ll have to test the system practically to death, you’ll need ideally to be at that stage one full year before that possibly cataclysmic Friday night – ie you need to do all this between this month and December 1998. (Gartner has also been so concerned as to suggest that as many as 10% of IT-using companies could go bust directly as a result of the Year 2000 crisis). Think about that. Then think about the fact that the IRS is just starting to look at fixing the problem. Then do what Ed Yourdon recommends – check all your money out in gold coins and go and live on a Pacific island for two years until the dust from the crash of civilization settles!
End of the World
Hence the End Of The World scenario we’ve cheekily quoted from REM. And do you feel fine? Maybe you do if you were one of the far-seeing individuals who made it to the Software Productivity Group (of Westboro, Mass) sponsored Year 2000 conference in Orlando, Florida in October of last year. Of the over 300 attendees, 13% were of IS director level and 18% were CIOs, Senior VPs or VPs, with over half (52%) other management and only 17% on the developer or consultant level. The preponderance of management can be taken as a good sign, for as we’ll see the Year 2000 is not so much a technical as a management issue. Century date change and re-engineering specialist Adpac, of San Francisco, took the opportunity to poll attendees on their current level of awareness and action on Year 2000. Only a handful of organizations can claim they have completed their Year 2000 efforts- most are just becoming aware of the crisis, it seems quite a few folks are still very much at the planning and early adoption stage – only 1% were at the final test stage! But the scale of the problem can be glimpsed by other aspects of the survey. Over ten per cent of the respondents have over 100,000 Cobol programs – not lines of code, programs. Most (27%) have between 2,500 and 10,000, and nearly a fifth simply don’t know how many they’ve got. When asked if there were application or database files that do indeed have only 2-digit years, an astonishing 85% admitted that was so. And a bare majority – 51% in this survey – said they were confident that application components are easily identified by naming techniques.
Fun weekends
It would be easy to continue to throw around some of these mind- numbing statistics, but we think the point is clear: the Year 2000 problem is a problem, and there is a scale of possible dire consequences ranging from no effect to worldwide economic and social catastrophe. Obviously it’s prudent to believe the actual impact on you and your development team is going to be somewhere in the middle – and like it or not, chums, that means that those 200-odd weekends left to the end of the century are more likely than not to be taken up with fixing this problem, rather than any fun stuff (like new development) or sensible stuff (re-engineering badly deteriorating systems). Software Futures was interested in participating in the Orlando experience precisely because we wanted to sift away some of the Armageddon hoopla, so we could try and determine what real live situations and strategies are going on regarding the Millennial Bug. If we heard any phrase in Orlando more often than The year 2000 is a serious problem and we’ve got to start doing something about it, it was Start with inventory management – it’s important! We say this because of all the user war stories (and yes, there are a few – some people are already doin
g the right thing!) the inventory management issue stands out as the common theme. Like they say in metrics, if you don’t measure something, how will you know how you’ve done when you’re finished? Inventory management is the right first step because it can help you answer such firefighting questions as, How much source code is missing from your application portfolio? How many systems can be retired in the next four years with no impact? Tomorrow, find out how actual customer stories show that while the Year 2000 crisis is a real crisis, it’s not an intractable one. Gary Flood gary@apt.usa.globalnews.com
