A software development code of ethics

Workshopping ethicsWhat might a software development code of ethics look like? This was one of many, many questions that came out of John Nolan‘s excellent session at SPA 2013, asking us software practitioners to consider the moral and ethical dimensions of our work.

(To avoid doubt, in these discussions morality was defined as expectations determined by oneself, ethics as expectations determined by society.)

If you work in software you may well not think your work carries an ethical or moral dimension. I didn’t particularly. But John presented a number of scenarios where these questions were forced out. For example, what if you implemented a trading system which didn’t cap the volume of transactions? What about balancing speed of delivery against security? What if your project was funded with tax payers’ money, and its success was questionable? Would you do something about it? Or would you absolve yourself with the knowledge that you were simply implementing the requirements of “the business”? (That last defence has a name, by the way: it’s the Nuremberg Defence.)

As part of Tim Mackinnon, Seb Rose, Lucia Rapanotti and I spent some limited time trying to create a software development code of ethics. Naturally, we didn’t complete this in any sense of the word, but we did make a start.

Questions we asked ourselves included:

  • Would people trust our profession more if we had such a thing?
  • Could we reduce the chance of multimillion pound IT project failures?
  • …Or least ensure full accountability if they happened?
  • What behaviour changes would we expect if we had such a code?

We took principles (“rules”?) from some other codes of ethics and conduct, and we made some up. We found that the topic was so large we were in danger of succumbing to analysis paralysis, so we chose to just get some ideas down and worry about refinement later.

Our principles cover the range from software development to governance, so they aren’t all limited to those who necessarily consider themselves part of the industry. Here’s what we came up with, with a bit of commentary…

  • Responsibility should not be delegated. [So senior people cannot escape accountability for major failures.]
  • Ensure equal access to all. [Derived from a principle of medical care being open to all.]
  • Delivery value frequently, and continuously. [So you shouldn’t be able to spend anywhere near £100m without deriving some benefit.]
  • Have due regard for public health, privacy, security, the wellbeing of others and the environment. [From the BCS code of conduct.]
  • If it feels wrong, don’t do it. [A guide to help with morality.]
  • Accept that estimates are promises. [One for those work with software developers.]
  • Software should be shown to work within tolerances agreed by the customer, or should not be released. [Aimed to put a focus on testing.]
  • Changes should be traceable. [Version control.]
  • Keep code in a maintainable state. [Inspired by the Pirate Code: “…To keep their piece, pistols, and cutlass clean and fit for service.”]
  • Always read the End User Licence Agreement (for tools, services, etc). [Added mainly as a provocation; no-one really reads the EULA, do they?]
  • Failing to perform a good job in return for a benefit such as money or goods. [Derived from the ICC Cricket Code of Conduct.]
  • Ensure others can pick up your work when you leave. [Aiming for maintainability and continuity.]

You can pick holes in this list, sure. But right now it would be great to add more the bag of ideas, so we have a much richer selection from which to draw out the gold. What would you like to see there? We’re very keen to know, and to move this forward.