[rwallace]

No. (I don't believe cyclomatic complexity is meaningful, so it's not likely your coworker will believe it :))

The following assumes you've already politely expressed your opinion to your coworker and he's disregarded it.

It's important to understand what you're proposing to do here. You want to think of it in terms of fact, but what you are actually proposing to do is start a political fight.

Now, I don't know whether you're right or wrong. I also don't know whether it would be a good idea for you to start a political fight over the issue. I do know three things that are relevant to this situation, however:

1. Whether you're right and whether it's a good idea for you to start a fight are separate questions. It's important not to assume an answer to one automatically implies an answer to the other.

2. It's practically never a good idea to start a fight without carefully thinking through the costs and benefits - all of them, not just the immediate ones - and how you plan to win it.

3. In the modern environment, the usual outcome of a fight is that both parties lose.

[davelnewton]

At the same time, if standing up for code quality implies a "fight" then there are several issues, only one of which is the actual code quality.

CC does matter, even if in a limited sense: the more that can happen in a chunk of code, the harder it is to reason about. I guess I'd always thought that was obvious, because it's the same way with everything. Dismissing it out of hand is disingenuous.

That said, metrics matter at different times, and in different ways. Sometimes things are just complex at the method level.

In any case, if coworker is disregarding input, there's a systemic issue at the personal level. I hope you're just using hyperbole when you say the only course of action is a fight: that's an extreme escalation pretty early in the process.

If the coworker disagrees with the opinion, why not just have a conversation about what both parties mean by "complex"? List the tradeoffs that are being made (e.g., deep vs. wide) and why making or not making them makes sense.

People can discuss differences without "fighting" in any sense of the word. If they can't, they shouldn't work together, because it's stupid and a waste of time.

[VLM]

Speaking of outcomes, what would be the outcome of "your code is too complex"? Until you define that you got nothing.

There is a concept that is sometimes true, sometimes not, of the conservation of complexity. Its not just typical physics envy, sometimes it really does exist. So pushing complexity out of small pieces of code will probably make "something" more complex. So in the idea outcome, what would you make more complex, and why would that be better than status quo? Once you explore that, your plan should be pretty clear one way or another.

And this is where the warfare analogy of allies comes in. If you don't know that the other guy and operations are allied because the somewhat more complex error handling code makes operations much easier, and your bosses boss has some financial interest in making life easier for ops and harder for devs, then you'll be totally surprised when the operations manager or possibly his boss, is called in as an indirect fire weapon on your position. Or possible financial crush you don't know about where you'll ship sooner or none of you will be employed for the maint time anyway. Which sucks, but the only thing worse than living in it is not knowing or understanding why. So you need to sniff out alliances.

And be reasonable about giving up. There may be a perfectly rational reason you don't understand (or, maybe not...) and the best way to handle a failed campaign is to abandon it and wind it down as fast and cheaply as possible.

Its possible to make horrible analogies with the military and endless distraction about politics. However, it seems fairly non-controversial as a learning tool to at least gloss over a five paragraph operations order.

http://en.wikipedia.org/wiki/Five_paragraph_order

I'm not sugggesting writing it all out and using NATO phonetics or making pew-pew sound effects. But failure to plan is planning to fail so if you don't at least gloss over an outline of an op order and imagine what analogy or summary you'd provide for each line, then you're not planning, so you're planning to fail. As far as SMEAC goes, ops question is asking for advice on a part of "E" but most commenters are going to complain that "S" "M" "A" and "C" are going to dramatically alter "E", so its pointless to discuss "E" in isolation.

If you're allergic to the military or think "SMEAC" sounds too much like a james bond villian corporation, there are probably non-mil planning tools of equivalent usefulness that I am not as familiar with, that some should please follow up with links to...