[blowski]

Gerald Weinberg was a prolific author in the tech consultancy space, and most of his writing consists of anecdotes like this. He explains his theories by telling stories, the veracity of which isn’t the point.

On the specific note, I frequently make these mistakes, despite having read his books and knowing the problem to which he’s referring. I say “could you just…” and “we should really do x today”. In the abstract, we can all see the problem, yet it’s easy to forget in reality.

[JadeNB]

> On the specific note, I frequently make these mistakes, despite having read his books and knowing the problem to which he’s referring. I say “could you just…” and “we should really do x today”. In the abstract, we can all see the problem, yet it’s easy to forget in reality.

Oh, sure, I don't mean "no one who has read RFC 2119 will ever use 'should' incorrectly." I mean that I would hope that someone who understands the need to define 'should' would recognize, when looking at a requirements document and themselves singling out the word 'should', that divergent opinions on its meaning could be at issue.

> He explains his theories by telling stories, the veracity of which isn’t the point.

I am not so concerned with whether the story did happen as with whether it could happen. I think telling such a story risks giving a misleading idea of the ways of getting people to understand their difference—that "here, let me define that for you" in such a bald-faced form is a productive post-conflict resolution strategy. (After all, it's what those of us with engineer's disease, or at least I, think should resolve such a conflict.) More honest, I think, to emphasize the importance of such interventions beforehand than to pretend that people will easily respond amiably to them afterwards.