, , , , , , , , , , , , , , , , , , ,

In SW development you don’t see a lot of discussion about ethics. It is more common to talk about ethics at hospitals and social sectory. But contrary to dominant thinking, I believe ethics affect a lot of what we see happening in industry also. Ethics is integral part of human identity and because of this it affects the patterns we see at any work place, including SW development companies.

Bug assessment process as an example

Let me show an example. In my work with SW teams I have seen following pattern emerging over and over again:

During many months of concepting and early development of a product, SW designers are told that SW quality is of utmost importance. Without quality SW it is not possible to compete within the high-end industry. Furthermore, the SW quality will affect the schedule too – low quality SW will have lots of bugs and that leads to waterfall development cycle. This way of talking dominates the discussions in the early phases of development.

When the deadline is coming closer the conversation changes. The emphasis is put more and more on the speed of delivering features – after all, it is better to get the product out even with mediocre quality than not at all. Without a product there’s nothing to compete with. At this phase a special task force, whose purpose is to reject and ignore bugs (and features), is established. When this happens there are usually conflicts arising between the SW development teams and the bug assessment task force / management. SW developers feel that they don’t have enough authority to affect the decisions. They feel that also very important bugs are ignored.

At this phase managers start to talk about “changing mindsets”. Developers need to understand that it is the business goals that they need to optimize for, even if that would mean some compromises in the SW quality.

In my experience this isn’t so simple. To understand why, I think these “mindsets” needs to be studied more in depth.

Professional Ethics

For any rational human being it is quite easy to understand that even mediocre quality product is better than no product at all. If your work is simply to code features from a backlog, why would you argue if somebody removes bugs from that backlog? After all, it is work off from your backlog. It should make your life easier, not harder.

However, if we think this way, we assume people to be “rational machines”. They are part of a bigger system which creates products, and it is their job to do their own part – and that’s it. The managers and the bug assessment teams are doing theirs. If everybody just functions as they are supposed to, the system works efficiently.

This is a false view. People are not machines and organizations are not systems.

This is a false view. People are not machines and organizations are not systems. It is all just people – cooperating, competing, communicating, living their lives in local interactions. And in these interactions their identities are built. They are taking the perspective of others’ in order to understand what is expected from themselves. They imagine how the others will respond if they do this or if they do that.

In this process they are building what G.H.Mead called the “cult values“. Those cult values are idealized values according which the people expect themselves and the others to function. People identify with those values as respected individuals of a certain professional group. Whenever they are forced to go against those values, it brings up lots of anxiety. And this is where the conflict arises. People hold themselves and others to be accountable of functioning according those values they have created together.

Revisiting the bug assessment process

During their professional career, SW developers are reminded over and over again how important it is to create quality SW. Their peers and bosses are evaluating their work and their competences according their abilities to do that. They are creating together the cult value of “Quality SW”. They read books and blog posts about the importance of “building quality in”. They might have things like continuous integration systems where people put peer pressure against each others to not commit code that causes bugs. They attend seminars and trainings where the SW quality is talked about. Their whole identity as professional SW developer is tide to the concept of quality SW. It is one of the core values, the ethics of their profession.

Then the reality kicks in. It isn’t always possible to produce bug-free SW. Sometimes the bugs can’t be seen before the larger system is integrated. Sometimes there is too much pressure to reach a deadline to test everything properly. Sometimes the whole SW is just too complex to fully understand and human errors sneak in. This is what G.H.Mead called the “functional values“. Functional values are the reality of what people have to do. Functional values are often conflicting with the cult values and that conflict can’t be solved.

Now, it is easy to see the patterns where cult values such as “Quality SW” are built in the daily life of organizations. Everybody wants to see quality SW – the managers and the developers alike. It is inevitable that SW development professionals build their professional identities on such concepts. They become part of their professional ethics.

However, the actual development of SW, the coding, isn’t part of everybody’s job descriptions in the organizations. Most managers don’t code themselves. Their job is to take care of things like schedules, metrics and milestones. Their identity hasn’t been built around concepts such as “Quality SW”. Their identities are built around things like “leadership”, “accountability” and “roadmaps”. Likewise, developers don’t usually understand the dynamics and challenges of planning a large SW product. So it is not a surprise that these two job roles in the organization are not understanding each other very well.

The managers might be angry to hear that developers are fighting against the decisions made in the special task force. For them this fight is jeopardising the schedule and the success of the company. For the developers, many of these decisions feel unfair and plain stupid. And not just that, they are against their professional ethics. Against “who” they are. The managers might not even realize that when they are making these decisions they are calling into question “the game“, the very core values of SW developers. Pierre Bourdieu showed that when people do that it can have very serious consequences. Depending on the context, calling the game into question might lead one to getting fired, being expelled or even killed. In SW organizations it usually means that employees start using “the arts of resistance” to rebel against the managers. This might have serious effects on the patterns of cooperation in the organization.


So, as a conclusion, I want to draw attention on how the professional ethics affect the patterns of cooperation in organizations. By understanding these patterns it becomes possible for people to cooperate more skillfully. The developer might better understand why he feels the way he does. The manager might better understand how to discuss these matters in a way that it doesn’t “call the game into question”.

The ethics will always be part of our profession, no matter if we work as a nurse, as a SW developer or as a manager. The ethics will always affect our work and possibilities for cooperation. It is a matter that should not be taken lightly. Instead of just looking at the roles and responsibilities, it would be wise to think about the professional ethics of a given job also: What are the “cult values” and “functional values” of a job? What kind of paradoxes there will be that can’t be fully resolved?

(e.g. How can a people manager take care of the welfare of subordinates and at the same time put people to work more and more overtime? How can a quality manager challenge the status quo and still enable milestone achievements? How can a developer double the speed of coding and still ensure the Quality SW?)