@grrrr_shark

> I don't usually go looking for people's employers for privacy reasons (...)

If that was unobvious, this is exactly why I said anything explicitly (to make it obvious that I don't mind).

> I think there's a healthy dose of "I'll do that because I have to", but it helps to be in a position where you know you have management who will push reality checks back up the line.

It seems to me that you're referring to two things at the same time: one of them is having support for doing things that obviously further stated goals, and the other is having support for getting a discussion (that ends with everyone being convinced of the final result, or at least with the differences being distilled to some differing assumption) about whether some subgoal actually furthers the goal it's part of[1]. Do you see them as the same thing/do you see different distinctions here? I'm really curious about different viewpoints in this area that I can grok, because in a wider area around this topic I see viewpoints that I find not very comprehensible.

(One thing that I can't get past is an expectation that, pithily stated, modus ponens works. I can't really see how one can work in a multi-person organization without communicating in a way that can be transcribed in terms that admit logical[2] reasoning. Maybe that's a source of a large part of my issues?)

> where requirements were squishier because we were making something totally new

I find this curious. I see squishier requirements not in the areas where something genuinely new is happening, but rather from the areas where newish requirements and pre-existing architecture have an impedance mismatch, or where a new, very high-level requirement is translated into verifiable ones (which IMO end up not being that verifiable often). Do you mean "new" as in "new things that needs to be designed" or "new requirements applied to existing system"?

> those requirements were usually bound to someone's ego, and then the calculus was "what is the personal impact of challenging this"

Thankfully, I've mostly/completely avoided thinking about such considerations. When I try imagining working with such constraints, it seems sadly eerily similar to some problems I had with (IMO non-self-consistent) interpretations of vague requirements I've had experienced in the past year.

> And I think some people are more fundamentally irritated by those requirements than others - my daughter would flip her shit

I'm afraid I'm much closer to your daughter then :)

> I kind of integrate it into the challenge of the constraint system if it's not going to break everything

ISTM that these blast radii would usually be quite large, if someone wishes to use standard logic (where e.g. false actually implies everything and so where reductio ad absurdum is trivially valid) to reason about the whole thing.

> How do you deal with such things?

Somewhat badly, which is why I'm currently on somewhat long vacation. I mostly try to (a) point out the problem (b) if that doesn't cause things to change, avoid the area. Sadly, either due to changes in the company or changes in which parts of the company I'm exposed to, (b) is happening more often.

I'm also worried that all of infosec is going to become more vague in these ways (because many of the vague requirements are IMO downstream of externally imposed requirements that are not phrased precisely enough to achieve the goal the phraser had), which will probably hasten my move to some other area (data compression?)~~~, both for direct reasons and because this must have downstream effect on which people choose to work in the area, and thus on me feeling understood (and v.v.) by my future coworkers.

[1] Please tell me if I'm confusing here; tips of how to be less confusing would help (I find it hard to go with 'provide examples' one, because then it either gets very verbose or I'm unhappy with examples being misleading).

[2] in the meaning of "you can assign truth values to statements"