McDonald’s Theory Of Bug Fix

I like Jon Bell’s McDonald’s Theory and have put it to use from time to time. Last Monday was one such day.

My boss gave me a random bug. I debugged it and figured out what was wrong, but I was still unsure how to fix it. The code seemed to have some layering violations, but the right way to distribute the responsibility between the layers was unclear.

Looking at the commit history, the person who can fix this became apparent. I was wondering if I should just reassign the bugs to them, but that kind of action has had mixed results: People tend to push back, dodge or ignore. No one wants to waste their time on bug fixes.

Then, the idea of McDonald’s Theory came to my mind: Instead of reassignment, I “fixed” it anyway, and sent the PR to that person. To my own credit, I didn’t make a McChicken fix. I tried my best, and I’d consider it more like a McCrispy.

Yet, I know they will push it back. They indeed did. It was still a cheap McDonald’s fix. And it worked as McDonald’s: They thoroughly explained how wrong my “fix” was in the PR comment. So I appraised their analysis, pointed out they are much better positioned to fix it then asked to take it over.

As the theory goes, they agreed. And they gave me their version of the fix after a couple of days. It was better for sure: Instead of piling crap like mine, they removed the code in question. The layering violation seemed to be a leftover from some past refactoring, and the smelly code was not necessary after all. My faith in the theory has elevated.

I should acknowledge my luck that I hit the good engineer. The pattern I had seen was either 1) People just took the crap or 2) People pushed back but did nothing. Neither happened. They did what was supposed to be done, and I appreciate this healthy ending. People shouldn’t eat McDonald’s every day, and they need the ability to cook a good meal.