On ethics: engineers compared to programmers
from the is-there-a-programmers-code-of-ethics dept.
An engineer points out that the engineering professions have codes of ethics that guide them in designing for safety and in communicating with the public, and that these are not being followed by some programmers: "It seems to me that as a nanomechanical engineer (or rather a mechanical engineer with an interest in nanomechanics), I was permanently "conditioned" to always think of the ethics behind a design by "upping the safety factor" on my design. If your daily dealing with deadly machines — or rather machines that can cause harm to the public — then as an engineer I am obligated to design something that has a higher safety factor than someone who designs air conditioning systems. This fact, or rather a standard rule of engineering practice, has been overlooked by Joy and his counterparts…My point is this, that as a general rule engineers create highly reliable systems that must have a certain safety factor included whenever there is the slightest chance of harm to the public. I, or rather we, as engineers (Civil, mechanical, (High power) Electrical), are always worried about the safety factors we have set on a design…I think I might be over simplifying the issue but ultimately I have a hard time understanding why so many programmers are a) claiming to have a solid understanding of safety factors when their job has only a few instances for life or death of the public and b), if they follow the same code of ethics set forth by the state governmental systems, why is it they are not lumped together with the rest of the classically trained engineers? One other thing, if they are, then didn't they see that part in the ethics section about slandering or speaking out to the public on something in which they have no educated knowledge?… I would love to hear what the software "engineers" have to say about this particular essay in order for me to learn more about their trade." Read More for the full post. I don't understand how so many programmers are speaking out for engineerís sake. Bill Joy, a programmer/ electrical engineer is speaking on a subject of which he has little interest.
It seems to me that as a nanomechanical engineer (or rather a mechanical engineer with an interest in nanomechanics), I was permanently "conditioned" to always think of the ethics behind a design by "upping the safety factor" on my design. If your daily dealing with deadly machines — or rather machines that can cause harm to the public — then as an engineer I am obligated to design something that has a higher safety factor than someone who designs air conditioning systems. This fact, or rather a standard rule of engineering practice, has been overlooked by Joy and his counterparts because last time I looked I was not (nor was anyone else) killed the last time Windows crashed.
My point is this, that as a general rule engineers create highly reliable systems that must have a certain safety factor included whenever there is the slightest chance of harm to the public. I, or rather we, as engineers (Civil, mechanical, (High power) Electrical), are always worried about the safety factors we have set on a design. This is not to mention that people who make toys, medical equipment, and other devices have had a serious background in failure theory and have been warned about the entire safety factor area.
I think I might be over simplifying the issue but ultimately I have a hard time understanding why so many programmers are a) claiming to have a solid understanding of safety factors when their job has only a few instances for life or death of the public and b), if they follow the same code of ethics set forth by the state governmental systems, why is it they are not lumped together with the rest of the classically trained engineers?
One other thing, if they are, then didn't they see that part in the ethics section about slandering or speaking out to the public on something in which they have no educated knowledge? The system is there for a reason. It works. I do believe that it, the system, is changing but I don't believe that all of the work done in the past has been in vain. I personally have read a decent amount of engineering philosophy (including Henry Petroski's "To Engineer is Human") and I for one believe that a classically trained engineer is not out to destroy himself/herself or the society that he/she works for. I would love to hear what the software "engineers" have to say about this particular essay in order for me to learn more about their trade.
"I am Engineer, Scientist, Mathematician, Exacting Artist. I don't care what you label me I am still Me." – Anonymous



December 31st, 2000 at 8:02 PM
Good Point!
This is an excellent point, and one completely ignored by the likes of Bill Joy. I am a control systems engineer. I design and implement PLC-based and PC-based control systems for various process control applications, mainly high-vacumn process equipment. I have worked with DCS systems as well. The main difference between what I do and what IT people do is that, in some cases of my work, if it goes wrong, $millions of damage will occur as well as the possibility of death. Anyone who has worked in chemical processing plant or semiconductor fab can tell you that there are toxic chemicals and gases that can kill you very quickly, if not handled properly.
Safety is always an issue, whether it be petroleum refining, semiconductor fabrication, or biotech/nanotech production. That's why we always use standardized safety protocols when doing anything dangerous.
Perhaps some government regulation is in order. However, much of this can be done by non-governmental organizations such as UL and other industry safety standards. However, much discussion about nanotech and biotech has had little to do with safety issues, and that the issue of safety is often used as a smoke-screen for those who promote illiberal political agendas (liberal being defined in the classic 19th century sense).
December 31st, 2000 at 10:18 PM
Programmers vs. Engineers
This post would've been quite flameworthy had it been put up on Usenet in the old days. There are a lot of misperceptions in it about what programmers (particularly Bill Joy) do and don't do. Let me take a shot at a few.
Bill Joy works as the Chief Architect of Sun Microsystems which develops hardware and software around the Unix operating system, so he wouldn't particularly care about crashes of MS-Windows. Systems from his company (and companies like his) are used to control many critical operations (at least to their customers perceptions). If I remember correctly, their systems play a big part in the real-time management of trains, planes, and automobiles. As an original developer of Berkeley Unix, he certainly has a long track record in the high-tech industry.
Programming, unlike engineering, is still more art than science. There is also still a lot of reinventing the wheel going on as programmers strive to find the best practices for all situations. It may be in the nature of the beast that programming does not simply break down into a series of AND and OR gates.
Returning to the subject at hand, though, both Joy and Kurzweil postulate taking programmers and engineers out of the picture all together in that future systems will build themselves. Kurzweil sees this as a good thing in that it will allow the Moore's Law curve to continue to accelerate and thereby lead to fantastic new capabilities. Joy worries that this could lead to humans being left behind as our own systems simply decide that humanity no longer has any worth.
Personally, I think neither of them has really contended with the effects Murphy will have on this future.
January 2nd, 2001 at 1:24 AM
Software is still Engineering
I will write a short reply, but it cannot do entire justice to the topic, which would require a couple of pages to flesh out the issues and make sure that I am fully explaining my position. As an engineer interested in the profession, your comments have raised my interest, so I would at least like to offer a few perspectives.
You suggest that as a general rule, Engineers create highly reliable systems, and you mention civil, and electrical engineers.
Software Engineers have a similar goal. Consider the following:
A software engineer works on a project to define a software architecture, and therefore must be concerned with the totality of the architecture as a design. The engineer must consider the commercial problem, and the economics of the design. The architecture must be reliable and fail safe, it must satisfy whatever potential risks are involved in the system (loss of human life, major financial loss, etc). The engineer must make all of the appropriate trade offs to satsify the various conditions – it is not just a technical problem. This seems little different to engineers in other professions. Some examples: (1) consider software written for a patient monitoring system, or an infusion pump system, this software must be of exceptionally high quality otherwise human life will be lost. (2) consider software written for a major product line system, this software must take into account current and future requirements, and factor in the costs of failure.
I could suggest that you investigate the work of the Software Engineering Institute at Carneigne Mellon University (www.sei.cmu.edu), and the work of Watts Humphrey who takes a manufacturing approach to software quality. In general, the SEI is concerned with various perspectives on the software profession. For instance, their work on software architectures and problems domain can be seen as factoring out codifying engineering design knowledge, and quantifying the costs and tradeoffs and various other factors of designs – all important engineering activities. I would agree that a lot of software at the moment does not come close to being "engineering", but I think that is a result of various reasons (e.g. 1. the immaturity of the profession, as it has yet to codify design forms and understand structural principles in software and so on, 2. the excessive commercial need for software as a means of economic survival that takes a low quality approach because of commercial necessity)
You say that no one was killed the last time that windows crashed, perhaps not. However, it is possible to quantify the economic costs of bad software, and of software used badly. For instance, Windows is not consideredly highly reliable software, and would not be an engineering choice for a robust system. An engineer that did choose windows for such a system would be irresponsible bordering on negligent. Like other fields of engineering, engineers must make material choices ("design decisions") of appropriateness according to the situation at hand, and for that, they need information (i.e. information about reliability). For instance, an engineer designing a highly secure system would choose a security rated C1 to C4 system. The particular level of security would be chosen according to the system being designed – a public access workstation requires a less secure system than a healthcare patient record system, and in both cases, the engineer has responsibility to choose appropriately. Otherwise, should the system fail to meet requirements (contractual conditions!), then some one bears the cost of the fault, and that could be the engineer if he or she acted negligently.
Different people require different understandings of design safety and ethics. An engineer who writes subterranean software should be concerned with component reliability in the same way that an engineer who designs metallic pipes is concerned with thermal and material characteristics. Both engineers are a smaller part of a larger process, and that larger process may involve a calculation of risks involving human life. A civil engineer must factor in all risks in a bridge design to ensure that it does not fail. A building architect may produce the "overall strategy" (as a complex interplay of many aeshetic, social and other factors), and the building engineer must ensure that the implementation will work (as a complex interplay of component risks, tradeoff, design judgements, lifecycle considerations, etc).
As in any engineering process, risks are contextually relevant, and it is only at the top end of the system that all risks come together.
The space shuttle disaster is a prime example. The O rings are a subterranean component, and although just a small component, they need to be designed and used in a responsible manner. An engineer taking a larger perespective (i.e. the systems engineer responsible for the entire space craft) takes an engineering approach to factor in the risks of all components and various other aspects to determine an overall risk. That seemingly small component therefore feeds into a larger system that does affect human life. The O ring engineer must take responsibility within his/her context, and the spacecraft engineer within his/her context.
Different horses for different courses. Life is about tradeoffs, decisions and many different things. Computer game software may not need to be highly reliable (largely, the software is at the behest of the market, bad software does not sell, and therefore producing it is a bad commercial choice). Health care software does need to be highly reliable, because it directly affects human life. In the future, perhaps computer game software will need to be reliable when it becomes obvious that it could be dangerous if it failed.
Best regards,
January 2nd, 2001 at 1:47 AM
Re:Programmers vs. Engineers
… Programming, unlike engineering, is still more art than science. There is also still a lot of reinventing the wheel going on as programmers strive to find the best practices for all situations. It may be in the nature of the beast that programming does not simply break down into a series of AND and OR gates.
I think that this is due to the immaturity of the profession. Look at the work in the field of design patterns, there has been a concerted effort to develop design patterns and codify design forms. This will continue, and will continue to lead the way to a more component based approach to software. I know that some of this is all fashionable and buzzwordy, but it is also an expected path of development if you look at how other fields of engineering have matured. Underneath each disciple of engineer lies a similar set of principles: design processes, economic trade offs, structural properties, design forms, etc. I think software engineers could learn a lot by having a common base with other engineers grounded in understanding systems and so on.
I hope to see a future where engineers can design software systems using prebuilt components, with known structural properties. I expect that computer scientists will continue to have a role in producing new components as needed. In the same way that materials engineers produce new materials for construction engineers. Again, more interdisciplinary similarities.
At the moment, it is all a bit messy. Software is a huge part of the informational age, and there is a high need for it, partially because it is the basis for a lot of economic survival at the moment. This drive to produce is in many ways neglecting reflection and development of the profesion. Also, many people writing software could not care less about furthering the disciple, they are earning a buck to live for the weekend – so be it, each to their own – but what this means is that there is a cultural momentum that takes time to overcome as new practices enter and permeate the fabric. Commercial need does drive this though: the relentless pressure for faster and cheaper does mean that component based approaches to production (which economically better!) will take hold, but it requires time.
Programming can be seen as a subset of engineering.
Engineers are sometimes artists. It depends upon the engineering. Not all engineers work at the innovative edge which is more artful. All professions have a degree of artfulness, and over time, this tends to be codified into a science and become routineised. The development of design patterns and architectural forms in software does require a certion amount of artfulness, but over time, when good practices are discovered, it will become more like a science. By that time, we will be thinking about other difficult problems.
(over the past 6 months I have been wandering around Europe on a sort of cultural sabbatical, able to see much great art, architecture and engineering – what humanity has achieved is no less than astonishing)
Best regards,
Matthew Gream
Berlin, Germany.
January 3rd, 2001 at 1:27 AM
Trust me, I know what I'm doing??
The fact that there are some engineers with ethical guidelines, does not mean a technology is by definition safe. Arguing that people should not worry, because well-trained engineers are working on the topic and they know what they are doing, AND that people who are not experts should shut up, seems naive and arrogant. It is evident that there are engineers that follow good practices in designing systems, as well as there are software engineers that take into consideration the implications of their creations. If a technology is safe, it is up to the experts to convince the non-believers, not by stating their ignorance, but by giving solid evidence and convincing arguments.
January 3rd, 2001 at 3:41 AM
Re:Trust me, I know what I'm doing??
First of all, the engineer who wrote the original message is interested in safety why else would he say so?! Or did the safety factor stuff make you think that he was out to create gray goo. There are also some things that don't fit logically in this reply. I will attempt to work with each sentence and then the context. 1) The fact that there are some engineers with ethical guidelines, does not mean a technology is by definition safe. One of the major problems with this statement is that it lacks a basic understanding that technology is and always will be a dual edged sword. All science and all technology can be used for good or bad and the intended use is up to the user alone. The creator or in this case the engineer can only restrict use to a point. This type of belief can lead to the engineers running all of society telling it where to go and how to use the knowledge it has reaped through the fields of math and science. 2)"Arguing that people should not worry, because well-trained engineers are working on the topic and they know what they are doing, AND that people who are not experts should shut up, seems naive and arrogant." Engineers do build structures and machines everyday and the idea of "being well trained" means that one can say they know what they are doing. Although, I suppose some people believe "higher (Longer and more in depth)" education can lead to the belief that you, personally can make a difference, which it is naive and arrogant to believe that the last generation didn't do a good enough job. (Because if they did it wouldn't need changing.) 3)"It is evident that there are engineers that follow good practices in designing systems, as well as there are software engineers that take into consideration the implications of their creations." This sentence states exactly what the original message stated except for the fact that it seems to assume that the engineers who follow good practices are in the minority. This is not true. It should have been evident all along. 4)"If a technology is safe, it is up to the experts to convince the non-believers, not by stating their ignorance, but by giving solid evidence and convincing arguments." What if all of the safety issues can be addressed through only technical matters. The question arises, is it safe? The engineer who specializes in this field or rather, has done exhaustive research in it, should know more than the person asking the initial question. If not his research has been pointless. He states it is safe. This reason is technical in nature (One of the best reasons out there) but the person asking is it safe doesn't understand and therefore deems it impossible. The best way to deal with something that you believe is important is to get involved, study it and prove the person's convictions are weak and unsubstantiated by logic. If you truly believe it will destroy the world get involved with the logic, the science and the math. DO NOT STAND ON THE SIDELINES SHOUTING THE SKY IS FALLING BECAUSE PEOPLE WILL NOT LISTEN. Engineers, Scientists and Mathematicians have work hard earning the knowledge they have as well as the degree and they will rarely take a non-technical degree seriously. This is just how it is you want to tell them about their chosen field get a degree in it or get a PhD in it. The context I believe has been addressed. One more thing we already have proven it will go ahead in a safe fashion to the U.S. government as well as other governments. This is not to say that the fight for recognition is over but we are past the halfway point. Passionate people are accumulating knowledge and I don't think there is a force on earth that can stop a truly passionate person.
January 3rd, 2001 at 5:24 AM
Re:Trust me, I know what I'm doing??
Higher education does not make someone perfect but it does say that they know more about the subject and are therefore more unlikely to fail. Trust me I know what I doing and If you don't trust me trust the ABET accreditation board and if you don't trust them then trust your local government that sets requirements for engineers and if you don't trust them trust in the people around you who voted them into office. If you don't trust any of these people develop a rocketship yourself and move off the planet because living in a society means that you trust others implicity(not explicity).
January 6th, 2001 at 1:10 AM
Software engineering is no different
I'm not entirely sure I understand what your point is. Programming is little different from any other engineering activity with respect to standards of professional ethics and conduct. The only major difference I see is that so far we have managed to avoid the temptation to set up any kind of government imposed professional licensing racket.
The principal professional organization of the software trade, the Associate for Computing Machinery (ACM), has a long established code of ethics which members are expected to abide by. See http://www.acm.org/constitution/code.html.
The other major player in this area, the IEEE Computer Society, has a very active professional standards development and certification process. See http://www.computer.org.