How vital are computers? : LUSENET : TimeBomb 2000 (Y2000) : One Thread

There is an underlying theme in most of the discussions here, and that is that our society is dependent on computers to function. That's true to some extent, but one thing I think needs to be assesed directly is the question "How truly dependent on these beasts are we?"

Certainly computers pervade almost every factet of modern life. But it seems to me that is we assume that the Y2K issues is going to bring down civilization as we know it then we are making the assumption that civilization does now in fact depend on computerization for it's very existence.

I guess my optimism that civilization will survive this problem, even if we all suffer some pain and anxiety from it, comes from the relatively recent introduction of computerization. Civilization existed just fine for a lot of years before computers, and I'm not talking about 1900 civilization. How many companies had computers in 1960? Not many. Even in 1970? How many personal computers were there in the world in 1980? How many desktops had PC's before 1985? Before 1990?


-- Paul Neuhardt (, April 24, 1998


In the second sentence of the second paragraph above, the phrase "...that IS we assume..." should be "...that IF we assume..."

Sorry about that. I've got a bad case of Fat Finger Syndrome today.

-- Paul Neuhardt (, April 24, 1998.


I think the main thing is time. It took about 10 years (1960 to 1970) to get much of the accounting-type processing moved to computers for the Fortune 1000. It has take almost 20 years for the PC to become universal (I can't spell ubiquitous).

If we started today, we do not have enough time to move all of the accounting stuff to manual processes (and -- brace for flames -- where would we get all the little old ladies in tennis shoes and eye shades?). Seriously, it would take several years of college and accounting school graduates to take up the slack. After all, all of the humans have been "right-sized" out of the picture so that these companies can become lean and mean. Payrolls are down just when the need for people will increase (if we go your route).

In the process control arena, we are doing things that cannot be done manually. Instead of one car every 15 seconds or so, the assembly lines will produce one per hour or something. (Ok, so I made up those numbers, but I don't think they are very far off the mark.) It takes a lot fewer assembly lines with computers to produce a given number of cars than it does assembly lines with only humans.

In our greed, individual and corporate, we have painted ourselves into a corner. I don't think there is an easy way out. I am coming to the conclusion that there is no way out at all.

No one, yet, has been able to assure me that there will be electricity after 12/31/1999. If someone does that, maybe I'll believe that we can find a way out.

"Just because it's not likely doesn't mean it won't happen."


-- George Valentine (, April 24, 1998.

Do we really need to move to fully manual processes? There are a couple of implied assumptions in the concept that anything currently handled through computerization would have to be completely replaced with a manual system, assumptions I would also question before drawing too many conclusions.

1. Every computer system with a Y2K bug will fail completely. Is that true? Persaonlly, I believe a lot of Y2K bugs will express themselves through undersirable or erratic behavior, not total failure. In many cases it should be possible to develop manual work arounds until the systems can be repaired.

2. The skills don't exist in sufficient quantity to handle these things manually. Well, by and large you may very well be right, but people can learn awfully quickly when they have to. Face it, as a percentage of the population, very few people know anything significant about farming anymore, yet a lot of the people here are learning because they believe they have to. Furthermore, if I am right in my supposition above, fewer people will be required.

-- Paul Neuhardt (, April 24, 1998.


If I were a CFO or CEO, I would not knowingly allow an erratic computer system to do things that affect the life of my company. I guess that is why I feel that unless a program or system of programs is proven to be reliable it will not be used at all.

As to your second point, I think the job of convincing someone that they really want to bust their whatever trying to do the accounting or data processing for some company that they have no interest in just won't get done. I think the reaction would be on the order of, "That sounds like a personal problem to me. Why should I try to pull your chestnuts out of the fire?" rather than "Yeah! Sure! I want to work countless hours for minimum wage (or a minimum wage) trying to make up for a mistake you could have avoided."

"Just because it's not likely doesn't mean it won't happen."


-- George Valentine (, April 24, 1998.


When the choice comes down to allowing a computer system to do bad things to your company or allowing the lack of computer systems to be fatal to your company, my guess is that most executives are going to chose bad over fatal.

As for people not working to help out the company in times of crisis, I'm sure that some people will take that attitude. However, I have spent my career working in environments where most people are willing to do what it takes to keep the company afloat and their pay checks rolling in. I know I would. Maybe I've been unusually lucky, but I tend to thnk not.

Your milage may vary.

-- Paul Neuhardt (, April 24, 1998.

How vital are computers to our society? As vital as we make them, which at this point is life or death.

One thing that studying y2k has done for me is make me aware of the technology that supports my life. I run a small business (auto repair). Sure, it's technology driven business, but I was not really unaware of just how much we depended on processors. In our little business I can walk around and point out four computers right away. They have keyboards and monitors. Obvious computers. But....lets go further... There is a fax machine, some electronic multi line phones, some diagnostic equipment, some processor controlled repair equipment, some lube equipment with processors, and probably even one in the coffee maker and stereo.

Can I stay in business if the PC I write on now dies? Yup, no problem. How about the one our customer database and parts inventory is on? Probably, we have backups, but it would hurt to have that old machine croak. It would HAVE to be replaced. We need to manipulate that database for many many uses.

How about the PC I store diagnostic data on? Sure, we could operate, but I would lose a good tool that helps me stay in front. How about the PC that drives our diagnostic scope? Ouch, that would hurt the bottom line at once. What if my brand new 486 powered on board computer scanner goes belly up? That would prevent me from working on newer car computer systems. Bottom line again, not to mention the big $$$ I laid out to buy it would go down the drain.

Looking around this shop, we could lose just about everything BUT my diagnostic equipment and stay in business. If I lose that though, we are dead in the water. My 4000 customers COULD be tracked by hand, we COULD maintain our inventory be hand, but I HAVE to have that diagnostic equipment. Is it going to work past 1-1-2000? No idea, and the makers refuses to answer my questions.

I would have to hire at least one more person to do what we do on PC now. That might hurt the bottom line enough to make it rough.

Lets move on to my suppliers. If my fax machine quits, who cares? If THEIR fax machine quits my parts may come in two days instead of one. OUCH. If THEIR inventory computer dies, they are out of business in 30 days. I have asked, and their entire business is built around automatic parts ordering and J.I.T. delivery.

There are an INCREDIBLE number of old 286's and 386's in this business. That was all you needed, and still is for the most part. Most will have problems with Y2K. (side note: Processors I have found in my shop: (1)8088 (2)286's (1)486 (1)P133 and yes that 8088 is a vital one that I need.)

Thats just a tiny tiny picture of what is within 100 feet of me right now. What about our utilities? What about my suppliers suppliers? My customers employers? Our banks? Etc Etc Etc Etc

Our society is fragile. It's built around automated help. if that automated help faulters the results are unpredictable.

Try getting a tank of gas without using a computer.

-- Art Welling (, April 25, 1998.

Ok Art, fair enough. You've obviusly done some homework and come up with some very good points. Thanks for your thoughful response. Now for the next part of the Y2K puzzle:

Divide the items you mention into two simple groups: Yours and theirs. "Yours" would include diagnostic equipment and "theirs" would include a vendor's inventory system. Start by examining the "yours" group. Ask the following questions, or questions like them, and when possible experiment to determine the answers.

1. How many of these systems are date driven, or are likely to be? You mention computerized diagnostic equipment. Do you ever have to set a date in them? Does the way your diagnostic equipment interacts with a customer's 1995 Buick here in April of 1998 differ from the way it did in November of last year, or April of 1996? If not, there is a good chance that such systems don't have Y2K problems. Remember, the core problem here is an inability to deal with dates correctly, and any individual system that doesn't worry about dates is necessarily immune from Y2K.

2. What can you do to check out systems that are date sensitive? Well, the easy way is to reset the date to sometime in 2000 and see what happens, although do so with caution. As the Yourdons mentions in their book, you want to make sure you have backups and/or replacement units if anything goes blooey and can't be fixed by setting dates back to normal.

3. For systems that are date sensitive, how vital is it that the year be handled correctly? Before you automatically answer "very," consider what is being done with the date. If all that is happening is a time stamp such as printing today's date and the system thinks it's 1900 instead of 2000, would it be okay to pick up a ballpoint pen and correct the error? Sometimes the answer is going to be "yes." Could some erroneous ouput simply be ignored? For date math problems, which direction is the calculation going in? If they are forward only (i.e. "your car's next tune up is due on today + 180 days"), then your system will exibit any problems it's going to have before 1/1/2000 but could concievably be okay after that date.

Once you've asked these questions about "your" systems, you would be in a better position to ask such questions about "their" system, although you would have to do more speculation there. this process can give you a better idea about the direct impact of Y2K on you. Having gone through this myself, and having seen several others do the same, I believe you will find that that while there are certainly problems and risks out there, it may not be as bad as first imagined.

-- Paul Neuhardt (, April 26, 1998.

Paul, Good questions.

How important is the date in my business. Not very. Our accounting is done elsewhere on a compliant machine, and frankly could be done by hand. The database can be manipulated with false dates easily as just two of us use it.

Now...the test equipment. Dates don't matter. TIME is critical. How is that time counted? By an RTC in the machine I would guess. Is that real time clock compliant? Probably not. What will it do after/if it rolls over? No idea. Our equipment is rife with 'embedded' chips and it's a safe bet that NONE are specifically made for these machines. I know some of the people who design this stuff, and they deal with off the shelf as much as possible. Just because I can't set a date in some of this stuff does NOT mean it's not going to be a problem. Speak to some of the guys who work with this stuff and see what I mean. I have. I have talked with guys who order their 'chips' 500,000 at a time for manufacturing purposes, and they really have no idea what 'extra' capabilities those chips have, only that they do what they want at that time. Nor can they answer if those chips are date capable, or what happens when the date changes past limits.

The question is, how critical are these machines to us? Very is my answer. Next question, will these machines make it past 1-1-2000 in an operational condition? I can't answer that. Nobody I have talked to can or will answer that question.

Thats the big problem. No answers. The database software we use is outdated and there is nobody that can tell us what happens when 2000 hits. The machine that runs it is an old 286 and nobody can say if it will work, or if it will suffer from time dilation even if it does. Reset the date you say? The real technoweenies I have spoken to say that's not enough by half. That company that makes those RTC's admit they were not compliant till 96 at BEST. They also won't say what might happen to them on 1-1-2000. Hell, my P-133 probably has a noncompliant motherboard in it!

I presented my little shop as a microcosm of what we face. Just a tiny part of the equation. Just a small glimpse of the unknowns. Multiply that building full of questions by billions, trillions. Any decent size medium business has problems a thousand times worse than mine. Any large enterprise has them a million times worse. The government? Toast in my opinion.

GM's CIO used the term catastrophic in describing their manufacturing plants. Publicly. Think about that.

-- art welling (, April 26, 1998.


Regarding rollover in clock chips, if the clock is counting elapsed time, the issue becomes "when does it's internal register roll over?" Weeks, months, years after start-up? After the last reset? No matter what, it seems unlikely that the problem would be tied to the date 1/1/2000, or any other specific date for that matter. As you mention, many embedded systems may have date functionality built into them that isn't used. While it certainly is possible that year rollover in those chips could cause problems, I tend to doubt it. After all, who cares if the chip knows the correct year if you never ask the chip for a date?

-- Paul Neuhardt (, April 27, 1998.

Oops, pressed "Submit" before I was finished.

As for resetting the clock not being enough, it may not be. On the other hand, it's a heck of start. Besides, when we are talking about PC's and the like, the issue isn't so much the internal clock's date as what the software will do with it. Operating systems might louse up file dates, archive utilities would have a heck of time knowing which versions of files to backup and restore, etc. Software might or might not operate properly depending on the use of dates and date arithmetic in the. All of these are problems, but not necessarily fatal ones. It is concievable that these problems can be ignored or worked around.

Certainly the issues for small businesses are orders of magnitude easier than for an operation such as GM. I don't want anyone to think that I believe otherwise. However, the process of triage to determine risk is basically the same. Furthermore, if you plotted number of systems against some sort of "critcality" scale (say 1 to 10 with 1 being "no fixes required" and 10 being "will die without total remidiation") I bet the two ends of the scale are pretty lightly populated and the middle farily densly so.

Just my guesses, of course.

-- Paul Neuhardt (, April 27, 1998.

This entire thread, while fascinating, points out the me the entire murkiness when dealing with the problem:

It's all uncharted territory. Nobody knows for sure what will happen. All we can say for sure is that something will.

If you've read my other posts, you'll note I'm big on historical perspective. There's no real analogy for this type of problem in history, but we are starting to see companies doing tests by rolling the dates over and seeing what happens.

In the few cases that I'm aware of this being done, here's what happens:

  1. A electrical generator in Hawaii failed safe -- but it failed.

  2. A GM plant in Michigan failed to the point where no one could even get in or out because of the security system. The assembly line ground to a halt. GM's CIO said that they obviously couldn't track hours or cut paychecks because the punch in/out system was non-functional.

    The only solution to the problem was to re-set the clocks to the current date.

    Understand what this means? GM dies. GM's CEO has recently been quotes as saying there are catstrophic Y2K problems in every plant.

Admittedly, this is a very short list of people who've actually done testing -- but that's because so few are at the testing phase.

I invite anyone to roll the dates forward in their shop just to see what happens. Then you'll have some real answers to the question of how dependant are we on computers.

So far, the tests have all been catstrophic. What if your local power company is in the same condition as the one in Hawaii?

"John Smith"

-- "John Smith" (, April 27, 1998.


I would be interested in seeing the information about the power plant in Hawaii and the GM info. Can you give us pointers to where we could find it, either on-line or in print?

-- Paul Neuhardt (, April 28, 1998.

This isn't exactly what you asked but is a good lesson about computer problems. In today's Wall Street Journal section A page 1 column 6 and all of page A14 there is an article about Oxford Health which is an HMO. They switched over to a new computer system in Sept. 1996, with no ease in or back up (sort of like Y2K eh?). Well things went bad right off. It changed this company from one that was making $20-40 million per quarter to losing $75 million in 3rd 1/4 of 97 and $287 million in 4th 1/4 of 97. It's stock price took a bit of a tumble too. $10 in 93, $25 in 94, $50 in 96, peaked at $89 in 97, and now at $18. Now mismanagement helped a lot, but the computer problems were the kickoff. Makes for good reading while thinking about interconnectednes.

-- R. Watt (, April 29, 1998.

I'm very familiar with the Oxford problems. I almost got a job as senior developer for the their data warehouse project a few years ago, and I know the person who did in fact get it. I also have worked with several of the people in their systems group and in other areas of Oxford, so I got to hear a lot of what happened as it happened.

Frankly, every failure has to have a scapegoat, and the IS group was it this time. Not that the project wasn't a complete and utter failure. It was. But what I've heard leads me to believe that IS was one and only one of the problems. Basically, this is a troubled company that made a whole series of bad decisions that caught up with them all at once, not the least of which was trying to grow the company faster than the market would allow. Blaming the problems on computer systems may have been partly true, but it darned sure wasn't the *whole* truth. . Furthermore, you may notice that trying to blame the IS group didn't save the guy who founded the company and was President/CEO. He lost his job too, as did several other top level managers.

This is a good example of how dependant compnies can become on computerization and what happens when the systems fail them. However, like most stories, this one has a lot of other aspects to it, and it is entirely possible that the managers involved could have kept their jobs and the company would not now be in such dire straights if other, non-system problems had not also existed.

-- Paul Neuhardt (, April 29, 1998.

Very interesting thread. A phrase comes to mind: "division of labor". A few personal examples: 1. A friend is an analyst at American Express. He is a gifted statistician and has played with certain probabilities. He estimates that if AmEx lost 25% of its computing capability it would fail financially (after operating for several months with its cash on hand reserves). Loss of 10% would likely cause earnings to completely dry up (and stock prices to plummet). The problem, a firm like AmEx (enter the name of any financial services firm) does literally trillions of calculations a day. The analysis done by my friend often runs models on Unix based systems that run OVERNIGHT CONTINUOSLY to produce their results. This analysis could not be done by even a small army of qualified people (becuse of the comparison features used by the model--the conversations required between batallions of manual processors would use productivity time. By the time the calculations were complete, the data would be essentially useless to the firm). 2. I am an ICU nurse. I currently take care of two very sick people at a time. The reason I can do so is because I have several computers and equipment with embedded controllers for constant intense monitoring, drip calculations, instant blood gas analysis, etc.... at my disposal constantly. Take away that monitoring and tool help capability and I would be very hard pressed to care for one of the life/death sick people I now take care of. I would likely need an assistant (or maybe one assistant for every two nurses). In any event, we would immediately have to double our staff. Two problems: a) there is a shortage of staff already b) the hospital couldn't pay for it (these monitoring systems and embedded controls exist in every unit--the patients just aren't as sick in other areas). I estimate that it would cost the hospital about a 100% increase in labor cost to go back to pre-computer days (assuming we could do all the diagnostics--which isn't the case, but that's a different point). The hosptial currently has about 40 days of operating cash on hand. Since payroll in nursing represents nearly 30% of the expenses, and doubling that cost, the hosptial now has about 28 days of operating capital on hand. Do all the systems get repaired in 28 days? I think highly unlikely--more like 280 days if everything goes well and all the new parts/equipment are/is available.

Now, my professional license and the liability policy that protects it requires that I practice in a safe manner accourding to well-established standards of care. I won't be able to do that 1-1-2000 until well after whatever failures have occurred have been resolved. Neither will physicians. Will be afforded relief by legislation--currently considered legislation in other jurisdictions always includes that sticky little "acting in a prudent manner" or some similar phrase. Easy to interpret a post y2k scenerio as not reasonable or prudent. Bottom line, the legislation doesn't really provide protection. Unfortunately, over the last 20 years, medical professionals have come to consider liability protection more important than care for the sick under any circumstances and there are thousands of lost career--destroyed life examples post lawsuit to support this new priority in practice. Many thousands of providers of nursing and medical care will have to "just say no" until repairs are made post y2k. Many will leave their jobs on leaves of absence during the 4th qtr. of 1999 (unless sooner). Yet the hospital system's board and CEO say no problem and will not listen to reasonable discussions about contigency planning. Oh well. Those of us currently in the trenches are pretty much powerless to effect any change--until people are willing to listen. Will it then be too late? If huge change doesn't occur soon--like in the next several months, it will be too late. The preverbial Titanic will already be on an irreversible course to crash mightily into the iceberg. I'm checking the inflation and supplies in a lifeboat for my family.

-- P. (, April 29, 1998.

For commentary about embedded systems in hospitals, check out some of the posintgs in the "Is Toyota complient" thread. Many of the same principals apply (i.e. are the embedded systems in these machines dependent on date for operation).

-- Paul Neuhardt (, April 29, 1998.

A friend of mine works for a company (Marquette Medical) that makes medical devices. They have a website. I asked her about problems with imbedded systems in those devices. She told me the company is currently trying to track down 25 years worth of devices in at least 10 languages. (this has to be impossible) These things are in hospitals, nursing homes, clinics, private homes, etc..etc. all over the world. The scope of this problem is incredible!

-- Gail (, April 30, 1998.

Here is how reliant we are on computers: Scenario - You wake up on 1/1/2000: 1. Power is off because of imbedded chips. 2. No water because pumps are off. 3. You only have the money in your pocket, ATM's are not working. 4. Stores only have 7 days worth of food, can't reorder. Shelves empty in 8 hours. Stores close. 5. Gangs roam streets looking for food. 6. It's the middle of winter, power is off, you are cold. Lesson here is to be prepared for any scenario.

Check out for more information.

-- Del Ball (, April 30, 1998.

Paul, The devices in hospitals are not analagous to the chips in a car. Considering the well thought out posts of yours I have read, I'm really surprised to see you post that ill informed comment. The "Safe Medical Devices Act" requires that all automated equipment involved in patient care have regular maintanence. They do care what the date is, becuase they "have" to. They track time for a variety of the functions they perform. Furthermore--they always have power, even when turned off and unplugged. While this feature might be overkill and over expensive for a feul injection system (e.g.), it is not for a IV drip controller upon which patient's lives depend! We aren't even in the same galaxy of functionality here when comparing these devices to automobiles. The monitors mftcd by Marquette (which my hospital uses) also track dates and record events. The print out on the strips shows hours, minutes, seconds, day, month, and year--in two digits. Marquette had not yet responded to our formal inquiry about how the machines will respond. However, techs have rolled forward dates during maintanence on a bunch of other equipment (external pacing devices, defibrillators, IV and PCA controllers) some of which is made by Marquette. The devices shut themselves off. In some instances, they were not able to restart the devices. Now, imagine you are a heart patient with bradycardia or an idioventricular rhythm. You are hooked up to all the monitors and IV drip controllers, as well as to a Marquette auto-sensing external defibrillator or pacer. This equipment monitors your heart rhythm from beat to beat and analyzes it based on established parameters. Imagine you are the physician in charge of this patient's care or the nurse likewise responsible. Embedded chips in automobiles analogous to medical equipment???? I think not.

-- P. (, April 30, 1998.

Tracking dates and recording events in a time based manner still doesn't mean that you have Y2K issues, especially if you are using the fact that dates are printed with two digit years. Don't confuse the printout with the internal representation of the date. They may be quite different.

Now, having rolled dates forward and have machines shut down is a potential problem. However, did you determine why they shut down? A lot of these systems track service using those dates. If you suddenly roll the date forward 1 1/2 years, then these machines could have shut down because they thought they had gone over two years without being serviced and were therefore in violation of the rules coded into them! If you serviced them and set the servide date to sometime after 1/1/2000, how many of those machines would have started up again?

Embedded systems in medical equipment are analogous to those in cars at one very important level: You have to know what they are supposed to be doing with the information they collect before you can assess Y2K problems. Obviously these systems are more vital to health and safety, but you still need to know what they are doing with dates (and not just that they use dates) before being able to asses Y2K problems.

-- Paul Neuhardt (, May 01, 1998.

Go to the site and check out the Year 2000 section. They list all the medical equiptment that they have tested for compliance. Most will be ok but some will not. Also note the number of models that were not tested and are no longer supported. Some of these will fail. Just some hard data from one company. Some companies I have contacted flat stated that their equiptment was not compliant but they were working on it. Others refused to talk about it at all on advise of counsel!

-- LM (, May 02, 1998.

Read today's Press Clippings from DeJaegers site. The millennium bug has hit London hospitals. Operations cancelled, screwed up inventory, etc. It's heeeeeeeeeeeeeeeee eeeeeeer!

-- Gail (, May 04, 1998.

I read the article Gail suggested. It's scary. NOT because things went wrong, but because of people's reaction to th problems. Let's examine.

Maybe things are different in England, but after working in two different U.S. medical schools and two national managed care companies, I have yet to meet a surgeon who would be willing to accept "the computer won't let me" as an excuse for not scheduling surgery. And, I can't say that I would blame them. ORs got schduled for a looooooong time before computers took over, and they could be scheduled that way again until the computers get fixed. Shame on any hospital that cancels suregery on the word of some computer scheduling system.

The computer says you don't have supplies in inventory? Wander down to the supply closet and check it out! Sure, it's more inconvienient, but it does work. How do you keep the inventory recordscurrent without the computer? They have some wonderful equipment for that: Paper, pens, ink and people. Will it cost more to do it manually? Sure it will. Will hospital administrators spend the money to protect their revenue stream (i.e. patients' insurance payments)? You betcha they will, because it they don't they go broke. Fast.

Bottom line: You need to do the surgery or you go broke and people's health suffers, so you do what it takes. I would be very interested to see a follow up article a week or so later detailing the London hospital's workarounds for the problem. Alas, solving problems doesn't seem to be as press worthy as having problems these days, so I don't count on seeing anything more about it. Too bad.

-- Paul Neuhardt (, May 07, 1998.

I just read an email from someone who decided he would rather be snide in private than in public. The gist was as follows (my own snide editorializing added, of course):

"Thanks for trying to keep eveyone from panicking. This will make it easier for me to cover my own behind as my plans will take another 13 months to complete and I wouldn't want too many other people getting in my way as I complete my hoarding activities."

This got me to thinking about two related items. First, isn't it amaizing that so many people who expect to use the benefits of civilized society like hospitals, roads and telephones are not willing to pay the price by channeling their efforts into finding solutions to problems on a societal level rather than a personal one? Second, I wonder how many work arounds, actual solutions, and even improvements in the way things are done could be discovered in the next two years if the efforts of so many obviously bright and talented people were focused on finding solutions for everyone and not just on themselves?

I probably shouldn't write messages when I'm in this bad a mood, and I ask everyone's indulgence. Still, if I get even one person thinking about these things (not necessarily agreeing with me, mind you, but just thinking) then I will have accomplished something wothwhile.

-- Paul Neuhardt (, May 07, 1998.


You said:

"This got me to thinking about two related items. First, isn't it amaizing that so many people who expect to use the benefits of civilized society like hospitals, roads and telephones are not willing to pay the price by channeling their efforts into finding solutions to problems on a societal level rather than a personal one? Second, I wonder how many work arounds, actual solutions, and even improvements in the way things are done could be discovered in the next two years if the efforts of so many obviously bright and talented people were focused on finding solutions for everyone and not just on themselves? "

Hospitals and telephones are provided by profit-making institutions. I HAVE been paying the price -- probably more than I have used. I am a net payer.

Roads are provided by a socialistic government. I HAVE been paying the price, in taxes -- probably more than I have used. I am a net payer.

Please, don't try to lay some kind of guilt upon me for using what is there to be used. Not only have I paid for it, but also I have paid for many others to use it as well.

As far as finding solutions go, I believe that it is way too late for that. If 100% of our efforts are spent to make sure that there will be an ample supply of electricity to all parts of the country after y2k, we might have a chance of restoring society. Otherwise, I think we are back to 1850, 1750 something like that. And I DON'T see human nature changing quickly enough for us to all spend 100% of our efforts on prividing electricity for others. It is much more likely that we will provide, as best as we can, for ourselves and our families. I think there is a breakdown in society coming, whistling past the graveyard not withstanding.


"Just because it's not likely doesn't mean it won't happen."

-- George Valentine (, May 08, 1998.


The issue isn't payment for societal benefits, but the expectation of their delivery. Whether or not you feel that you are paying more than your fair share for roads and hospitals, you expect them to be available when you need them. My point is that instead of planning what to do when they are not available, how 'bout investing some time and effort into seeing if they can be kept available?

Of course, you don't believe they can be made available, and you are acting on that belief, so my point doesn't really apply to you. But for anyone who has any faith that civilization won't end, my question stands.

(By the way, isn't it a bit contradictory to talk about overpaying on a per-use basis for things provided by a socialist government? True socilalism would provide all of that stuff out of the tax base, but this isn't an argument for this forum.)

-- Paul Neuhardt (, May 09, 1998.

Moderation questions? read the FAQ