if (today.month != tomorrow.month):
send_email()
If this was a code review, the end of the month code in this example should get flagged for its complexity, when it can be replaced with the single conditional "if tomorrow.day == 1".
It's entirely fine to question the specification/request here, and ask why the end of the month. Not because the code that detects the end of the month can be written in a complex fashion, as it was here. Rather it doesn't seem to meet the requirements: The Account Manager doesn't realize that by processing on the last day of the month, rather than after the last day of the month, is going to miss out on some portion of the last day of "accumulated fees" for the month (depending on the rest of the implementation). The Account Manager has requested an implementation detail that doesn't meet the requirements, and now rework is required.
But it's not a code review. It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request. I have a feeling that in typical engineer fashion, you're missing the forest for the trees. Trust me, I've been there :)
Yes, it is a contrived example, that's my point. But it's not the programmer that didn't understand the feature request, it's the entire organization. A questionable decision earlier made by the Account Manager led to an overly complex, questionable implementation that will lead to more code and more bugs. Trust me, I've been there.