Let’s Care About the Ethics of Software Development

How many times do we ask ourselves, “what could I have done differently”? Even though I’m aware of the futility of mourning past decisions, looking back with a more investigative attitude can yield some wisdom. I decided to look back through the lens of ethics because I’m particularly concerned with what are the responsibilities of a software developer and how to recognize what is the right thing to do in certain occasions. Without trying to sound self-condescending, I should emphasize that ethics is a complex body of knowledge and I’m not trying to establish the moral grounds of my profession.

I was inspired to explore this topic while reading Clean Architecture by Robert C. Martin. He talks about how software provides two values: The behavior that satisfies the functional requirements of the business stakeholders and the architecture which promotes a structure that allows software to adapt easily to changes. Most software development teams struggle to find a balance between these two values because the former represents concrete aspects of the business while the latter is more difficult to measure and even understand. Uncle bob encourages developers to fulfill the responsibility of “fighting for the architecture”:

Effective software development teams tackle that struggle head on. They unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That’s part of your role, and part of your duty. And it’s a big part of why you were hired.

Martin, Robert C.. Clean Architecture: A Craftsman’s Guide to Software Structure and Design (Robert C. Martin Series) (p. 18). Pearson Education.

I have faced this struggle many times in my professional life. Long and difficult discussions trying to convey why the company has to invest in improving some aspects of the system’s architecture. What I usually haven’t had is the conviction that a moral obligation offers to one’s standpoint. That’s the reason I think every development team should define their core values and use them as guideline to determine what is right a wrong.

It’s also important to remember that these are guidelines, not rules written in stone. What you are looking for at the end of these discussions is a balance between software’s two core values. The opposite case where we as developers do not remember that at the end of the day we are trying to deliver a product that satisfies a real world need is also a common case. The best way to determine if a position is worth defending is by answering questions that provides strong foundations to our case: How many features have the team delivered in comparison to N months ago and the number of developers in the team? How long it takes to make changes on existing features? Try to sustain these answers with data.

We explored a very important area where having a strong set of values can help us but as engineers we have to make many other decisions every day: Should we always write a regression test before writing a bug fix? What are we agreeing to when we approve a teammate’s pull request? How the right language to express our concerns about a design decision? All of these questions should be answered with a consistent judgment that emphasizes values like honesty, integrity, and respect.

Sometimes I wish these topics were more popular in our community much like neural networks, serverless architectures, or single page application frameworks. The experience I’ve had over the course of my career is that many companies work without answering much of these questions even when they have a bigger impact than the technology stack used in their products.