Whenever I interview a recent graduate, one of my favourite questions is always "what was your favourite module on your degree course?". This always elicits some interesting answers and a lot of discussion. Invariably, the answer isn't a module that focused on a particular language or technology, but more around the practices of software engineering as a whole or soft skills. If I'm ever asked my favourite by the interviewee (tip to potential candidates: it's always good to ask the interviewer questions!), my answer is always COM217 - Professional Issues in Software Development

Photo by Dom Fou on Unsplash

This was a fascinating module that covered a lot of interesting topics, like data protection, the computer misuse act, IP and liability. Over the years since graduating, this is the module that I've continually drawn on whilst working as a professional software engineer.

With this in mind, here are a few key points that I think any software engineer should always be conscious of:

Licensing

No one really ever reads End User Licence Agreements (EULA), but with a few exceptions every piece of software, whether Commercial Off the Shelf Software (COTS) or Open Source, has a licence of some sort. Understanding the licensing terms of the software you use is really important.

Photo by Markus Spiske on Unsplash

It's now become so easy to add a component or library to your code base to help with a particular task, via the likes of Node Package Manager (NPM) or Nuget. However, it's often not realised that you can inadvertently make the commercial code base you're working on open source, by not checking the licence and including code licenced under the GNU General Public Licence (GPL).

Open source aside, it goes without saying that using unlicensed, pirated/cracked or software under personal (non-commercial) licences for your commercial work is a massive no-no.

Intellectual Property

When we build software, someone always owns the Intellectual Property (IP) of it. At DCSL GuideSmiths, we're very clear that when we build a system the IP ultimately belongs to our customers. We don't build in any proprietary libraries that lock them into us, and this is important for our customers, as their system becomes their asset.

Photo by Umberto on Unsplash

It's not just about who owns the software though, whether you're writing a blog post and using some images to make a point, or even inserting some pictures into a web application that you're developing, you need to understand who owns the IP of that content. Nowadays it’s really quick and easy to find an image online that is exactly what you need, but if it belongs to someone else you may be at best asked to take it down, or face fines and other serious consequences. Taking this blog as an example, we've made use of some freely licensed images from Unsplash and have added credits to the creators of each.

Recent AI backed services can help, particularly with generating random realistic faces – for example This Person Does Not Exist

Data Protection

If you're working on any sort of system that handles personal information, then depending on where the data is physically located and/or your users are based, you're going to have to understand what data protection rules apply. When GDPR was introduced in Europe, it bought in a lot more protection than the existing Data Protection Act in the United Kingdom. Some might say it sparked a mini gold rush of consultants earning a lot to ensure that companies were compliant, as the fines for a breach of the regulations can be very significant.

Photo by AbsolutVision on Unsplash

If you're dealing with health-related data then there are many other rules and regulations that you'll need to be aware of and comply with, again varying based on jurisdiction. It's also not just how the system you're writing handles this data, but how you do when supporting the system. For example, if you host live production data in an Azure SQL database (with encryption at rest and other security measures), then taking a copy back to your dev machine to debug an issue can potentially be a breach of data regulations.

If in doubt, it’s best to check with your organisation’s appointed data protection officer (as most companies will have one of these), or if you’re working independently, you loop in an expert on data protection regulations to ensure you are covered.

Ethics

Imagine someone asked you to write some software to solve a classification problem. In this case dealing with identifying particular gene sequences in an individual's DNA. Clearly sounds like something that's going to benefit humanity by identifying disease, right?

Well, what if the client is actually the military, would you have questions about the end use?

That's obviously a very extreme example, but also think about being asked to build a system to "automate reviews into an online shopping platform". There may well be a very valid business need to do this, but it's also clearly something that could be very easily abused to promote someone's low quality products over the clear market leaders.

One area that’s had a lot of attention around ethics is Artificial Intelligence development. There are many potential concerns, not least: are existing human biases transferred to models that make decisions, what rights do AIs/robots have and how much control to make decisions is given. Another area of concern is what data is fed into the models that then make a decision, where does it come from and is consent given to its collection for these purposes?

Photo by Nathan Dumlao on Unsplash

Clearly ethics is a wide and at the same time personal field. Our own value systems evolve as we learn more about the world. Knowing where to start and what is right can be hard at times, but professional engineering bodies such as the IET, IEEE and BCS have well established codes of ethics for their members.

Be responsible

Google famously had the motto “Don't be evil”, which has probably been commented on enough for the last 20 or so years. Whilst they may not use it anymore, it is still a motto that all Software Engineers should take to heart.

Photo by Florida-Guidebook.com on Unsplash

Don't turn a blind eye to bad things, if you find an issue in a system report it responsibly. What do I mean by responsibly? Well, if you find a security vulnerability in a system, don't see how far down the rabbit hole you can go. Aside from the fact the system could be a honey pot, you put your reputation on the line as a trustworthy and responsible engineer.

Obviously if you're developing the system in question, then as a good software engineer you should be testing it thoroughly and fixing bugs as they’re found. It’s well proven that leaving issues to fester, compounds the problems resulting in many weeks or months of “refactoring” to fix what would have been simple issues if resolved immediately.

Copyright

For me, the most interesting example of copyright is the Nintendo vs Atari case (Atari Games Corp. v. Nintendo of America Inc.). This centered around the fact that Nintendo had copy protection hardware in all of its game cartridges and other software companies would have to pay a licence fee to release games on Nintendo's platform.

The key to this approach was the 10NES chip which had to be present to allow the cartridge to work in the console. Atari didn't like this, so tried to reverse engineer the data stream generation routines, but ultimately failed. They then obtained a copy of the source from the Copyright Office, under false pretences, by claiming it was related to litigations involving the 10NES chip. They then copied this to make their own version.

Photo by Markus Winkler on Unsplash

Aside from the fact that this was an unauthorised copy, they fell foul of the fact they copied it verbatim. Nintendo was able to argue that there were many different ways to generate the data stream that would unlock the NES, but their particular design had a number of additional features that were completely unnecessary to generate the data stream.

Whilst reverse engineering the routines to produce the correct output would be allowed, copying novel features that were unrelated (and importantly protected under Nintendo's copyright) set important precedents that whilst reverse engineering is fair use, verbatim copying of another copyrighted implementation is not.

Copyright is a complex field, and ultimately exists to prevent unauthorised copying or reuse of software code. Conversely free and open source licences, such as copyleft licences rely on copyright law to ensure that re-use is possible by abiding by certain terms.

Liability

Ultimately when we build software systems they are to solve a particular problem or to improve efficiency of the end-users’ operations. But if the software we write goes wrong, who is liable and what for?

Obviously, as software engineers we should always strive for the most robust and high-quality solutions possible. But what does failure mean?

Let's imagine a complex calculation routine that fails 0.01% of the time. Now, if this is in a piece of invoicing software, and the result of this occasional failure is a discrepancy of 10 pence, clearly that's something that can be fixed relatively easily and also worked around.

Photo by National Cancer Institute on Unsplash

Now, contrast that with a calculation routine for a system to administer targeted radiotherapy and that's out by 10 mm 0.01% of the time. Well now, that's potentially life changing for 1 in 10,000 patients – the Therac-25 accidents in the 1980s are used as examples on many software courses. As a software engineer you need to not only produce the best code you can, but also consider the consequences of what happens if your software fails for some reason. Defensive programming is a software design practice that engineers should be familiar with and make use of where the system is mission critical and has high safety and/or security needs.

Staying Ethical

This isn't a comprehensive list of "professional issues" for software engineers, but just a few areas I have experienced throughout my career as a software engineer and think are important.

As technology progresses and evolves, there will undoubtably be more regulations that are introduced for data protection and how to create software ethically...so I may well revisit this topic in the near future.

In the meantime, here’s a list of books/resources for ethical software engineering:

• The Essence of Professional Issues in Computing – Robert Ayres (ISBN: 0-13-908740-0)
• Professional Software Development – Steve McConnell (ISBN: 0-321-19367-9)
• Gray Hat Hacking: The Ethical Hacker’s Handbook – Various Authors (ISBN: 978-1-260-10841-5)