My last post on refactoring generated a lot of conversation so lets look at a different aspect of that.
When I teach refactoring, one of the exercises I use is a kata for scoring a tennis game. I give the attendees some working code with reasonably good tests and the instructions to refactor the code to make it better. I tell them up front that the goal is improving the code, not just moving things around, and that I’ll be asking them during the debrief how they made that code better.
Even though the code isn’t very large, there are enough problems with it that you could spend multiple hours cleaning it up.
This particular kata illustrates so many teaching points but there’s one in particular that I want to talk about today.
I’ll split the group into pairs and have them work on the code-base with their pair. Inevitably at least one pair, and sometimes the whole group, will stop about ten minutes in and say “there’s nothing else to fix so we’re done”.
They made a couple of superficial changes and declared that everything left was great. Why is this?
It would be easy to say that these people are lazy or unmotivated and yet that’s rarely true. The real problem is that just don’t see what was right in front of them.
Our brains receive billions of bits of information every second, and our conscious minds are able to understand almost none of that. Research shows that an average person can hold 5-9 (often described as 7±2) chunks of information in our working memory at any time. Only the tiniest bit of that information that we receive every second actually makes it to our conscious awareness.
The part of our brain that decides which bits are important enough to bring to conscious awareness is called the Reticular Activating System (RAS) and it has some fairly simple rules that it follows, that revolve around survival, personal relevance and beliefs, your goals and intentions, and various emotional cues.
The key bit here is that the RAS re-tunes itself constantly based on what you tell it is important.
Have you ever found yourself looking for a new car and when you select one, now you start seeing cars like that one everywhere you go? That is your RAS tuning itself for that particular make of car. Those cars were always present but you didn’t see them until the RAS decided that they were important.
How is this relevant to the original point of people not seeing poor quality code? It’s because the people who aren’t seeing the problems in the code, have never trained their RAS to look for problems in the code, and so they honestly don’t see them. “The code all looks great to me”.
This is why we continue to propagate poor code - because we can’t fix what we can’t see.
As a quick aside, you may be thinking that AI tooling will solve this because it will write better code. AI is a fantastic amplifier - if you’re already writing great code, it will help you write lots more of that. But if you’re writing lots of poor quality code, it’s going to help you do that really fast too. And you won’t be able to correct the AI if you can’t see the problems with the code that it’s generating.
So how do we train our RAS to identify that poor code? The real answer is repetition. We need to spend time looking for problems in the code. Perhaps we’re doing katas to actually improve that code or perhaps we’re doing things like Code Smell Bingo where we make a game out of identifying problems. We need to train our brains to recognize problems so that our RAS starts to help us rather than hiding the problems. Doing that requires repetition.
Can we train our RAS without doing katas? Certainly, we could focus on that through more disciplined code review. That’s just going to take a lot longer, particularly if we’re doing individual and asynchronous pull request reviews, rather than actually talking through the code as a group. Then in the meantime, we’re continuing to add poor quality code to the system.
Want to help your teams improve their ability to find and fix problems in the code? Let’s talk. I’ve been doing this for decades now.
See also: This article on how we often don’t see blockers which can be caused by exactly the same problem.