Accusations of "stop energy" are "stop energy"

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


It's an old term, Bill, dates back to the last century :-). "Stop Energy" is when you use your energy to stop something rather than to fix it. You can tell when it's happening because positive comments get no uptake whereas procedural devices to derail people's "do" show up everywhere. A sure-fire sign it's around is when people with positive outlooks are accused of it.

Posted by Simon Phipps on November 02, 2007 at 05:02 PM EDT #

Personally I prefer to think of review as a conversation between the reviewer and the reviewee as to how to make their project better. In the example of a code review the coder is the expert. As a reviewer I try to think beyond what they might have considered and hope they are willing to hold a conversation about those things. I don't consider the issues I raise as set in stone.

In higher level reviews or tiger teams I've been involved in I try to fight the impulse to have to produce something. Its fine for those teams to produce the answer that all is well. The impulse to always need to "find a comment" tends to create combative environments. Its should also be ok to have comments that don't need a response. That is just part of the conversation.

Posted by Michael Hunter on November 02, 2007 at 05:41 PM EDT #

Ideally a review should a conversation between differently-focussed experts. In a code review, the coder is (hopefully!) the expert on the proposed change. Other reviewers should be experts in both the module being changed and on other parts of the system.

If the coder cannot convince others that their proposal is the right thing to do, it has no business being in a large scale industrial-strength operating system.

Posted by guest on November 03, 2007 at 12:50 AM EDT #

Post a Comment:
Comments are closed for this entry.



Top Tags
« June 2016