Y2K Plan B Missing

by Jon Roland



In Y2Kspeak Plan A is remediation, that is, fixing existing software, Plan B 

is replacement with new software, and Plan C is preparing in case you or 

others you depend on fail to do either Plan A or Plan B for themselves in 

time.



We are now seeing a major shift of attention from Plan As to Plan Cs as more 

and more people realize there just isn't enough time and there aren't enough 

programmers to carry out Plan A successfully. It is now not so much a matter 

of whether systems will go down as how long they will stay down. A few days 

won't matter much, but if it becomes a matter of weeks, months, or even years, 

then all bets are off.



What has been largely missing from this picture are the Plan Bs. Yes, there 

have been a lot of enterprises that have decided to replace old software and 

often the hardware that went with it, but most seem locked in a herd mentality 

that directs them to try to fix existing software instead of replacing it.



The only trouble is, based on informal polling in several fields, the only 

operations that have achieved or seem likely to achieve Y2K compliance are 

those who have opted for replacement. Despite this record, most companies 

continue to throw more money and personnel into remediation, hoping to reduce 

eventual downtime from years to only a few months.



The problem with this herd mentality is that it is the same mentality that got 

us into this Y2K crisis. It fails to recognize that if too many have downtimes 

measuring in the months, the enterprises will fail anyway and it won't have 

made any difference that the downtimes would otherwise have been measured in 

years.



Is Plan B still an option? In most cases yes, but just barely. In another two 

or three months it won't be. Replacing large systems takes time, even if only 

to convert critical data. Bank mergers have involved a lot of this, and it 

usually takes months to work things out.



Software tools exist that can enable competent programmers to rapidly develop 

complex applications in far less time than it ever took before, rapidly enough 

to replace many of these complex systems from scratch, and far more rapidly 

than it would take to find and fix all the bugs.