What should be included in a programmer's code of ethics?

Question

Recently there was an ethical question asked, but I'd like some input on what might be included in a comprehensive code of ethics. I'm thinking of something along the lines of the Hippocratic Oath that professional software developers would hold to.

We are in a relatively new profession, so there's likely to be debate about what should and should not be included in an ethical code. There are published ethical codes, such as ACM's and GNU's, but there are deep philosophical differences among programmers. Perhaps we can't find a definitive answer for how programmers should behave, but we can get some consensus on what most of us feel is right and wrong.

Please limit yourself to one point per answer so we can vote up or down. Ideally, the most important ethical considerations will rise to the top and less important clauses will stay at the bottom. I'd say it's fair game to "borrow" points from other published lists and get inspiration from the ethics tag. Please cite any sources. (Inspired by MagicKat's answer.)

Answer 1

If you use code from somewhere else, cite where you got it from.

Answer 2

Never commit code that intentionally breaks the build.

Answer 3

Don't make a program that you know will be used for evil(spam, hacking others sites, etc).

Answer 4

How about "Don't be evil".

Answer 5

Reading code is inaccessible to most people, so it definitely needs to include something about documentation agreeing with implementation.

Answer 6

Commitment to excellence.

(In other words avoid mediocrity and half assed solutions at all costs)

Answer 7

Don't leave broken windows

Answer 8

Stay legal - ie. do not break licensing stuff and sell a product as totally your own if some library you used requires mentioning.

Answer 9

When working with existing code, always leave the code cleaner than when you found it.

Answer 10

Do not lie to your customers/clients/boss

(In other words, avoid the it's 90% ready trap, and tell when there have been unexpected problems)

Answer 11

Don't give bad code out of your hands.

(People might read it and get wrong ideas)

Answer 12

Respect your User! Give them solutions that address their problems and work consistently.

Answer 13

Don't help to kill people.

Answer 14

Expect the unexpected

(In other words, design for robustness)

Answer 15

Consider the plight of future programmers (including yourself) when they come to your code. That clever hack you wrote won't look so clever years down the line when someone discovers it's buggy and impossible to understand.

Answer 16

Never ship anything you wouldn't use.

(I mean this from an interface/quality standpoint, not from a business use one of course. Thanks to Jon and Grant for pointing out the vagueness of the point.)

Answer 17

Share your knowledge

(I don't mean open your source, or speak at usergroups but rather don't try to make yourself unfire-able by never telling anyone anything and writing code that's hard to use)

The British Computer Society has both a code of conduct and a code of good practice. The fun thing about ethics is, of course, they're all relative.

Answer 18

On a technical front: Always worry more about the next time some human reads your code than when the machine reads it.

Making code a PC can read and execute is trivial, making code the next guy can pick up an run with in a reasonable amount of time is an art form that can take decades to master.

Answer 19

Know your user.

Answer 20

Don't be cryptic in coding. Either use a clear variable or function name to explain what is going on or comment to allow people after you (or even yourself) to figure out what you were doing when you were trying to be clever.

Answer 21

Care about the end users

(Do not deliver ugly, incomplete, unusable software)

Answer 22

This topic seems to be a little bit strange for me.
The ethical question you giving an example is clearly legal question and not ethical (don't steal can lead to theological discussion, but not ethical). And taking the code from employee is stealing (read your contract).
I can't think about single point in may daily work that i can consider as ethical (from professional point of view). May be only one "Do comment you code properly i.e no over commenting" :)

Response to the comment: The ethical can expend the legal and can not contradict. The question about taking code is clearly legal and if the law is gray in some point it's still legal. If legally you allowed to take code from work so what ethic question is here ? Just take it. I probably to cynical to this discussion.

Response to comment 2: You understand me very well and i don't care lose more points on this:). There is no ethic in our profession. There is good programmer and bad programmer (and the scale between). I can understand ethic for Doctors, Therapist etc ... In our case or you good programmer and you write good code or not. 90% of examples here define good practice in programming the rest is just naive.
Ok i think it's time to wrap it up. I'm done.

Answer 23

Solve the problems that matter. Let go of the ones that don't.

Answer 24

Write code you would want to use yourself.

Answer 25

Leave each file at least as neat as you found it.

Answer 26

Use what you have been building, as if you were just a user

Answer 27

Involve the user in the process. Ultimately, it's their tool your building.

Answer 28

Program as if the next developer that will maintain your code will be a crazed maniac with an affinity for sharp objects and knows where you live.

Answer 29

Under no circumstances shall an ethical programmer create of or assist the creation of DRM

Response to comment: That's not DRM that's security software for privacy protection.

Answer 30

Have time for people (colleagues) AND code.

Answer 31

Never use your code for personal job security.

Anything that tends to ensure that you are the only one who can maintain the code falls into this category: lack of comments, misleading comments, obfuscation, poor variable names, misleading function names, functions with multiple side effects, easily confused variable names (simple and simp1e), subtle coding tricks, secret back doors, etc.

Answer 32

Programmer ethics? How about this:

It should be noted that no ethically-trained software engineer would ever consent to write a DestroyBaghdad procedure. Basic professional ethics would require him to write a DestroyCity procedure, to which Baghdad could be given as a parameter. - Nathanial Borenstein

Answer 33

Code no harm

Answer 34

Always keep your code in some kind of version control system with comments!

Answer 35

Write code that is self-documenting (or self-describing).

Answer 36

I like the IEEE CSDP: Software Engineering Code of Ethics and Professional Practice.

Here are items that I found particularly important:

• 1.01. Accept full responsibility for their own work.
• 1.08. Be encouraged to volunteer professional skills to good causes and contribute to public education concerning the discipline.
• 2.01. Provide service in their areas of competence, being honest and forthright about any limitations of their experience and education.
• 3.04. Ensure that they are qualified for any project on which they work or propose to work by an appropriate combination of education and training, and experience.
• 3.09. Ensure realistic quantitative estimates of cost, scheduling, personnel, quality and outcomes on any project on which they work or propose to work and provide an uncertainty assessment of these estimates.
• 5.08. Not unjustly prevent someone from taking a position for which that person is suitably qualified.
• 7.02. Assist colleagues in professional development.
• 7.03. Credit fully the work of others and refrain from taking undue credit.

Answer 37

@Echo

Lots of tools that could be used for hacking and other malicious intents could also be used for good. Things like WireShark, Debuggers, and even password crackers can have both legitimate and malicious uses.

Answer 38

Here's the unifying theory:

Do unto others as you would have them do unto you.

(respect the original author's white space unless you are the new owner, don't release something you wouldn't use, leave the code at least as neat as you found it, don't break the build, and all the other applicably stuff already listed)

Answer 39

Write self-documenting code and use appropriate comments.

Answer 40

Always write your tests first, and never write new code that doesn't have a test already.

Answer 41

Don't ship a flawed project without a list of known bugs.

Answer 42

when committing to source control, always include a comment

Answer 43

Use a consistent style within a file.
Which should also match the coding standard for the project.

If you are not the original author that means adapting your style to match the rest of the code within the file. If all the code within the file has a consistent style it (should) be easier to understand and maintain.

Also note there are exceptions to every rule.
Do not follow the standards just because. If following the standard makes the code unreadable adjust accordingly and document the deviation.

Answer 44

When refactoring code don't leave the original code commented out beside the new code.

This is what version control is for.

Answer 45

Pay for the commercial software that you use.

It's only fair that other developers are rewarded for their work if you expect to be rewarded in turn.

Answer 46

For an example, look at the Australian Computer Society's Code of Ethics

Answer 47

Not so much of an ethics issue, but about arrogance: Don't assume your program is the only one running on the client machine. You don't have to optimize everything, but you should try to make the program efficient and stay away from running some background task that's drinking up 10% of the CPU.

Answer 48

to make this problem solvable, you would have to separate the ethics involved in programming from what the progamming is going to do. For example, there is programming involved in targetting a nuclear missile, as there is in a medical diagnosis application.

A programmer is a cog in very large group of people coming together to create a solution for a problem, whether it is how to make a bomber invisible to Radar or making a website work well for a client.

Professional ethics would have to start with being honest to your client during the entire process of developement.

Answer 49

The Software Engineering Code of Ethics and Professional Practice seems like a good place to start. It was developed jointly by the IEEE and ACM. As a software engineering major, I had to study the whole thing and write up my opinions on it; I won't bore you with that, but here is the preamble of the SECoE&PP:

PREAMBLE

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

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.

Answer 50

Don't hold your users' data hostage.

See DataPortability.org

Answer 51

Borrowing from Hippocrates ... First, do no harm.

That is very general, but ethical rules should be general. It has a lot of "sub-rules":

• do not write code intended to break machines or systems
• write what is requested and required and no more.
• abide by the license terms of code written by others

.. and so on.

Answer 52

Don't be too damn clever for your own good. Write code that is appropriate to the organization that you are working in, in terms of complexity and elegance.

There have been times when I've written bits that I thought were incredibly elegant, but that I soon realized were over the head of my peers (not trying to be arrogant, just realistic.) Although the code was well-commented, included unit-test, etc, I became apparent that the guys I was working with just weren't getting it. I ended up breaking it down, throwing away some of the speed and elegance, but getting something 10x more maintainable.

Answer 53

Never break a public interface.

Answer 54

Bill hours honestly.

Answer 55

We work within a technical industry, and whilst some of us like to believe that our work puts us in line with professionals like Doctors or Lawyers we have to admit that what we do is create software. We work to Business Aims and our goal is to complete a Project on time.

A Programmers Code of Ethics seems almost pompous to an outsider, so the only ethics I can really bring to the table are those that apply to other skilled jobs:

1. Work to the best interests of your employer.
2. Remain professional and diligent at all times.
3. Respect and understand your clients.

Past that, there's really not that much we can really say. Everything else should really be down to the employer.

Answer 56

Newton once very humbly wrote “If I have seen further it is by standing on the shoulders of giants”. This is very apt for developers as we rely on so many giants of our profession for almost everything we do; from the platforms on which we develop to the help we get from developers all over the world.

I can derive two codes of ethics for programmers from this:

• Always be humble (Edsger Dijkstra wrote an entire essay on this)
• Whenever possible, help your fellow developers and give something back to the community (let’s try to be the shoulders on which the next generation would stand)

Answer 57

Don't enter into a relationship with employers or clients who are engaged in unethical activities. You are responsible for who you work for. (See this question.)

Answer 58

Report security vulnerabilities to the person responsible for that system, library or application. Never exploit a security hole to "get their attention" or demonstrate the problem, unless formally and contractually authorized to do so by the responsible party.

---

Note: tread carefully because there may be legal complications.

Answer 59

Don't use use your technical knowledge to violate the privacy of others.

Answer 60

Do not underestimate the time it will take to complete a task.

Bad estimates are a fact in programming. We have a responsibility to give realistic (even pessimistic) estimates for the time it will take to complete a task. We have a responsibility to improve our accuracy in making estimates.

If you are unable to give an accurate estimate, do not give a guess. You must give a reason, citing the unknown factors in the task that prevent you from making an accurate estimate.

Answer 61

Treat the codebase like a campsite: always leave it in better condition than when you found it.

Answer 62

Remember that you make a living from people paying for software and reciprocate. Stop ignoring the nag messages in your shareware and shell out the piddly $20 bucks already!

Answer 63

I encourage my cohort of students to formulate THEIR OWN CODE OF ETHICS based on existing ones (i.e. ACM, IEEE, BCS etc.). Here's an example. Also I ask them to write their thoughts on current ethical issues in IT so there's documentation that they actually thought about these ethical issues (it's released under a by-nc-sa 3.0 Creative Commons license). Here's an example - you'd be surprised what students nowadays think about the contemporary ethical issues in IT that face them everyday.

Answer 64

Assume every line of your code is broken until you tested it. But don't assume it isn't broken after you tested it.

Answer 65

"It works on my machine" is not an excuse. Corollary: "Could not reproduce" is not a valid reason to close a defect. It's a reason to look harder.

(This obviously does not apply for software you write for yourself.)

Answer 66

Never fall victim to the "when you have a hammer, everything looks like a nail" issue when trying to architect a solution. There is too much technology available to assume only one option will work well.

Answer 67

When it comes to code, prefer readable over concise.

Answer 68

Credit your sources. Be proud to stand on the jolt cans of giants!