Hi this whole course, this MOOC was about tools and how to use them. We experimented with Rhapsody, we took a tour through NetBeans and JUnit. Now we're going to talk about ethics in design. That's a bit discontinuous isn't it? Well, yes and no. All along, I've been sending the message that you need to know a lot more than just the basics of design. You need to know hardware, you need to know tools, you need to know what other people are doing. Ethics is another thing that you have to think about. It may occur if you work for a large company that there's a code of ethics. What more do you need? It tells you not to steal things from the company, it tells you not to hand over proprietary information to non company or unauthorized people. And buried somewhere in there, it might tell you not to make or accept bribes, or have the appearance of conflicts of interest. But really when it comes down to it, this ethics codes they're just rules. This isn't what ethics is about, you can follow all the rules and still not be ethical because the rules don't cover everything you might encounter. In fact, that's why this talk and the next are important. We're going to cover what happens when the rules don't cover the situation. There are two broad areas we'll cover. The first, this talk is going to be about personal ethics, and personal decisions you have to make in the workplace. The next talk will address project related ethical situations. And believe me, company rules don't cover these situations. So for the personal ethics, what's that all about? As a designer, you're working with the nuts and bolts of the project. You're on a much lower level of effort than management. You will be exposed to inconsistencies and problems of which management's unaware. Let me outline a couple of situations. The first involved a project where there were two of us participating in a design and sometimes the coding, it was a small project, of a web server. This is a well funded research project and the operation of the web server was critical in the novelty of the research. The difference in experience between myself and the other designer was huge. I had been coding before the other person had been born. I had an entire career under my belt by the time this person even wrote a line of code. What this meant was that the actions that seemed innocuous to others raised red flags for me. We were looking for a better look and feel to our web presence. And the other developer found a cascading style sheet which when included with the project, made the screens look more polished. The style sheet was about 6,000 lines long and it had a GNU public license in the header. The GPL's a red flag, because if you plan on maintaining intellectual property rights to the software, you may not use GPL licensed material in your code. Doing so, brings the entire project under GPL terms which puts software in public domain. Quoting from a text at the bottom of this webpage, it's from gnu.org, developers who write software can release it under terms of the GNU public license. When they do, it will be free software, and stay free software no matter who changes or distributes the program. We call this copyleft. The software is copyrighted, but instead of using those rights to restrict users like proprietary software does, we use them to ensure that every user has freedom. Now, no code of ethics covers situations like this. There's no clear violation of the law, but what we were about to do was in my experience a very bad idea for the project. I raised the issue verbally and was ignored, what to do? I decided to write an email to my supervisor, and carefully outline the issues and the consequences as I foresaw them. The reason I did this was that by sending an email, whether or not it was answered. And in this case it wasn't, the fact that I sent it, would be the substance of the email that would be recorded in the organization's email servers. In short, there would be a record of my objection. Having done that, I simply pursued the project as if nothing happened. I went along with the use of the style sheet and nothing was said about it for a couple of years. I received a phone call one day from someone peripherally involved in the project at a high administrative level. And he wanted to know about the intellectual property rights to the software. Apparently, the corporate councils were arguing about it. I said to the shock of the caller, that I didn't think we had any intellectual property rights to the software at all. And I forwarded to him the email I'd sent to my supervisor years before. There were a few words of disgust said by the other person, but my conscience was clear. I raised the objection, I made it official by putting it in an email. And if my supervisor didn't do anything about it, okay, that didn't really concern me any more. And as it was the supervisor was moved to another position and nothing was ever said about the matter again, no IP rights. The ethical decision here was, how do I proceed? I could have mad a bigger deal out of the matter by paying personal visits to the people in the organization's hierarchy. I could have made life difficult by removing the style sheet from the project and breaking the software that used it. But none of these actions were likely to accomplish the goal. So I needed to simply clear my slate of liability for the situation. I needed to do it in an adultlike manner and hence, the email. Now this tactic has worked actually very well on other occasions. I was once aware of a clear contract violation on a project. In effect, we were conspiring not to pay suppliers for their services. I spoke to an attorney friend of mine about the legal specifics that covered the case. And I wrote one of those emails to the person in charge of the project finances. I outlined, what was being talked about, and how if we didn't pay the vendors, we would be opening ourselves up for legal action. The email actually had its desired effect in a few days. Corporate counsel got involved, realized that we had deliberately, but mostly through ignorance and passiveness, put ourselves in a risky position. The vendor was paid and the problem never occurred again. Now ethics is a big field. Philosophers since Plato, and you can argue from way before Plato, have considered the matter of what's right to do in a situation. Various ethical theories have been devised largely falling into four categories. Virtue ethics, social contract ethics, consequentialism or utilitarianism, and deontology. You're free to study the details of these. But what they are are different ways to look at a situation, different ways to evaluate what to do? It's these different ways of evaluating a situation that I've used to help me make decisions about what to do when there are no company rules that apply. Again, the point here is that as a designer you're going to be exposed and responsible for creating low level detail about a project. Occasionally, and hopefully it doesn't happen too often, you may find yourself in a situation as I have. Where something tells you this just isn't right and you have to figure out what to do about it. Good luck with that. [LAUGH] Next time we'll talk about more complicated subtle project ethics issues. Thanks again for your time.
