draft for Voluntary Code of Ethics for Programmers [Volcep]

Medical Practitioners self-regulate by means of a Medical Council. Standards exists in almost every aspect of society to ensure a minimum standard of quality. There is no such thing for programmers. What happens when you click on the "Forgot my password" link on a website and they send you your password by e-mail, your actual password? You then realize that they do not hash passwords and this should basically be considered malpractice. It should be but is there really anything you can do other than not using the website? Is there even a consensus as to what is considered malpractice? There is not and this is a very controversial topic. There are colleges and universities but in my opinion academia does more harm than good. The reasons why is a whole topic in and of itself.

This document is very much a work in progress and I welcome comments, suggestions and the like.
Twitter @Gregg_Ink, use #volcep
Reddit: /u/gregg_ink

This document is a draft for a code of ethics which ought to be followed by every programmer especially professionals. Trade-offs are a big consideration in the development of software. Therefor it is not easy to come up with rules which are to apply accross the board without being vague. Nonetheless, the rules below should be adhered to as much as circumstances allow.

This code of conduct has been designed such that is does not apply to any programming language or programming paradigm in particular. This is so as to reduce controversy in a topic I expect will already be very controversial.

This code of ethics only addresses things which concern programmers specifically and not ethics and morality in general. This is again so as to reduce controversy. Sure, you should not kill each other but I did not see the need to include this here.

The code

• In general, simple solutions shall be favoured over complicated ones.
  In general, solutions with the least number of failure points shall be favoured.
• Dependencies shall be used sparingly and not allowed to accumulate beyond reason. The more dependencies, the more bloat, the higher the chance of a vulnerability or exploit.
• In general, text shall be processed internally while encoded as UTF8. In general, text output shall be encoded as UTF8. Legacy code might require a different approach.
• I understand that the field of computing is too large for any one person to know all of it. I shall be honest about what I know and don't know.
• I shall respect the code style of the codebase I contribute to. I shall be consistent in the code style of my own code.
• I shall only use 7-bit ascii to name files and folders. Spaces will not be used either, underscores are okay. This is so as to reduce compatibility issues.
• Names of variables/functions and the like shall be given sensible and self-explanatory names whenever possible. Conventional names shall be used where applicable. No confusing or misleading names shall be used. For example: function names containing the word "push" are used to place something onto a stack-like datastructures. A corresponding function containing the word "pop" is used to take it off. Do not use "push" and "pop" to mean something else. Do not use other words where "push" and "pop" is meant.
• The input to any function / application shall undergo sanity checks when applicable. The length of input into an application shall always be checked so as to prevent buffer overflows. In the event an SQL database is involved, input shall always be parsed so as to protect against SQL injection.
  No assumptions about the input of a function shall be made without good cause. Edge cases, exceptions and malformed input always has to be considered.
• In general, platform independent technologies shall be favoured over platform dependent technologies.
• The word "computer science" shall not be used as such a thing does not exist. "Computing", "Information technology" and "computer technology" are acceptable words. Science is a human effort to propose hypotheses which are disprovable. The practical application of knowledge thus acquired is called: "technology". No false impression shall be given that computer technology is a science. The use of the word science can give a false sense of credibility to ideas which have insufficient evidence to back them up and which cannot be disproven.
• Passwords shall never be stored in plain text but stored as salted hash using a proper cryptographic hash or more recent technology as recommended by security experts.
• Userids and similar data shall not be given straightforward numbers which increment with each new instance. Black hat hackers should not be able to guess userids or similar data. This can easily be achieved by concatenating a counter and salt and then hashing it. Then concatenate the hash with the counter again to absolutely assure the uniqueness of the id.
• No system shall ever be designed which requires the sharing of passwords.
• Code shall always be tested to whatever extend is most reasonable. Preferably another person or third party shall do additional tests as programmers may have blind spots concerning their own code.
• Terms of licenses, whether open or proprietary, shall be respected. This includes but is not limited to giving credit where required or not including GPL code into proprietary code.
• Time pressure and constraints are a real thing imposed by either circumstances or management. This sometimes requires quick fixes which cause technical debt. The accumulation of technical debt does degrade the quality of software over time. Within reason, I shall prevent and reduce technical debt within my codebase.
• It is not uncommon for a lot of knowledge about a system to only exist inside the mind of the staff in a company/organisation. This can cause real problems when people leave and new people replace them. Within reason, I shall document the systems I design.
• I shall always write the best quality software I can write within the circumstances. Software quality is to be judged according to 4 criteria
  1. Stability: the software keeps running without problems. It doesn't crash or bluescreen.
  2. Reliability: it does what it is supposed to without mistakes, the output is accurate.
  3. Security: the software cannot be used for nefarious purposes, for example: acquiring credit card number from fellow users on the system.
  4. Performance: it does everything it is supposed to within a timely fashion.
• I shall not criticize or interfere with a system without first understanding the reasons it was designed the way it was.
• I understand that humans are typically really bad at estimating how long it will take to write or re-write something. While solving a problem, unexpected issues frequently show up which further delay a project. I shall not claim to know how long it takes to write a specific application.
• I understand that programming is primarily about studying, understanding and designing systems to solve problems. Writing code is merely a means to an end and not the focus of what I do in the same way English literatue is not about the latin alphabet.
• I understand that the number of lines of code, while an easy metric to measure, is mostly useless and correlates very weakly if at all with the quality of the code, the complexity of the code, the time it takes to write the code or how long it takes for the code to run. I shall almost never mention the number of lines of code when discussing a codebase as this means very little anyway. I shall not approve of the use of the "number of lines of code written" as a metric for performance in a company/organization.

© 2019 Gregg Ink