I would say: Looking at anything without the context can lead to wrong conclusions.

Everything has some context. Sometimes the context is obvious but we should not assume like that.
A little different example:
The one of the most problematic thing in soft-dev are estimations. The only possible to way to estimate anything is compare it to something “similar” what was already done. It requires a lot of expertise to take right context (not to deep and not to shallow) to make a decision that “cost of x is like (or twice as) y”. Unfortunately (soft-dev) people many times don’t even try to think a while about the context before making decision/giving estimation/judging design or code.

The beginning of it is very aligned with Nat Pryce’s theory about:
“Complaining about Other People’s Code”…. It’ss

Check it out…

http://www.natpryce.com/articles/000756.html

Cheers,

Thanks for sharing your reflections on this fundamental but often neglected issue.

I fully agree that design decisions shouldn’t be evaluated solely on the basis of generally accepted principles and rules. The relevant contextual aspects must be brought into the design process.

Indeed, I think the context is so important that even refactoring shouldn’t be absolutely constrained to the program texts. The program context points the best directions when we advance beyond trivial structural improvements.

This issue resonates deeply with me. I have been reflecting on this, as part of my learning journey, at http://sympriser.wordpress.com/?s=Revisiting+Fowler+Video+Store

Greetings,
Rafael

This helps give the context that you mentioned, and helps avoid “trash talk”. It might even be that the circumstances have changed since the comment was written, so the break from convention is no longer needed.