code data development programming security

Enforcing ethics

I was reading IOT: Code of Ethics for Software Developers and Engineers – Secret Microsoft Communications – Site Home – MSDN Blogs today and it got me thinking about the Botnet of Things, but more importantly, about ethics in Professional Development, as covered in the DunDDD open discussions.

The MSDN blog covers an ethical scenario well, so I don’t want to go over that again, but it got me thinking about something that I’ve been asked to do a few times, that takes the idea one step further.

I’ve been involved in a number of projects that handle sensitive data, particularly data on children, data on prisoners and sensitive financial data, so data protection is key to much of what I have built. In order to illustrate some of the additional ethical considerations when dealing with data, I’m going to discuss a scenario that doesn’t relate to a specific client, but covers many of the decisions that I have had to deal with, and I hope is a scenario familiar to many of you.

The ethical workflow

Consider a accountancy firm, with many clients. As a result of this, time tracking is very important to their business, so that they can bill clients appropriately. The scenario I want to present considers the timesheet software in use. At a basic level, there is a client code, a number of hours per day booked to that client, and an approval system so that the hours are checked following submission, before any invoices are sent out.

In addition, the timesheet software records overtime, and each users’ financial details, so that it can correctly pay each employer each month.

The software solution

The data entry portion validates that as a user, I only have access to a subset of the client codes, that I can only book my contracted hours to standard codes. The workflow ensures that a manager, as someone authorised to check work for a given client code, can authorise my time. The workflow also ensures that invoices cannot be generated until the time has been authorised.

This workflow is similar to many in systems I have designed. There is a validated data entry, which prevents the workflow from starting if the data entered is obviously incorrect, and a workflow that ensures the data is checked before it is used in a process with financial impact.

Ethical trapdoors

To truly be an ethical developer, you need to consider both the implicit and the explicit ethical considerations within the requirements, and the behaviour of the less ethical users, who may attempt to subvert the ethical process either due to malice, or laziness, or a myriad of other reasons.

Manager, authorise thyself?

Hopefully, the first potential ethical problem with this workflow is obvious to you : I have yet to mention any restriction who can authorise a timesheet. Should the user entering the timesheet also be a user authorised to access the client codes on the timesheet, they will be authorising themselves, offering no additional protection.

It might be the case that the user has been given authorisation because they have proven that they maintain high ethical standards, and would therefore be less likely to cook the books. If you believe in people over process, this might lead you to think this way. If, however, time pressures on individuals are such that the authorisation time is limited, there may be scenarios where a user would limit their diligence, increasing the change of deviation between the recorded and actual figures. There may also be unethical figures who are able to provide the facade of ethical competence in order to get the authorisation required.

Data leaks

Certain clients will be sensitive, either by means of celebrity, or association with staff, such as ex-husbands. Whilst their records will be recorded with sensitive data, satellite systems, such as invoicing and time tracking, may not be aware of their sensitivity. So, to ensure anonymity and enforce ethics via obscurity, the client codes should never leak information, either directly or indirectly (i.e. direct the user to an external resource that might contain sensitive information that can be exploited), and should only be visible to users with a valid reason to see them.

Software supports the business

Ultimately, the software exists because the business needs it. So the ethical decisions sit within those guidelines. The software can’t do everything, so the external processes have to be considered, and questioned where they allow ethical breaches that the software cannot counter. We have a duty to recognise the limits of where our software can enforce ethical behaviour and document these limits so that our customers can adapt or strengthen their processes appropriately. We also have a duty to challenge requirements and requests that violate or ethics, or the ethics our clients declare they follow.

2 replies on “Enforcing ethics”

[…] It’s frustrating watching customers who adjust their process to work around the software rather than fixing the software, and freeing staff up for all the nice to have things they moan about. If they’re working around your software, it’s likely they don’t know what it does, and it’s magic, or they know what it does and they don’t like it (which makes it tricky to enforce ethics by software alone). […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.