[dalke]

Unfortunately the OP and possibly co-worker would need to believe that the results of a CC analysis were meaningful. Also, some problems are irreducibly complex.

One solution is for the OP to come up with a shorter, cleaner, better, etc. solution. Actually presenting that version to the co-worker can be interpreted as directly confrontational ... though presenting metrics instead would more likely be interpreted as a side-handed attack, rather than a direct attack.

But if the OP can come up with better code, then that would answer to the OP's own satisfaction if the co-worker's code really is overly complex. Personal enlightenment (I tell this to myself) was all the OP was asking.

[dvanduzer]

A question I'm asking myself more often as I get older: What is the value of changing somebody's mind?

To that end, rather than prove someone else's code is complex, we can emphasize the virtues of simplicity with what we do. Refactoring someone else's code in smaller increments would be the passive aggressive middle ground.

There are more opportunities with code that hasn't been written yet. Maybe suggest watching this lecture as a group and then just discussing it without any additional agenda: http://www.infoq.com/presentations/Simple-Made-Easy

[spacemanmatt]

Having worked a couple decades in the trade, occasionally with some very unstable people, I have seen one suicide. I doubt it had anything to do directly with work but it's been a reminder to be nice to people, even when they are wrong.

[meragrin]

Just merely writing what you think is a shorter, cleaner, better solution isn't really enough. It can be easy to overlook the reason for the complexity. If the rewrite seems to work as a replacement, just use it to come up with questions about the current code and ask the co-worker. If there are actual reasons for the complexity, add the necessary comments so someone else doesn't have to go through that or find out the hard way.