I have been thinking about my presentation on wind energy that I gave to the Virtual Chapter of the System Safety Society yesterday and wonder if there might not be something even more interesting to do with this topic.
It seems to me that there are currently three main contenders for "solving" our energy problems while helping solve the global warming problem. These three are big wind, big solar and small solar. By "big wind" I mean the really large wind turbines designed specifically as central power generators sending all (or most) of their power to the grid for distribution to utility loads. These are usually, but not always, put into very large collections referred to with the quaint euphemism of "wind farms" as if these giants have anything to do with "green" energy, agriculture or farming. By "big solar" I am referring to the large to extremely large solar power plants that cover hundreds of acres to tens of square miles of land and also sell their power directly to the utilities. By "small solar" I am referring to distributed power generation systems that are primarily intended to provide power on the user side of the meter, but are grid connected so that the owners get the benefit of time shifting production and use. Basically these use the grid as a storage device, often making extra power in the summer months or day light hours and then drawing power from the grid during the winter or nighttime.
At the moment, the only one of these that is close to being economically viable without very large, continuing, government and utility (ratepayer) subsidies is small solar. I have been installing rooftop solar on a few houses near my home and find that I can make a very nice profit while installing systems that have a "payback" time of about 4.5 years, giving the owners an ROI of about 12%-15% for their investment over a period of 25 years or more. Actually, when you run it out they turn out to be free because the solar systems immediately add more to the value of the house than they cost - hence the "payback" is instantaneous. Maybe a better view is that a $12,000 investment can save about $250,000 over twenty years (according to Sandia, based upon long term testing they should have a lifetime of over 40 tears). Right now these systems get significant government incentives and tax breaks - but they are perfectly capable of paying for themselves without that benefit. This is all pretty new news, the cost of solar panels has dropped from about $4 a watt to $1.50 a watt (or less in bulk) during the past year - causing the change in affordability. Interestingly, the cost of systems being installed by my local competitors has not dropped, so you need to shop around if you want to get the correctly priced systems. A little over a year ago I installed a system that cost the owner about $8000. He now is asking me for advice on what new electrical devices he could install to use up the extra power that he generates during the year. His system was particularly expensive because in California we pay on a tiered schedule where the price per watt goes up as you use more power. He was already using the baseline amount so had cheap power to offset. Because of the low cost power being offset it will take him about 6.5 years to pay that system back, but he is happy with it.
My presentation was focused on the "hazards"and risks of big wind. I think it would be very interesting to expand the topic to include the risks and paybacks from these three energy sources - and to make comparisons between them. I am thinking of a panel, a workshop or some other approach to present and discuss a cost-benefit study of the three approaches to determine the best (or most optimal) solution. The amount of material involved is quite large, so it would take a day or so to get through the materials in even a cursory fashion. I think most of this could be done along very traditional hazard based lines, but maybe the definition of a "hazard" might have to be expanded a bit to include financial considerations. Maybe not, maybe it could ignore that and just look at the traditional safety, environment and security (including impacts upon the quality and availability of grid power) aspects of the questions. An interesting example of a security problem is a rumor that I have heard that there is at least one foreseeable condition where the presence of big wind as it is currently operated could bring down the entire power grid in the country for over a year! Now THAT would be a black out to set us back aways. Maybe it is not possible, but I am not at all convinced that it isn't a viable problem.
I think this is a topic that would be worthy of the SSS's attention. As it turns out, it is a topic that is not only not being addressed, but that has been forbidden to be addressed by our government agencies such as the NRTL. It is my understanding that they have been chartered to study the feasibility of each approach, and have the ability to address risks associated with each, but they are not allowed to do anything like an evaluation that compares and contrasts the benefits or costs of each. Therefore, what you find when you search for materials on these topics are descriptions of each as if it were the only choice, you get no assistance in prioritizing the choices. Their work comes down to whether or not a particular approach could be feasible and you get answers that are narrowly focused in that direction.
We are experts in not only doing risk assessments, but in finding the better choices. We come with a built-in systems point of view that could (and would) include the entire grid system including the various generators, the power sources, the environmental and societal impacts, the health impacts, and all the rest. We are probably the only organization in the world that is made up of members specializing in the types of analyses and studies that are needed to address this kind of wide open, extremely important, evaluation.
I think we could tackle this problem and have a really good time doing it. Not only that, but maybe we could actually do something important to "save the world." I know we all think of ourselves as instrumental in doing that (saving the world) already, because it is true. But maybe this is a chance for us to expand our horizons a little bit and actually do something "outside of the box" that could have major, long term, beneficial impacts.
As far as I can determine, one of the major risks associated with the current rush to big wind is that the ability to put variable renewable energy on the grid is that it is a "zero sum game" whereby the grid can only accommodate a certain amount of variable power. We are fast reaching the point where the available space is being filled by big wind, and this will eliminate the options that are much better, much cheaper, and much safer. We (the world) are rushing toward the worst choice, and that is blocking access to the best choices.
This might be something to aim for at the next conference. I am wondering if there is any interest in doing such a project. I am interested and would be willing to help however I can. I think it is an extremely important and time critical issue to get before the rule makers and money spenders before we once again get blocked out of making sane choices.
Tuesday, January 10, 2012
Saturday, February 19, 2011
Hazard Tracking Software
I have created a bit of turmoil in my mind concerning an old software program that I wrote quite a few years ago, called "HazTrac". I originally developed it as a "typewriter" that allowed me to input information as paragraphs and then print it in the required format consisting of columns. I did this by creating a very simple database that allowed me to write in paragraph shaped fields, and then print the information in whatever format was needed. It was quite a handy tool. Once the information was entered into a database, it instantly became obvious that a lot more could be done with it than just print it out. For example, it could be sorted or filtered! The "feature creep" really took off at that point because almost every time I used it, there became a need to do something else with the data. It rapidly became a status and action tracking tool, in addition to just a weird word processor.
The program grew, and morphed into a tangle of programming codes and statements. Luckily, the versions of the database (dBase in those early days) changed enough that I had to eventually scrap my process of adding and modifying an undocumented program, and was forced to rewrite the entire thing. That gave me a much needed chance to do a much better job of designing the software, and of documenting what I was doing. My System Safety engineering firm started to use the program as the basis of much of the work that we did, so I was lucky enough to get feedback from many users and quite a few customers. Each person seemed to have yet more ideas for improvements and changes. After awhile the changes started to slack off and people just used it. My guess is that at that point it was doing the job it was intended to do - help safety engineers and project management document and keep track of the hundreds (or thousands) of safety items.
I then decided that maybe it could be turned into a "product" where I could recoup some of the hundreds of hours of labor that I put into this thing. That decision required a significant modification to the user interface because now it had to be used by unknown customers, rather than "hand trained" engineers. I could no longer rely upon being able to sit down and teach folks how to use the program, it needed to be intuitively obvious. I created a first edition in dBase that ran as a stand alone runtime program. My personal opinion is that it was a pretty good, and extremely useful, tool. I advertised it around and sold a couple of copies - certainly not enough to pay back the effort of turning it into a product.
Then dBase went out of business, over run from competition from Microsoft Access. It was a terrible event from my point of view. dBase was a MUCH better database program, and allowed for a MUCH better user interface. It was a sad moment to be forced by market forces to dump a great program and have to go to the worst of the worst. Access is a terrible program in many ways, but it is what is readily available, so I once again rewrote the code - which ended up with huge change to the user interface necessitated by the functions available using Access. I had to move from something that I considered to be friendly and easy to understand, to something much more clunky. But I eventually got most of the bugs worked out and accepted the lose of functionality necessitated by the change. I still had my eye on the program as a product, so built many of the features this required into the structure of the program. I didn't add all of the "product" features at that time, but provided links and a structure that would allow for fairly easy future enhancements.
I once again advertised it, and talked it up around the Society, but nothing much came of it. I did notice that by that time a number of large firms had started up projects to create their own Hazard Tracking System (HTS), based upon specific contractual program requirements (including MIL-STD-882 and others). I gave up at that point, fearing that once the "big boys" got into the HTS game I would never be able to compete. However, I see that there still is a big opportunity for such a flexible HTS system. Actually, once it became clear that it isn't really a hazard tracking system, but rather an action tracking system, it became obvious that it would be useful for a wide variety of uses.
So now am sitting on this little program and nobody is using it, or even knows how very useful it could be. I am not particularly interested in going back into the code writing business, but sure would like to see the rest of the features that I designed for to be included. The smaller part of the job still needs to be done but I am not really ready to do it myself.
One of the problems that I keep having is that every time I talk to someone about maybe finishing it, the answer is always the same - "sure, I could start from scratch and use your funky little program as a template." That seems like such a terrible waste of time and energy. Some companies have actually attempted that, with the result of spending a lot of money and still not having an easy to use HTS. I would like it to be finished, not started all over again. I have been told that it could be rewritten as an SQL program - it is already written as an SQL program (using some functions, formulas and features built into Access). I suppose there might be some value to migrating to an SQL server, but I don't know what that might be. I attempted to use the SQL code conventions, rather than VBA - but that still doesn't guarantee an error free migration, and in fact is almost certainly going to cause many of the subtle user interface elements to fail.
My desire is to complete what is already there, rather than scrap it and start all over again. If it is finally ever completed, and there becomes a pressing need to migrate to a larger server (such as could be accomplished by migrating to and SQL server) that could be done - but it is likely to be a costly process.
My guess is that nothing is going to be done with it, and it will finally be relegated to the scrap bin of history because it failed to keep up with changes to software applications. It is already probably not compatible with Access 2007 because Microsoft made drastic changes to the basic structure of the database and code, they dropped compatibility with older versions of the program, stranding applications such as HazTrac high and dry.
The program grew, and morphed into a tangle of programming codes and statements. Luckily, the versions of the database (dBase in those early days) changed enough that I had to eventually scrap my process of adding and modifying an undocumented program, and was forced to rewrite the entire thing. That gave me a much needed chance to do a much better job of designing the software, and of documenting what I was doing. My System Safety engineering firm started to use the program as the basis of much of the work that we did, so I was lucky enough to get feedback from many users and quite a few customers. Each person seemed to have yet more ideas for improvements and changes. After awhile the changes started to slack off and people just used it. My guess is that at that point it was doing the job it was intended to do - help safety engineers and project management document and keep track of the hundreds (or thousands) of safety items.
I then decided that maybe it could be turned into a "product" where I could recoup some of the hundreds of hours of labor that I put into this thing. That decision required a significant modification to the user interface because now it had to be used by unknown customers, rather than "hand trained" engineers. I could no longer rely upon being able to sit down and teach folks how to use the program, it needed to be intuitively obvious. I created a first edition in dBase that ran as a stand alone runtime program. My personal opinion is that it was a pretty good, and extremely useful, tool. I advertised it around and sold a couple of copies - certainly not enough to pay back the effort of turning it into a product.
Then dBase went out of business, over run from competition from Microsoft Access. It was a terrible event from my point of view. dBase was a MUCH better database program, and allowed for a MUCH better user interface. It was a sad moment to be forced by market forces to dump a great program and have to go to the worst of the worst. Access is a terrible program in many ways, but it is what is readily available, so I once again rewrote the code - which ended up with huge change to the user interface necessitated by the functions available using Access. I had to move from something that I considered to be friendly and easy to understand, to something much more clunky. But I eventually got most of the bugs worked out and accepted the lose of functionality necessitated by the change. I still had my eye on the program as a product, so built many of the features this required into the structure of the program. I didn't add all of the "product" features at that time, but provided links and a structure that would allow for fairly easy future enhancements.
I once again advertised it, and talked it up around the Society, but nothing much came of it. I did notice that by that time a number of large firms had started up projects to create their own Hazard Tracking System (HTS), based upon specific contractual program requirements (including MIL-STD-882 and others). I gave up at that point, fearing that once the "big boys" got into the HTS game I would never be able to compete. However, I see that there still is a big opportunity for such a flexible HTS system. Actually, once it became clear that it isn't really a hazard tracking system, but rather an action tracking system, it became obvious that it would be useful for a wide variety of uses.
So now am sitting on this little program and nobody is using it, or even knows how very useful it could be. I am not particularly interested in going back into the code writing business, but sure would like to see the rest of the features that I designed for to be included. The smaller part of the job still needs to be done but I am not really ready to do it myself.
One of the problems that I keep having is that every time I talk to someone about maybe finishing it, the answer is always the same - "sure, I could start from scratch and use your funky little program as a template." That seems like such a terrible waste of time and energy. Some companies have actually attempted that, with the result of spending a lot of money and still not having an easy to use HTS. I would like it to be finished, not started all over again. I have been told that it could be rewritten as an SQL program - it is already written as an SQL program (using some functions, formulas and features built into Access). I suppose there might be some value to migrating to an SQL server, but I don't know what that might be. I attempted to use the SQL code conventions, rather than VBA - but that still doesn't guarantee an error free migration, and in fact is almost certainly going to cause many of the subtle user interface elements to fail.
My desire is to complete what is already there, rather than scrap it and start all over again. If it is finally ever completed, and there becomes a pressing need to migrate to a larger server (such as could be accomplished by migrating to and SQL server) that could be done - but it is likely to be a costly process.
My guess is that nothing is going to be done with it, and it will finally be relegated to the scrap bin of history because it failed to keep up with changes to software applications. It is already probably not compatible with Access 2007 because Microsoft made drastic changes to the basic structure of the database and code, they dropped compatibility with older versions of the program, stranding applications such as HazTrac high and dry.
Tuesday, January 18, 2011
Journal of System Safety article for 1st qtr 2011
Once again I find myself sitting at my computer to compose TBD only to realize that I have forgotten the topic that sprang to mind a few weeks ago. I guess I need to sit down and write them when that happens, rather then waiting for them to mature before setting them to print. Luckily, I ran into an interesting topic while having a cup of tea with my morning Buddhist meditation group. I belong to a small group of people in Davis, California (home of the University of California, Davis) who sit together from 6:00 am to 7:00 am. We then go to a little restaurant for a cup of tea and a little chat. Since it is a university town, several members of the group are PhD students studying various sciences, including the life sciences (microbiology, stem cell research and similar topics). This background leads our discussions off on some pretty wild, and interesting, tangents.
Yesterday one of them brought up that she had used me, and my work, as an example in a microbiology presentation. She kind of giggled and suggested that our work (system safety) is similar to the work of something called “micro-RNA” within cells. Apparently a couple of them in our little group of scientists have been referring to me as “the” micro-RNA!)
She went on to explain that these micro-RNA things are a newly discovered part of the cell. They are different from most of the rest of the RNA because they don’t really “do” anything. The DNA is used as a template to make RNA, which in turn makes many other elements of the cell that do the work – most of the RNA particles manufacture the proteins that are required to make the cell work, but they do so rather blindly. Apparently the RNA gets turned on to produce a product or chemical, without much control. Basically, they just start turning out various types of protein.
The micro-RNA things act as a kind of safety engineer. They monitor the amounts and rates of activities from the “doing” parts and adjust them by telling them to stop, to create other materials, to speed up or slow down – basically they are the “system” guys, looking after the overall health and safety of the cell – while allowing the other parts of the cell to make all that is needed for life. If they fail to work properly, many bad things can happen, including illness, cancer or cell death (or death of the entire organism!). Hence, they are the system safety engineers of the cell world in that they make sure that the cell manufacturing elements don’t produce dangerous or toxic products.
She said that it is turning out that this kind of activity is extremely common in nature at the cell level. The doers just get to doing, but need subtle control to do so safely and effectively. Hence her analogy of our role as the micro-RNA of the industrial world. Apparently this approach of some elements being focused on doing things and making things as fast and furiously as possible extends to the macro-world in the projects that we are working on.
I found this to be kind of humorous, but also enlightening because it gave me a slightly different perspective on our role within a product development team. Over the years, I have noticed a definite lack of respect for the importance of our work by not only the rest of the team, but as a feeling of “self-worth” by the system safety engineer as well. There is a feeling that the value is to be had in being creative in the design. If you don’t design something, then you are just an added cost.
The problem that I have observed is a desire by the system safety professional to “do something.” They want to get involved in the process of creation rather than “merely” being regulators. The problem with this is two fold. First, they tend to become vested in their own design ideas – breaking their position of independence which is so critical to their effectiveness in identifying problems and recognizing good solutions. The second problem is that the attempt to create “good” design ideas tends to create conflicts with the design team – causing jealousy and a barrier between the safety engineer and the design team. The design team usually doesn’t want to share the glory with others.
I rather like the analogy of our work to that of the micro-RNA. We don’t actually “do” much in that we don’t design or build anything. However, without a process such as ours to guide and control the process, the designers are not likely to be successful or the final product safe to make or use. The work of the system safety engineer is necessary to achieve success of the enterprise – just as the work of the micro-RNA is necessary for the success of the cell and ultimately of life. Of course, in many situations that work is performed informally by the designers themselves either by following existing codes and standards, or by using “common sense.”
The problems with the use of these informal approaches are many, not the least of which are that the existing standards usually do not completely cover the scope of the potential hazards and are therefore incomplete, the fact that “common sense” doesn’t seem to be all that common. An additional problem is the fact that the designers are influenced by the same type of vested interest as mentioned above. They become “blind” to glaring safety problems in their designs.
I have always found it to be most satisfactory (and satisfying) to keep my role as an assistant in mind while working on a project. I am there to assist in the identification of potential hazards and potential types of solutions. However, it is not my place to actually do the designing. Of course, sometimes I make suggestions about design solutions if I happen to know of them, realizing that I am treading on thin ice when I do so. I find it best to make sure that others actually do the design, and I provide“behind the scenes” assistance – leading them to a better and safer design, but not doing the designing for them. I freely give my knowledge to the designers to help them to be successful and do not take credit for the design. I make sure that they maintain ownership and credit for the design. That approach prevents the formation of jealousy and other problems where my knowledge is not sought after. As far as I am concerned, they can do the designing and get the glory – I get to do the extremely important work of directing the design toward a safe solution.
Saturday, February 4, 2006
IPod Risks
I was driving home yesterday listening to Pete Wilson on KGO. He was talking about a lawsuit that somewhere in the country concerning the IPOD devices. Apparently, the lawsuit claims that the IPOD is “defective” because it allows the user to adjust the volume to 115 db – which is high enough to cause permanent degradation of hearing after something like38 seconds.
Mr. Wilson’s position, which was agreed to by all of the callers, is that this is a frivolous lawsuit and that it is not the place of the legal system to protect people from themselves. His point is that the device has a volume control and you can always turn the volume down and not damage your hearing. He used a number of examples of his thesis such as the ability of some cars to go 150 miles per hour, the extremely load volume used at rock concerts, and the volume control on your car radio (actually I don’t think my car radio can get close to 115 db).
He made an interesting point that for sales to France, Apple has elected to limit the maximum volume to 100 db. He also pointed out that as a news person he has worn very loud earphones for so many years that it has damaged his hearing, and that this was his choice and therefore somehow acceptable.
I find all of this to be interesting. First off, if his employer has been providing him with earphones that have caused permanent hearing damage, they have been breaking the law because OSHA prohibits exposure to noise levels that will result in such injuries. Actually, my guess is that he is getting older and probably was exposed to excessive noise levels in other ways – but he might be correct, his employer might well have been breaking the law.
My guess the reason that Apple limits the noise levels for sales to France is that they are complying with the European Union law which protects people from excessive risks from products. The United States doesn’t seem to think this is very important and has very few laws or regulations designed to protect people from injury from products. The recourse in the USA is to sue the manufacturer, rather than implement safety requirements as part of our law. We end up having a lot of excessively dangerous products until enough people have been injured, or killed, to make a lawsuit worthwhile. Personally, I consider this to be a barbaric approach to product safety, but that is the way that it is. Luckily for us, the European Union is influencing many products on a global scale and we all get additional protection.
Now to the specific issue of whether or not the IPOD is “defective” because of excessive noise levels. I can’t really say one way or another because that is a legal term that can only be decided in court. However, it is my personal opinion that it is defective. My reasoning includes (but is not limited to) the ideas that the manufacturer knows that many of the users will be children, and that children do not necessarily have the ability to make decisions that protect their future health – especially if there is no means available for determining that harm is being done. Parents can’t effective monitor the noise levels being used by their children because the noise is personal in nature, it fills the ear but not the room. From a few feet away the noise is not detectable even if it is turned up full blast. Even if parents happen to discover that they are playing the thing too loud, they can only monitor while the child is in the area – once the kid is away from the parent they can, and do, turn the volume up to full blast. Apple knows this, and knows (or should know) that many children and young people play the device at, or near, full volume most of the time.
There are warnings to not play the device too loud for too long, but there is no way for a person to know what that means. There is no indication that the volume is too loud and dangerous. In fact, there is no immediate way for a person to know that they have damaged their hearing. It takes time, and tests, to determine that one’s hearing has degraded. It is one of those things that sneaks up on you without warning.
So, as it stands millions of young people are potentially exposed to sound levels that are known to cause permanent, and serious, hearing damage. There is no means available for those persons to know the extent of the injuries, or the extent of the risk that they are exposing themselves to. The manufacturer knows all about this, but has elected to take the position that it is better to enhance sales and injury millions of people than to back off a bit and injure none. It appears to be a sales decision, one that is good for them but bad for their customers.
By the way, it isn’t just Apple that is doing this kind of thing, there are other personal music systems (using hear phones) that are every bit as dangerous as the IPOD. It seems to be the norm in the industry to take the position of “let the buyer beware,” but that doesn’t make it right.
Oh yes, I almost forgot to address the issue of the fast cars. It turns out that we do not assume that it is alright for people to drive as fast as they want and take whatever risks they want. We have lots of laws that limit speeds to what is considered “safe enough.” Speeding is not okay, and is actively regulated throughout the country. I personally think building cars that are capable of 150 mph is crazy since there is no place to legally drive them except on a race track. Race tracks are an entirely different issue, and in fact are heavily regulated themselves, including special vehicle designs, special driver training, and self-regulations by the industry. Building a fast car in an environment where speed is highly regulated and the risks are relatively easy to judge is not at all the same thing as handing a dangerous device to a child and hoping that they don’t harm themselves – especially when neither the child nor the supervising parent can determine what is risky and what is not.
Mr. Wilson’s position, which was agreed to by all of the callers, is that this is a frivolous lawsuit and that it is not the place of the legal system to protect people from themselves. His point is that the device has a volume control and you can always turn the volume down and not damage your hearing. He used a number of examples of his thesis such as the ability of some cars to go 150 miles per hour, the extremely load volume used at rock concerts, and the volume control on your car radio (actually I don’t think my car radio can get close to 115 db).
He made an interesting point that for sales to France, Apple has elected to limit the maximum volume to 100 db. He also pointed out that as a news person he has worn very loud earphones for so many years that it has damaged his hearing, and that this was his choice and therefore somehow acceptable.
I find all of this to be interesting. First off, if his employer has been providing him with earphones that have caused permanent hearing damage, they have been breaking the law because OSHA prohibits exposure to noise levels that will result in such injuries. Actually, my guess is that he is getting older and probably was exposed to excessive noise levels in other ways – but he might be correct, his employer might well have been breaking the law.
My guess the reason that Apple limits the noise levels for sales to France is that they are complying with the European Union law which protects people from excessive risks from products. The United States doesn’t seem to think this is very important and has very few laws or regulations designed to protect people from injury from products. The recourse in the USA is to sue the manufacturer, rather than implement safety requirements as part of our law. We end up having a lot of excessively dangerous products until enough people have been injured, or killed, to make a lawsuit worthwhile. Personally, I consider this to be a barbaric approach to product safety, but that is the way that it is. Luckily for us, the European Union is influencing many products on a global scale and we all get additional protection.
Now to the specific issue of whether or not the IPOD is “defective” because of excessive noise levels. I can’t really say one way or another because that is a legal term that can only be decided in court. However, it is my personal opinion that it is defective. My reasoning includes (but is not limited to) the ideas that the manufacturer knows that many of the users will be children, and that children do not necessarily have the ability to make decisions that protect their future health – especially if there is no means available for determining that harm is being done. Parents can’t effective monitor the noise levels being used by their children because the noise is personal in nature, it fills the ear but not the room. From a few feet away the noise is not detectable even if it is turned up full blast. Even if parents happen to discover that they are playing the thing too loud, they can only monitor while the child is in the area – once the kid is away from the parent they can, and do, turn the volume up to full blast. Apple knows this, and knows (or should know) that many children and young people play the device at, or near, full volume most of the time.
There are warnings to not play the device too loud for too long, but there is no way for a person to know what that means. There is no indication that the volume is too loud and dangerous. In fact, there is no immediate way for a person to know that they have damaged their hearing. It takes time, and tests, to determine that one’s hearing has degraded. It is one of those things that sneaks up on you without warning.
So, as it stands millions of young people are potentially exposed to sound levels that are known to cause permanent, and serious, hearing damage. There is no means available for those persons to know the extent of the injuries, or the extent of the risk that they are exposing themselves to. The manufacturer knows all about this, but has elected to take the position that it is better to enhance sales and injury millions of people than to back off a bit and injure none. It appears to be a sales decision, one that is good for them but bad for their customers.
By the way, it isn’t just Apple that is doing this kind of thing, there are other personal music systems (using hear phones) that are every bit as dangerous as the IPOD. It seems to be the norm in the industry to take the position of “let the buyer beware,” but that doesn’t make it right.
Oh yes, I almost forgot to address the issue of the fast cars. It turns out that we do not assume that it is alright for people to drive as fast as they want and take whatever risks they want. We have lots of laws that limit speeds to what is considered “safe enough.” Speeding is not okay, and is actively regulated throughout the country. I personally think building cars that are capable of 150 mph is crazy since there is no place to legally drive them except on a race track. Race tracks are an entirely different issue, and in fact are heavily regulated themselves, including special vehicle designs, special driver training, and self-regulations by the industry. Building a fast car in an environment where speed is highly regulated and the risks are relatively easy to judge is not at all the same thing as handing a dangerous device to a child and hoping that they don’t harm themselves – especially when neither the child nor the supervising parent can determine what is risky and what is not.
Subscribe to:
Posts (Atom)