I was visiting a team a while ago and we came across an area of code with extremely long methods. We looked around and tried to understand the code but its shape and intent was lost in this jungle of run-on statements.

The remedy for this sort of thing is usually very straightforward - you refactor - you select cohesive bits of code and extract them as methods. I was ready to do this, but one of the developers stopped me. "Wait!", he said, "You can't extract that, look at the logging."

I looked and noticed that all of the logging statements were prefaced with the names of the methods they were called from.

I said "Well, we can decide on an alternative or we can preface the calls with the names of the methods we extract." And, they said "No, we count on those names to maintain context. If we extract a method and then call it from someplace else we won't be able to debug our production problems."

I said "You can build nested scopes into your logging."

They said they'd mull it over. We looked at different code.

It was a brief episode, but it reminded me of how much I hate logging. Yes, I realize that it is necessary in many environments, but for me it is definitely in the "necessary evil" category.

Whenever possible, I like to restrict logging to particular level in a design. When it runs rampant through code, it makes the code harder to understand, and people are reluctant to change it.

Yes, logging is useful, but it is a very real form of coupling. If you log you have to manage the coupling it induces. If you don't, it will manage you.