Last week, I spent a good amount of time deleting dead code from our application codebase. I love to delete code. As far as I'm concerned, few things in life offer as much excitement and satisfaction as decreasing code-rot. In fact, I love it so much that I become confused by software engineers who leave the dead code in the application in the first place. Over the weekend, however, I was listening to someone talk about The Milgram Experiment on Obedience to Authority Figures; and, I couldn't help but draw parallels between the person who shocks another human-being and the engineer who leaves known bugs in the user experience and rotting code in the codebase.
If you are unfamiliar with The Milgram Experiment (conducted by Stanley Milgram), it's an experiment in which an Experimenter (ie, the authority figure) orders a Teacher (the subject) to give increasingly dangerous electric shocks to a Learner who is believed to be in another room. The following graphic is borrowed from the Wikipedia page on the topic:
| || || |
| || |
| || || |
The intent of the study was to see how people would respond when asked to do something that conflicted with their own set of morals. Before the study, it was believed that most subjects would refuse to send an electric shock to the Learner once the subject believed the Learner to be in pain. However, once the experiment was conducted, a surprising number of subjects would end up delivering the most powerful 450-volt shock, even when the thought of doing so felt absolutely abhorrent.
In Milgram's first set of experiments, 65 percent (26 of 40) of experiment participants administered the experiment's final massive 450-volt shock, though many were very uncomfortable doing so; at some point, every participant paused and questioned the experiment; some said they would refund the money they were paid for participating in the experiment. Throughout the experiment, subjects displayed varying degrees of tension and stress. Subjects were sweating, trembling, stuttering, biting their lips, groaning, digging their fingernails into their skin, and some were even having nervous laughing fits or seizures.
When we hear about findings like this, we all like to believe that we would never do such things. We like to believe that, "just following orders," is somehow a human flaw that we don't have. But, experiments like this demonstrate that such assumptions are optimistic at best and completely wrong at worst.
And, now that we see how people respond to authority figures when physical pain is on the line, let's think about how software engineers respond to authority figures when mere abstract frustration and inconvenience is at stake. What if we take the Milgram Experiment diagram and rework it to reflect our engineering team dynamic:
| || || |
| || |
| || || |
When we look at the engineering team like this, it's much less surprising that we engineers leave dead code in the codebase and allow known bugs to present in the user experience (UX). Perhaps at some point an authority figure made it clear that we didn't have time to fix problems or that said problems weren't a high-enough priority on the product roadmap. Or maybe that cleaning up dead code didn't add value from the user's perspective. And so, we move on to the next task even though leaving the code as-is conflicts with our internal moral compass and our sense of right and wrong.
In the Milgram Experiment, the subjects often raised concern and objection about sending the jolt of electricity into the human-being in the next room. But, the experimenter would prod the subject into continuing with the following phrases (from Wikipedia):
- Please continue.
- The experiment requires that you continue.
- It is absolutely essential that you continue.
- You have no other choice, you must go on.
With nothing but words, the experimenter was able to get 65-percent of subjects - against their will - to deliver extremely painful electric shocks. I wonder, what words do we use in a software engineering context?
- It's not up to us, it's up to the Product team.
- We have to hit our deadline.
- The marketing team is going to release a press-release next week.
- You're not closing enough tickets.
- We're going to abandon this code eventually anyway.
- This is just a short-term solution.
- You're team's velocity needs to be improved.
- This only affects a small number of users.
- This isn't a priority for us right now.
- We'll come back and fix this later.
- Because that's what management wants.
- Why is this taking so long.
- You need to step up and get this done.
I am not writing about this to provide a solution. I don't have one. I am only writing about this to cultivate - in my self - a better sense of empathy and understanding. When I see code that frustrates me and behavior that confuses me, I have to remember that actions don't necessarily represent intent. I have to remember that engineers aren't leaving dead code in place because they don't care - they're leaving dead code in place because they aren't given the freedom to clean it up. I have to remember that engineers aren't leaving bugs in place because they don't care about the users - they're leaving bugs in place because they aren't given the authority to deviate from the product roadmap.
Looking For A New Job?
Ooops, there are no jobs. Post one now for only $29 and own this real estate!