Hacker News Reader

Comment by Scubabear68 | Hacker News Reader

Old style Java code often exhibits low CC, and as you indicate this is not necessarily a good thing. The actual logic is often spread out in a multitude of helpers, proxies, deep inheritance chains, and unneeded abstractions. The end result is a system that is very difficult to reason about.

Also, in general terms over use of DRY can lead you here.

In many cases it is better to “risk” higher CC by concentrating logic where it makes sense.

View on HN

Yeah I agree with this. Or, rather, I think there's an argument to be made that what we're really interested in is logic density Vs logic sparsity and when developing something we have to decide what the right level of that is. So if you're a small team, logic density makes sense because it means one person can have a lot of context in one place and make significant changes without doing a lot of context switching. Don't underestimate the productivity of one experienced guy doing old school PHP.

But if you're a large team on a large project logic sparsity (with appropriate decoupling!) makes sense because then multiple people can change the code simultaneously without stepping on each others' toes. People can specialise where appropriate without having to understand the whole thing. The "sparsity" approach is obviously what enterprises see as good news mostly because it means they can have large teams without silos but in real terms it costs a lot of money to operate this way. Although I think as you rightly point out, Java has in recent years realised that it possibly went a bit too far in that direction historically.

I hear what you're saying here, but I like to delay going in the second direction as long as feasibly possible.

In theory, the idea that "people can specialise where appropriate without having to understand the whole thing" sounds good. In reality, so many, many, many bugs and piles of technical debt pile up from developers with a worms eye view who don't understand how the whole system works. Eventually you have to make this compromise, but resist it as much as you reasonably can, and always strive to grow developers so they know as much of the system as they possibly can.

Exactly, and this is why I always try to steer teams away from "one metric to rule them all" whether this be "always fail if coverage is less than X percent" or "random code metric like CC is beyond limit". Reality is simply more complicated than that, and it takes experienced engineers to actively manage and balance the tradeoffs appropriately over time. Putting arbitrary one-size-fits-all rules in place is almost never the answer.

Unfortunately, in some (many?) companies there simply aren't enough experienced engineers who have the time to do the active balancing...leading us back to "just stick this rule in pipeline so the teams are held to _some standard_".

Agreed. I like to do these scans but for informational purposes, not as a gate. Also most tools allow you to annotate code to turn off warnings, which can help when used intelligently.

Of course some teams will over use such tools and turn off the metrics left and right.

In the end there is no substitute for experienced engineers.

I think that's the joke behind FizzBuzz Enterprise Edition, where FizzBuzz is implemented with rigid adherence to Java-encouraged abstractions:

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

Reply on news.ycombinator.com