We are 3000 Years Behind: Let’s Talk About Engineering Ethics

From “An Eye for an Eye” to Gatekeeping

If a builder builds a house for someone, and does not construct it properly, and the house which he built falls in and kills its owner, then that builder shall be put to death. This is a law from the Code of Hammurabi, written almost 4,000 years ago. If it kills the son of the owner, the son of that builder shall be put to death.

This code is the earliest known instance of construction laws and it can be thought of as basically a grisly series of if/then statements. It reflects the structure of society at the time–meeting out different punishments for offenses perpetrated against the offender’s equals than their inferiors. Taking the lives of people connected to the offender! It is in many many ways shocking and harsh and it really shows it’s age.

My name is Hayley Denbraver and I am a web developer and an aspiring developer advocate. In an earlier chapter in my life, I worked as a structural design engineer and got my professional engineering license in Civil Engineering from the state of California. I even have a stamp with my name on it, very official.

I can say, with absolutely no caveats, that I am glad that modern construction law doesn’t look like the code of Hammurabi.

But I think the code of Hammurabi has something interesting and relevant to say, even today. The law is brutal, but there is an undeniable sense of accountability. And this is where, in my previous field, the idea of engineering ethics started. In violence and absolutism. And more than 3,000 years ago.

Fortunately my former discipline didn’t stay there. The germ of responsibility and accountability had begun, but do you want to know how it sprouted and flourished? Disasters mostly.

All were horrifying, but many make for interesting reading–for instance, did you know that in Boston in 1919 an enormous tank filled with molasses failed, flooded the town, and left everything sticky for months? It also killed 21 people. Today on the site of the engineering failure, there is a plaque that reads: On January 15, 1919, a molasses tank at 529 Commercial Street exploded under pressure, killing 21 people. A 40-foot wave of molasses buckled the elevated railroad tracks, crushed buildings and inundated the neighborhood. Structural defects in the tank combined with unseasonably warm temperatures contributed to the disaster.

This disaster and the resulting class action lawsuit lead to the first licensure laws in the United States.

So construction law and engineering responsibility moved from an ‘eye for an eye’ philosophy to one of gatekeeping. And the gate you must pass through is licensure.

Let’s Talk Licensure

So what is licensure and why does it matter? Professional licensure protects the public by enforcing standards that restrict practice to individuals who have met specific qualifications in education, work experience, and exams.

We are going to talk a bit about licensure, not because it is the same as ethics, but because it is a system of formalized responsibility. And taking responsibility for your work and how it impacts others is a pretty good place to start, whether this responsibility is formalized or not.

In order to get licensed, I completed my undergraduate studies in Civil Engineering from an accredited university. Additionally, my masters degree in Structural Engineering counted a year towards my work requirement. After that I worked for a year and a half to finish my work requirement. I then needed a few licensed engineers to vouch for me. Finally, I had to pay more than a grand to sit for a three part, multi day test that many people need to take multiple times to pass.

Now, just because I worked for a bit , took some exams, and jumped through some hoops doesn’t mean that I am a good person. But that isn’t really the point of licensure. The point is that as a licensed civil engineer, I had a stake in the outcome of my work (malpractice can result in losing my license or in prosecution depending on the breach), I was accountable to the general public, and I could be censured by my professional community if I operated outside the bounds of ethical practice. Licensure also ensured that I understood the basics of ethical practice, because I was tested on it, and because my accredited degree required an ethics course.

So what about Software Engineering?

So how does all of this compare to my experience writing code and having the title “Software Engineer”.

Well, to start, the title “Software Engineer” doesn’t mean much. Anyone can call themselves a Software Engineer with abandon. When I was nearing the end of my coding bootcamp, we were issued business cards that had our name, contact info, and the title “Software Engineer” on them. Obviously, these served a practical purpose for us while we were job searching and additionally, our instructors wanted to instill confidence in us. However, in no way could you do something like that with the title “Civil Engineer”, which is a title protected by law. You can’t just print “Civil Engineer” on a business card and set up shop any more than I could apply the title MD to myself and start treating patients. The title “Software Engineer” might mean something within the corporate structure or for your career growth, but it doesn’t imply anything official about your education, work experience, or responsibility towards the public.

Secondly, on my development team, we are pretty well split between people who are self taught, bootcamp grads, internally trained developers, and people with a computer science degrees. This sort of breakdown would make zero sense in a civil engineering office. I realize not every workplace is going to have a group of developers this diverse, but many many offices have developers that fall into a category other than “got a BS in Computer Science”.

Third, my work is evaluated by my peers and possibly my team lead before it is deployed, but it isn’t reviewed by any exterior party. It isn’t available to the people who use our service. It isn’t retained anywhere public. This is a very different process compared to structural plan review, where the city, county, or a governing department is involved . Version control and pushing code to github is far from the stamped structural plans of my previous career.

So you might be thinking, “Okay, so your new career is different than your old one. Why should it be the same? It is a different field, after all” and that is a fair point. And within it, there is a kernel of truth. Not every software developer is going to be writing code that has the capacity to negatively impact the public if they act unethically or if they lack a certain level of skill or knowledge. It is hard to argue that all software developers fall into this category, given recent data breaches and the examples we see in the news of people using a platform inappropriately.

I want to talk about one final difference between software development and civil engineering. It is a difference of culture. Software is open in a way that civil engineering cannot be under the current system. Knowledge is shared much more freely, there are many more accessible opportunities for learning, and there is more varied work for a varied population of developers. And this is really exciting! I don’t want this to end, and for more reasons than that I came from a non-cs degree background.

So What is Next?

My personal opinion is that one way or another, our industry will eventually see the adoption of an ethical framework. I believe that the discrepancies between how these fields are practiced will shrink.

The question is whether this will come from within the industry, or whether it will come from external pressures and sources. Will it be something we adopt or something that is imposed on us? Can we do it for the right reasons, or will it be a reactionary response to a disaster? Can we create something that both protects what is good in the industry, but provides increased accountability to the public?

I don’t really have answers to these questions. 100% overhauling how we approach our work is too big for a minimum viable project, in my opinion. So I want to propose a few ideas that we can start with, and then iterate from there.

First, we need to promote ethical literacy in the same way that we promote technical literacy. We are expected to keep up with our technologies and tools. It is not too much to ask that professionals have a basic grounding in ethical conduct.

Second, we need to take review, both internal and external, more seriously. Think about your team and how they release code. My current team has some very basic guidelines in place. Although you can’t release your own code and code can’t be merged if tests aren’t passing, there is some rubber stamping that goes on. I think we can do better. If a project has the potential to impact the health and safety of the public, I believe that it is reasonable to have some external code review. That way, other fresh eyes are looking at the problem and may spot issues to which you are blind.

Third, we need to improve communications between stakeholders and the team. One of the things that I miss about my old career is that on issues of safety I had veto power. Architect, client, or contractor wants something that is unsafe? DENIED. In most civil engineering firms there are fewer layers between the engineer and the client. In software you may have to communicate that something is a bad idea to your product manager, and damn it you are ruining the roadmap, and whoops sales already has contracts out, and now we are behind. Bringing increased ethical awareness into our work requires buy in from more than just you, an individual developer.

So those are some of my suggestions for good first steps. But remember, it is not enough to say, “Oh yes, good idea, I will talk to my team and get it squared away.” Companies need to put time and resources behind engineering ethics efforts and take work that devs and others do on this as valuable, not just “nice to haves”.

Acts of God and Sticky Shoes

To close, I want to return to the story of the Boston Molasses Flood. To recap: tank failed, area flooded with molasses, 21 people died, massive lawsuit, the catalyst for licensure in the united states.

A similar event had occurred in 1814, around 100 years prior, in London. There was a similar structural failure and nearly 1.5 million liters of beer were spilled. It killed eight people, including five people who had been gathered for a wake. It also had resulted in a trial, although the engineers weren’t held accountable because the disaster was ruled ‘an act of God’.

I ask you, why do you think that the tech industry has so far largely avoided things like licensure and accountability for the impact of their work? I think the answer is that failures are seen as an “act of God”. We wouldn’t phrase it that way today, but the thinking is similar. For much of the public, computers are somewhat magical and when the people don’t have even an abstracted level of understanding of how something works, it is hard to demand accountability.

The Molasses flood a hundred years later played out differently and I think that is for two reasons. First is that we had progressed 100 years in science, education, etc. That is great! The second reason is a little more sticky.

Bear with me here. Imagine you are a citizen of Boston in 1919. Even if you didn’t know anyone injured or killed, a few weeks later you are walking down the street and your shoes make a squelching sound because of the molasses residue that is EVERYWHERE. You don’t sit down on the train because you don’t want to ruin your clothes. The seats are sticky too. You have wandered into the Molasses swamp from Candy Land and there is no escape. The public couldn’t forget. They were forced to engage with it repeatedly. Every sticky step, you can’t forget. Change is mandatory.

That is what I want you to take from this post. When you go to your workplace tomorrow, imagine you are walking down the hall and your shoes are squelching. You sit down to your keyboard and it is sticky. Could you forget that or would it stick with you? Write your code, but remember that you are working for people, and that they deserve your care. May your responsibility towards them stick to you like tree sap, super glue, or molasses.



Code of Hammurabi

Boston Molasses Flood

London Beer Flood

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: