On August 1st of 1966, Charles Whitman climbed a tower a the University of Texas and went on a shooting spree. After, the coroner discovered that Whitman had a tumor in the part of the brain that controls anger and aggressive behavior. A few days before the event, Charles wrote in his journal about noticing feeling different over the past weeks and months.
The book leads up to a question of whether we ask the right question in criminal cases: blamability VS ability to be rehabilitated. I think we are asking the wrong questions in software and would like to talk about that.
In Incognito: The Secret Lives of the Brain, David Eagleman describes all of the individual parts of the brain as zombie systems. None of the systems really have a concept of anything outside of the very specific jobs they do. Our consciousness or awareness is the CEO or director of the zombies.
Eagleman brings up an interesting point about the justice system. Trials and sentencing system usually seems to be based on culpability and blameworthiness. Trials focus on the question of ‘how sure are we that we can blame this person for that crime’?
In software development, the stakes usually aren’t so high. People (usually) don’t go to jail for bad software. But we face similar questions that often focus on who can be blamed and held responsible for what.
I think we should focus on the ability to learn and move forward from mistakes.
Who Broke the Build?
Almost everyone that has written production has broke a build at some point. I had the honor with my first commit in the early 2000’s. When this happens, heads pop up and every one starts asking who is responsible. Key word here being: responsible. Some companies pass around rubber chickens or have lights that flash to shame that build breaker. As if shame is a tool that will make them write better code or remember to check in all their changes next time.
When questioning stops after discovering who broke the build, the question was almost entirely a waste of time.
The real value in this question is can the person that broke the build figure out why the build broke, what systems of software and behavior lead to the red light, and then make that mistake rarely if at all in the future.
Why Didn’t You Catch That Bug?
This is a question that I haven’t heard lately, not because I don’t miss bugs sometimes (I do), but because I work with good people. I have heard it many times in the past and have felt the same combination dread and eye-roll every time. The typical scenario is something along the lines of a customer reporting a bug, support figures out what feature the problem is in, dev figures out who tested that feature, test management figures out who to give a talkin’ to.
The only reason we should ask this question is to use as a tool to learn more about how our customers are using the software we build, or to discover categories of mistakes a developer has a tendency to make, or to learn about how our systems are not integrating in the ways we think they should.
The focus on learning shifts the motivation for question from blame to rehabilitation. Incognito refers to this concept as neuroplasticity. That is a fancy work for how able a person is to learn or reprogram their brain.
Could Charles Whitman have been returned to society as a healthy contributing member if he had been treated for his tumor? We’ll never know.
Can programmers and testers improve with nurturing and a focus on improvement rather than focusing on who did what wrong?
I bet we can.