Hacker News Reader

Comment by dvt | Hacker News Reader

> Pretty embarrassed about our current state of leadership skills. In my current organization, we call this syndrome "bring me a rock". Like, I bring a rock, and she says "it's too big, or too brown, or whatever". Instead of outright saying, "I need a medium, smooth, grey, rock". I can deliver if you're explicit.

This sounds like an example of the AZ problem[1].

[1] http://azproblem.info/

View on HN

have you made more sites like this beyond the AZ and XY problems? I'd love to be able to cite these when trying to talk about these topics with people.

The XY problem is kind of famous and I actually didn't make that website (although I find myself citing it all the time). I kind of "invented" the AZ problem because I ran into it multiple times at my previous job and thought about formalizing it in some way.

Hope you find the website helpful! :)

Interesting, I'd never heard of it before - but it puts a name on something I think we've all experienced many times. The AZ problem is a useful generalisation too, it digs towards the root cause.

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.

> Do you know if it belongs to a category of problems

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.

no pressure :) I was just curious if you'd happened upon such a thing. I find these groups of errors helpful for understanding interpersonal dynamics - I might go have a read around, I'll reply on here if I find anything.

if (today.month != tomorrow.month): send_email()

I think you missed the point. The point isn't to be clever or figure out a way around the ill-suited requirements, the point is to avoid coming up with ill-suited requirements altogether!

Yeah, but this is a bad example of that. It's not that the last day of the month is an ill-suited requirement, it's that, in the example, the programmer who wrote the code for the end of the month did more work and wrote more error prone code than really needed to be.

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.

> 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".

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 :)

How does the computer know that today is the first day of the month without already having a complete calender implentation?

It's a frivolous and simple example to show the underlying impact of not understanding the context of a hypothetical feature request.

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.

"The Complicators Gloves" - https://thedailywtf.com/articles/The_Complicator_0x27_s_Glov...

Better come up with a way to calculate tomorrow's date, then. I suppose it'll be today's date, plus one, unless today is the last day of the month. I'll just write a function first to calculate if today is the last day of the month...

Bookmarked, thanks. :-)

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...

Oh man, I love that "chocolate covered banana" example, I've never heard of it before, thanks!

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...

Good find, thanks, just bookmarked it, it must be the new one, over the years the site moved already a couple of times, it was:

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

Reply on news.ycombinator.com