Accusations of "stop energy" are "stop energy"
By sommerfeld on Nov 02, 2007
So, there's this hot new newage-y (I think that rhymes with sewage-y) concept being bantered about by certain people called "Stop Energy". It seems that it's been used primarily as a non-rebuttal rebuttal to project review comments that the reviewee would rather not deal with.
Many desireable properties of large systems are not localized to any one part of the system. Security is a key example, but performance and availability are others. Senior engineers in organizations which produce such systems often have an obsessive-compulsive streak -- because they have to. In order to preserve or enhance that property, you need to get all the details right, and this often results in long list of "stuff you got wrong" coming from reviewers. It's easy to misread this as a message to just give up.
But it seems that the new thing is to instead accuse the reviewer of applying Stop Energy to the project.
Based on what appears to be the canonical definition, it occurs to me that these accusations of "Stop Energy" are .. an exertion of Stop Energy against the reviewer. The reviewer actually is trying to help, it's just that there's a breakdown of communication such that constructive criticism is interpreted as an attempt at stonewalling. So, the frustrated reviewee counter-stonewalls, perhaps with this accusation.
A more constructive response is to honestly ask "okay, so what should I do?". And then listen, and change your proposal accordingly. Maybe the requirement you just learned about overlaps with your requirements in such a way to produce a null solution set, so maybe you need to go back and adjust your requirements.
UPDATE: Perhaps I should have been clearer. My non-snarky view is that "Stop Energy", if it exists, only exists in the mind of the person who stops in response to criticism. In a large project there isn't a single frame of reference in which you can declare some action unambiguously as "forward progress". Reviewers often point out things where, in certain frames of reference, a proposed change is a big (or small) step backwards. In the large, those reviewers are themselves charged with (say) improving the overall security of the system; and in that scope, one or more proposals that introduce more insecurity form a barrier to progress. Reviewees often hear the "no, don't do it that way" part of the message and then tune out and fail to get the message about the requirement they overlooked and cause the subsequent conversation about alternatives to fail. And as a result a message intended by its speaker as "do it a little differently" is received as "don't do it at all".