Hyperfixation In Problem Solving

With spring fully tilted, it's time to turn on the irrigation. Because the house doesn't have sprinkler irrigation, turning on the irrigation becomes an effort in design. The system has undergone several revisions over the seasons to balance the system's ability to cover every corner and my willpower in managing it. The best solution so far has been the use of an irrigation tractor sprinkler. Setup is as easy as a timer, a hose, and the tractor.

At the start of Spring, I went through just that--a timer on the spigot, a hose on the timer, and the tractor on the hose. On its maiden journey, the tractor didn't seem to be performing quite as I remembered. A quick change to the sprinkler’s spray arms and now it's working as expected. However, a few days later, I realized the issue was getting worse. It's time to do a little bit of debugging to figure out what's going on. I took the hose off the spigot to check the flow was fine. Next, I checked the connection between the hose and the tractor for a blockage caused by the unfiltered reservoir water. There was a little bit of debris, so I cleaned that out, set the timer to manual, and tried the system. It was performing even worse. I then thought, “Well, I’ve never maintained the tractor so maybe it's time to take it apart. That must be it, I’m sure there's something in the tractor blocking the flow.”

I spent the next few hours taking the sprinkler apart, making a trip to the hardware store to get a 3/8th Allen key socket and grease, and then making a second trip to “get the right socket this time!”. The insides were practically pristine; though now my socks soaked, and my hands covered in a lotion of grease. I’m stumped, but as soon as I have it all together, I realize I skipped a part of the system. Did you notice?

I walk over to the spigot, remove the timer, flip it, and the filter is choked with sand.

You see, there's this thing we do when we interact with systems. We make assumptions on how that system works, and when problems arise, we often focus on certain “problem” areas. We do this because most of the time our assumptions and intuition are often correct. Why worry about C when X has been terrible for as long as we can remember, and it's constantly having issues.

This exact issue appears in software development constantly. We see this in legacy systems; we see this in poorly designed systems; and we see this in systems that were created with high pressure to produce features. We must constantly make assumptions and rely on intuition to find the source of issues. Then we address them as quickly as we can, because the next issue is right behind-- and this time it might be in the tractor. This hyperfixation comes at a cost: time and effort, effort better spent on other issues or put into other areas like documentation and tests (Oh my!).

My irrigation setup was simple, and I still fell into the trap of hyperfixation. I had convinced myself that my simple system couldn’t have any issues, and the issue must be a part of the system I didn’t design; that green sprinkler tractor was taunting me with its hidden issues. Instead of considering other potential problems, I dove deep, tore the whole thing apart, put it back together better, and the performance wasn’t improved, it was worse.

My debugging was flawed due to the assumptions that had served me so well every other time. The next time I need to solve a flow issue, I now have a new process: check spigot, check the timer, check the hose, then take an hour to tear the sprinkler apart.

Even though I've been QA’ing for years and finding more bugs than features, it was an important lesson to remember the basics of chasing down an issue, starting at one end and going to the other. Don't assume entire parts are working as you remember. And don’t hyperfixate on something for hours until you've ruled out that other parts of the system work as expected. You'll just end up with wet socks, covered in grease.