Software development through the prism of Milgram's experiment “Submission to authority”

Last week, I spent a decent amount of time removing the dead code from our codebase. I love to delete the code. As for me, so few things bring the same pleasure as bringing order to the code. Yes, I love to do it so much that I am puzzled by engineers who leave unnecessary code in the application. But over the weekend I heard someone talking about Milgram's experiment “Submission to authority” (I also wrote about it - note of a translator ) and I could not help drawing a parallel between a man who was shocking another human being and an engineer who leaves known bugs and bad code.

If you are not familiar with the experiment of Stanley Milgram, then it is that the Experimenter (a person endowed with power) orders the Teacher (object of study) to beat a series of increasing current discharges of the Pupil, who is in another room. Wikipedia illustration:

E - the experimenter (experimenter), T - the teacher (teacher), L - the student (learner)

The essence of the experiment was to study the reaction of people to orders that come into conflict with their moral principles. Prior to the experiment, it was believed that most of the subjects would stop the experiment as soon as they realized that they were hurting the Apprentice. However, during the experiment it turned out that an amazing number of subjects reached a maximum discharge of 450 volts.

In the first set of Milgram experiments, 65 percent of the participants (26 out of 40) used the maximum possible value of 450 volts, although it was unpleasant for them to do so; at a certain point in time, each participant stopped and doubted the experiment; some participants wanted to stop and return the money they paid for participation. During the experiment, participants experienced varying degrees of anxiety and stress. They were sweating, trembling, stuttering, biting their lips, moaning, digging their nails into the skin, some laughing nervously.

When we learn about such results, we want to believe that we would never do that. We want to believe that “just obeying orders” is a human flaw that we don’t have. But experiments, such as the Milgram experiment, show that such a belief is optimistic at best, and completely wrong at worst.

And now, when we know how people react to authority, when physical pain is at stake, let's see how programmers react to authority when it comes to more abstract things, such as frustration and inconvenience. Let's take the Milgam experiment diagram and remake it to reflect the development team:

If we look at the development team in the way it is shown in the illustration, it is not so surprising why we, the engineers, leave bad code and leave known bugs. Probably at some point a person with authority made it clear that we don’t have time to fix problems or these problems are not of high priority compared to other things in the roadmap. Or that deleting a dead code does not bring value to the user. As a result, we leave the code as it is and proceed to the next task, although it conflicts with our moral compass and the concepts of what is good and what is bad.

In Milgram's experiment, the subjects often hesitated and protested against sending another discharge to a person in another room. In such cases, the experimenter demanded the continuation of one of the predefined phrases:

• “Please continue” (Please continue / Please go on);
• “Experiment requires you to continue” (Experiment requires that you continue);
• “It is absolutely necessary that you continue” (It is absolutely essential that you continue);
• “You have no other choice, you must continue” (You have no other choice, you must go on).

Without using anything but words, the experimenter was able to achieve that 65 percent of the subjects, against their will, beat the very painful current discharges of other people. I wonder what words we use in the context of software development?

• It is not we who decide, but the product team.
• We need to meet deadline
• The marketing team is set to issue a press release next week.
• We close too few tickets.
• We still throw out this code later.
• This is a temporary solution.
• Need to improve your team's performance.
• This will affect a small number of users.
• This is not a priority for us now.
• We will fix it later
• This is what the management wants.
• Why so long?
• Need to do it faster

I am not writing about this in order to offer a solution. I don't have it. I write in order to cultivate - above all in myself - sympathy and understanding . When I see code that leaves a sense of bewilderment or behavior that I don’t understand, I must remember that actions do not always reflect intentions. I have to remember that engineers leave bad code not because they don’t care - they leave bad code because they didn’t have the freedom to fix it. And they leave the bugs, not because they do not care about users, but because they did not have the authority to deviate from the roadmap product.