JFYI, and in case you want to add a reference to the chocolate covered banana:

http://web.archive.org/web/20160523201519/http://homepage.nt...

http://web.archive.org/web/20160329162624/http://homepage.nt...

that I have been citing a lot, together with the Yes/No and the Standard Litany:

http://web.archive.org/web/20160527013035/http://homepage.nt...

http://web.archive.org/web/20160604095422/http://homepage.nt...

Will definitely source these, how come the original site is down? Edit: found one that's up: https://jdebp.eu/FGA/put-down-the-chocolate-covered-banana.h...

http://homepages.tesco.net/J.deBoynePollard/

Before being:

http://homepage.ntlworld.com./jonathan.deboynepollard/

all the FGA's are nice, (besides - the technical ones - extremely accurate) if you loved the chocolate covered banana one, you will surely appreciate the "legacy" correct definition:

https://jdebp.eu/FGA/legacy-is-not-a-pejorative.html

and don't miss the note about the secret 7:

https://jdebp.eu/Humour/microsoft-monopoly.html

Do you know if it belongs to a category of problems, in the same manner that e.g. the "either-or" belongs to the category of logical fallacies and confirmation bias belongs to cognitive biases? I always find those types of categories useful in building mental models.

You kind of put me on the spot here, I'm not sure. I'd have to think about it for a while, but my gut feeling is that, yeah, it probably falls in the overarching category of "not knowing/realizing that you don't know something" -- so the failure point is epistemic.

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.