Developer ethics — why you should care
As a software developer, on a daily basis, it doesn’t often feel like I am faced with moral dilemmas. Usually, I’m trying to figure out how something should be implemented, or how to fix some bug. However, moral dilemmas can happen even though we might not be fully aware of them. Consider these situations:
- You are asked to create a tool which captures customer email addresses, and then uses the API of a popular career-oriented social network to find and store demographic data about each customer, in order to send targeted marketing campaigns.
- You are moving a big new feature from BETA testing to fully rollout. After the feature was deployed in BETA, the decision was made to only give it to your premium users. Because of the tight deadline, there is not time to make an exception for all the BETA testers, so they will lose access to it.
- Somebody asks you to implement a new pricing model that charges users visiting the .com version of your site 30% more than users visiting the .co.uk version. This will help your company achieve its revenue targets.
Would you feel comfortable being the engineer behind these product specs? Would you be happy if you were the customer of this product?
It’s easy to look at a product decision and think “that was the responsibility of design/UX/product team”, and it’s true that the person coming up with the ideas might not be a developer, but as engineers we are responsible for the implementation, at least. Being asked to do something at work does not remove your responsibility to consider whether it is a wise idea.
This is at odds with the opinions of many developers, according to the most recent StackOverFlow survey. Although nearly 80% of developers thought they did need to consider the ethical implications of their code, 58% thought that upper management was ultimately responsible for the software. The thing is, from a legal perspective, these developers might be wrong.
At university I studied a module on UK criminal law, and there was one particular thing that stuck in my mind: If somebody puts a gun to your head, hands you another gun and tells you to shoot a third person, if you comply you are guilty of murder. You cannot use the excuse that you were saving your own life as a justification for taking the life of somebody else.
Courts are applying the same principle to unethical software engineering. In the US, for implementing the software which allowed cars to recognise when they were being tested for fuel efficiency and display false readings, a Volkswagen engineer received a three year prison sentence and a $200,000 fine, despite not being the “mastermind” behind the plan. So, even if you have no interest in doing the right thing for your customers (although I hope you do), you should at least question unethical practices for yourself, because if you built something, as the developer you can be held responsible, no matter what happens to upper management or a product owner. While the problems we work on might not usually pose questions of criminality, the principle is the same.
At this point, it’s easy to say “you need to behave responsibly”, but what does that mean in practice? There are several things you can do.
Protest effectively
The details of Stanley Milgram’s experiments in the 1960s have been widely reported. He discovered that the majority of subjects would obey somebody to the point of causing somebody else serious harm, if they are ordered to by somebody in a position of authority. However, more recent research discovered that under these circumstances, most people will offer some degree of protest. Those who ended up stopping the experiment were simply more effective at protesting, a skill that anybody can improve.
I take from this that, when faced with an unethical situation, we must go above and beyond expressing mere discomfort. It’s important to articulate the reasons the situation is unethical and use that to backup your refusal, both in order to bolster your own resolution, and to persuade whoever is asking you to do something you don’t believe in or consider an ethical risk.
Educate yourself
It’s much easier to protest about unethical situations with some idea of what unethical means to you. Unlike in the medical and legal professions, there is no universal code of ethics for Software Engineers, but there have been several attempts to come up with one. A good one is from the IEEE Computer Society. The full version is here, but the short version is:
Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:
1. PUBLIC — Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER — Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.
3. PRODUCT — Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.
4. JUDGMENT — Software engineers shall maintain integrity and independence in their professional judgment.
5. MANAGEMENT — Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.
6. PROFESSION — Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.
7. COLLEAGUES — Software engineers shall be fair to and supportive of their colleagues.
8. SELF — Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.
Educate your organisation
Finally, it’s much easier to have conversations like “is this in the best interests of our users and the organisation’s reputation?” if the organisation you work in is already considering the ethical implications of the software it builds. DotEveryone has an interesting article on the three Cs they believe organisations should be considering while when developing new technologies:
Context — looking beyond the individual user and taking into account the technology’s potential impact and consequences on society
Contribution — sharing how value is created in a transparent and understandable way
Continuity — ensuring best practice in technology that accounts for real human lives
Considering the 3Cs is a good way to think ethically about the products we build, and make sure they are helping our users in a transparent and ethical way.
The ethics of developing products are not something to be left to the people making product decisions. If you write code you are responsible for it, and the sooner you educate yourself and your company on the subject, the easier it will be to make ethically responsible decisions.
This blog post was heavily inspired by the talks at the superb Coed:Ethics conference I attended a few weeks ago. I thoroughly recommend adding it to your calendar for next year.
Thank you for reading! We are glad to share our experience and help everybody out there to code better.
Do you use Typeform’s Developer Platform? Would you like it to be featured on our Developer Portal? Please share with us!
And yes… we are hiring!
