The Easy Fallacy

I was talking to one of the younger engineers at work recently and he said that he appreciated my experience. After I realized that it wasn't one of those - your so old moments. I laughed and told him that is probably more true than he realized. For instance, we were talking about an a fix that he labeled as "easy". I told him that in my experience easy changes can be a fallacy. I could see in his expression that he knew what I saying but he didn't know what I was saying.

I can't count the number of times when me, my colleagues, and/or team fell for this one. It looks something like - the change is a small one, often innocuous - like a configuration change. If you're nodding you're head right now, then you too have fallen or been witness to this one.

This happened recently a couple of times. One looked like a change that when merged to to the main branch, inadvertently picked up an unrelated change. This change was not something that was caught until it was promoted to production and resulted in a performance impact. As a result we had a week delay two weeks before the larger launch because we had to do even more work to earn trust that it would not happen a second time.

A contributor to falling for this fallacy is that making simple changes in a complex system isn't about how small the change is - it's about everything else after the change.

Which begs the question, how do you not fall for this one? I feel like this one hurts the most when your under a time crunch and your belief in the fallacy convinces you that you should make "easy" last minute changes. Ouch. Or that you let your guard down on the "easy" change and miss something. The answer for these two is - don't do this. I am sure you have your version of this.