I’d like to start by first talking about software engineering itself, and whether it can legitimately be called engineering. The Oxford English Dictionary defines “engineering” as:
The branch of science and technology concerned with the development and modification of engines (in various senses), machines, structures, or other complicated systems and processes using specialized knowledge or skills, typically for public or commercial use; the profession of an engineer. Freq. with distinguishing word.
By this definition I believe it’s fair to describe the design and creation of software as “software engineering” and I’m going to proceed with the rest of this post on that basis.
Although we don’t design or build bridges or other physical products of traditional engineering, as software engineers we are still involved with solving complex problems by technological means. It’s easy to think of software as a kind of background entity with no serious consequences if it contains a stray bug here and there. Indeed, that’s basically true for the majority of software created every day.
There is obviously software out there which is critical to physical safety in one way or another, but I believe that ethical responsibility extends beyond that minority and in fact should have deeper roots in our day-to-day work.
Whereas traditional engineering associations formed over time have developed official codes of ethics (the American Institute of Electrical Engineers, as an example), software engineering is considered by many to be rather immature and perhaps too informal a discipline to be worthy even of the description of “engineering”, let alone formal declarations of standards. I can’t fault anyone for this, as it’s all too easy for anyone to sit down at a computer and produce something useful in one way or another by feeding the computer a list of instructions.
Things are rather different for professional software engineers. No matter what sort of software business you’re in, the reason you’re creating software is because someone is going to use it, either directly or indirectly. As the creator of a software system the end user is ultimately trusting you, not the software. Whether it’s trusting you with their life (e.g. if developing software for the medical field), their personal information, their money, or something else, as a software developer you have an ethical responsibility to take the most care possible when delivering a software solution.
This is about a lot more than just making sure your software “works”. There are other aspects to consider, including efficient use of customer resources (mostly money), and choosing the most appropriate technologies to create the solution.
Part of an engineer’s job is to make decisions that the customer is not qualified to make. We need to put aside our biases and personal preferences when choosing the means and mechanism of delivering the solution. That means maintaining up to date knowledge of new developments in technology and how they are being used in real scenarios. When a particular technology is selected for the task at hand it is our responsibility not only to ensure we have sufficient knowledge of the appropriate applications of that technology, but to ensure that we have the technical ability to apply it appropriately.
In software engineering, part of our job is to ensure that we don’t create new software solutions that already exist. In fact, we should first look for all the reasons we shouldn’t be writing new software. This applies at both the overall solution level as well as at the software library level. When customer resources are spent on reinventing the wheel an ethical line has been crossed.
There should also be massive emphasis on quality as a feature. Although this may seem difficult to quantify, I think we’ve all used software which we feel could have used a much larger degree of care during its creation. The foundations of quality span the entire software development life cycle and require strict discipline throughout. From ensuring that requirements are as well defined as possible, through peer reviewed architecture design, down to user experience refinement, emphasis on quality needs to permeate the engineer’s daily work philosophy. It cannot be merely an afterthought.
Some of what I’ve mentioned will undoubtedly be read by some as boring details that aren’t necessarily relevant. Unfortunately that is why we find ourselves less able to be taken seriously by the engineering community at large. The remarkably low barrier to entry in the software world is both a blessing and a curse, allowing imposters to maskerade as experts to the detriment of the party we should ultimately be most concerned with, and the very reason for our existence…
… the customer.