Hunter or Cleaner - How do you approach a search?

I was raised as an US Air Force brat. Like any US military brat, I looked forward to my 10th birthday because on your 10th birthday you get that much coveted military ID that you get (have) to carry everywhere you go. It is one of the highlights of military life.

Now, as a mother of two, I can only assume my parents did not share this excitement because no sooner had I gotten this ID than I had lost it. This losing of my ID in my mess of a room would recur throughout my childhood. I’d cry to my parents that I lost my ID and my mom would always give me the same response “clean your room and you’ll find it”. I hated that response, but I am mature enough to admit now that it was sound advice. I found it every time. And I have found that over the years this has become a common approach when I am looking for lost items.

When people are searching for a missing item, there tend to be two types of searchers:

The hunter will start picking up items: looking around and under them and then putting them back (sometimes in slightly different places). Sometimes the hunter will begin to panic and start tearing the place apart looking for the lost item. In that case, the hunter may find the item only to look around the room and discover they’ve made a huge mess that they need to clean: couch cushions are thrown around; the entire contents of the closet are on the floor; etc. Quite often the item is found in a location the hunter could have sworn they’d checked five times already.

The cleaner will take my mother’s approach and clean or organize until the item is found. At the end of the cleaner’s hunt, they will also have an organized space where the item is less likely to get lost again. Or, if they are like me and just prone to inevitably losing it again, the item should at least be easier to locate in the newly organized space.

Which approach should I take? That will depend a bit on circumstances. If I have five minutes to leave the house before I miss my flight for vacation and my son can’t find his right shoe, I’m not going to start reorganizing his closet! No, I’m going to send everyone looking for the shoe for three minutes and then I’m going to make him wear different shoes and reorganize after vacation. But if I can’t find the Phillips screwdriver I need in order to tighten a slightly loose cabinet knob and the garage workbench is a complete mess, I’m going to take the time to reorganize and put things away until I find it.

Now, why in the world am I talking about lost IDs, shoes and tools on a blog primarily about software development? Well, these approaches to searching for a lost item can be applied when attempting to resolve issues in software development as well. I’ll get a call that an issue is occurring and we aren’t really sure why or even where in the code the error is located. And so, the hunt is on. Instead of looking for a lost ID, I’m searching for the source of a software bug, but the same approaches can be taken.

Should I hunt or should I clean? Just as I wouldn’t miss my flight for a missing shoe, if I am presented with a mission critical bug that is causing major issues in production every minute, I’m not going to be able to clean, even if I want to. I’m going to become a hunter or perhaps apply a work-around and come back as a cleaner to find the source later.

Just as the hunter looks under the couch and under papers on a desk looking for a lost ID, they will dig through code and logs, searching for the cause. The hunter may increase the logging level or add logging statements. If the issue is really hard to find and the search becomes more frantic, the hunter may even attempt to hack at possible solutions. Once the bug has been found and resolved, the hunter may have some temporary logs or intermediate attempts to revert.

However, if the issue is less time-sensitive or a work-around is in place, I will likely make an initial attempt at a non-frantic hunt. Then, I will become a cleaner. The cleaner will take on a methodical organization/cleaning process to help with their search. They may pull large sections of complicated code into reusable methods. They may rename a method or variable to make the usages clearer when reading. They may remove chunks of dead or commented out code that are getting in the way of understanding the code’s purpose. During all of this cleaning, the issue will hopefully reveal itself. Just as it is easier to locate an item in a clean room, it is easier to locate an issue in clean code. Having found the problem, the cleaner will fix it and leave the code not only fixed but also cleaner for the next time.

The cleaning approach can be particularly useful for software problems such as slow performance, intermittent issues, or when someone comes to me with “I’ve already looked everywhere and can’t find the issue”. The more complex the code, the more likely the cleaning technique is to be helpful, but sometimes even seemingly clean code benefits from this approach. In one such cleaning search, I encountered a method called “isPastCutoff” that was really returning true if the item was before the cutoff. So I renamed it to indicate it was really “isBeforeCutoff”. Having made that simple refactor, I spotted the issue - a caller of that method that had relied on that name now getting the opposite of what the caller wanted.

The next time you find yourself looking for an issue in code, which type of searcher will you be? Will you become a hunter, searching for the issue before modifying the code? Or will you become a cleaner, refactoring and organizing as you search?