I'm not a doomsayer - I'm saying "Check your managers!"
rachel
-- Rachel Polanskis Kingswood, Greater Western Sydney, Australia grove@zeta.org.au http://www.zeta.org.au/~grove/grove.html r.polanskis@nepean.uws.edu.au http://www.nepean.uws.edu.au/ccd/ "Yow! Am I having fun yet?!" - John Howard^H^H^H^H^H^H^H^H Zippy the Pinhead---------- Forwarded message ---------- Date: Tue, 6 Jan 1998 22:53:48 +1100 (EST) From: Rachel Polanskis <r.polanskis@nepean.uws.edu.au> To: Stewart Fist <fist@ozemail.com.au> Subject: Re: Y2K tax deductions
On Tue, 6 Jan 1998, Stewart Fist wrote:
> > > > I worry about all the embedded systems that are out there > > in remote regions, or on military hardware that is rotting > > away somewhere in some missile silo. > > > > It might be the hidden rail switch in amongst the weeds, > > the life support machines in a poor and aging hospital, > > the failover system in a foreign nuclear power station > > or the forgotten nuke that's waiting for > > a zero countdown :/ > > > > That's what scares me.... > > But why would a life-support system have a line of software code saying "kill > the bugger off, if the date is 00". I would have thought that embedded > systems are the least likely to have critical date issues -- in fact, I can't > think of any reason why any one of them would. Maybe to warn the pilot that > his system needs checking, or something like that, but embedded systems aren't > like banks, doing financial calcualtions based on dates, etc.
I was thinking of things like poor quality control, bad programming, and oversight by design teams who might cut corners on a specification. It does happen.
Perhaps the system has a time of day clock the same as the CMOS in a PC or something. It might use this clock to synchronise itself with another element of a larger process.
The fact that the clock is wrong is only incidental to the problem - if the code is poorly written, and then poorly tested (that's different to debugging) then a value that might return 0, when in fact it should return another value could possibly cause unstable behaviour.
We're only human beings, and I've seen enough crappy code to prove there's lots of crappy programmers out there - and crappy managers watching over them too.
rachel
-- Rachel Polanskis Kingswood, Greater Western Sydney, Australia grove@zeta.org.au http://www.zeta.org.au/~grove/grove.html r.polanskis@nepean.uws.edu.au http://www.nepean.uws.edu.au/ccd/ "Yow! Am I having fun yet?!" - John Howard^H^H^H^H^H^H^H^H Zippy the Pinhead