I've worked in such places. The reason it is that way is because you will receive a broken description/specification/story of what you are supposed to implement. You have a choice to make when that happens, you either implement it as specified or you reject it because it is broken. The problem is that if you do reject it then it will take about 6 months to get back a specification that is broken in another way and then you have to make the same choice...

So after a few iterations you just say "fuck it" and implement it as specified and then hope that you get a chance to fix it before shipping it (or that it doesn't become your headache later on...).

I've been there too, and I know. I'm not speaking to the choices devs make (rock and hard place, as you say), but the choices the org makes. For government work is driven by Congress' procurement process, but for enterprise is entirely on upper leadership's perceived need to avoid risk. Which is ironically hilarious, since such approaches guarantee higher risk, in that they pretty much universally lead to late delivery of broken features.

Enterprise developer here. Exactly this. If you reject the spec, you won't get another one before the deadline that was committed before you got the spec you want to reject.

Instead of implementing the obvious intention of the spec and waiting to see if anyone complains?

The intention usually isn't obvious. The stakeholders have spent so much time documenting, in depth, the solution that they want, while spending no real time documenting or communicating the specifics intricacies of the -problem-.

That's the issue in a nutshell; Checkbox Driven Development implies "if we just define the solution well enough upfront, we'll get what we need!" instead of "if we define the problem well enough, and let dev pitch us solutions, and iterate as we go, we'll get what we need". Which implies that the devs are not to be trusted to come up with a solution themselves.

To deviate from expectations and be congratulated, you have to, A. Be certain you're doing the right thing, and B. Have an audience that can recognize you did the right thing. Both of those require a level of trust that is just missing in this sort of org.

Exactly, and sometimes to fix the issues with the spec you'll have to go far enough off script that it gets very obvious to people you dont want attention from.

"Monkey Paw Development" was a new one for me :) Thank you! Great analogy. Reminds me of this :D https://www.youtube.com/watch?v=cDA3_5982h8

Yeah, I just coined it while making the post. :P Less a "also (currently) known as" and more of a "also (should be) known as". Certainly how I'll be referring to it in cynical moments from here on out.

I was reminded of this: https://www.youtube.com/watch?v=5W_wd9Qf0IE

Requirements are hard in dysfunctional organizations, or those with more stakeholders than capability and agility.

Requirements are hard upfront, period, to the point I'd say that any organization trying to set them upfront is dysfunctional, tautologically. Making all the decisions when you have the least amount of information is a Bad Idea.

Also, how long will it take to build and how much will it cost? :)

This is where Agile ought to improve things, but then SAFE came along and we were back to square one.

but there are some architectual significant requirements, which have to be known upfront.

I both agree and disagree with you.

There are requirements that will affect architecture that, if they're guessed at and turn out to be wrong, will lead to massive refactoring and/or large amounts of effort being thrown out. 100%.

Where I disagree from most businesses is in the implicit belief they have that seems to be "better for devs to be idle than for devs to work on code that will be thrown away". I'd rather take a guess and start work; best case we're right and are ahead; worst case we're wrong and have learned some useful lessons.

Which you'll note is the same dilemma as every other decision related to the project, with the only difference being the scope.

I wonder the extent to which those two specifications describe the exact same organizations.