Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Code Is CRAP (2011)

testing.googleblog.com

Post reply on HN
Print view View original

31–40 of 55 posts

Re: This Code Is CRAP (2011)

#31

Post by eadler »

bunderbunder wrote: post #20
richardbarosky wrote: post #6

The pendulum has swung too far in the direction of class, function, cyclomatic complexity (and here, CRAP) and similar idiotic metrics. This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved. The cyclomatic complexity metric is touted at each s…

A while back Hillel Wayne did a talk (whose name I forget) on what empirical evidence on software quality actually says. As I recall, he concluded that there’s really no support for then-popular ideas like short functions, reducing cyclomatic complexity, avoiding explicit branch statements and loops, or TDD. (Tests yes, just not TDD.) He made a pretty strong case that only two principles are particularly robust. One…

This talk.

What We Know We Don’t Know • Hillel Wayne. (2019, April 28). Hillel Wayne. https://www.hillelwayne.com/talks/what-we-know-we-dont-know/

Re: This Code Is CRAP (2011)

#33

Post by bluGill »

A measure is only good if I take action on it and in turn make things better. There are a lot of things that are easy to measure, but there is no useful action I should take on the measure.

Re: This Code Is CRAP (2011)

#34

Post by bunderbunder »

almondfestival wrote: post #25

I'm sure this method has evolved and/or been supplanted over the last 15 years, but one thing that struck me reading this is how much the dynamics of unit test coverage have changed in recent history, with AI-generated commits containing 10x as many unit tests (many of them kind of silly and tautological) as in the olden days. Gonna need to update some of those coefficients in their CRAP1 formula... Or maybe test cov…

Anecdotally, I’ve found that codebases that enforce code coverage metrics often have worse behavior coverage than ones that don’t.

It’s a classic example of Goodhart’s Law in action. Code coverage metrics only measure what percentage of code the test suite causes to run. But it’s very, very easy to write tests that run code without actually confirming that it produces correct output for all possible inputs. And it’s very, very easy to assume that a module with 90+% code coverage also has 90+% behavior coverage, and then become complacent about reviewing the suite for proper behavior coverage.

Re: This Code Is CRAP (2011)

#35

Post by octantes »

Anonyneko wrote: post #7

>Note: This post is rated PG-13 for use of a mild expletive. If you are likely to be offended by the repeated use a word commonly heard in elementary school playgrounds, please don’t read any further. Mild as this ironic passive aggressiveness is, can't imagine something like this in modern sterile corporate messaging.

don't be evil!

every bit of humanity went with the motto

Re: This Code Is CRAP (2011)

#36

Post by Jtsummers »

GranPC wrote: post #16
badc0ffee wrote: post #15

Earlier quoted context omitted.

This title normalizer is crap.

In its (admittedly weak) defense, if the submitter edits the title back during the few-minute window after submitting where this is possible, the normalizer does not kick back in. But it is a bit opaque, in the sense that the poster needs to: realize that the title has been changed; know that they can edit the title (but not too slow!); and know that it won't be filtered through again. I have no idea what the website…

You get an hour or so to edit the title. There is ample time to fix it if the auto-edits mangle it. The submitter just has to look at the submission after hitting submit one time to see if there was a problem.

Re: This Code Is CRAP (2011)

#38

Post by bunderbunder »

bluGill wrote: post #33

A measure is only good if I take action on it and in turn make things better. There are a lot of things that are easy to measure, but there is no useful action I should take on the measure.

Yes, but also all too often “useful” is interpreted to mean “moves the metric”. If that metric is merely a proxy for some more tangible outcome then that may not be good enough.

The one that tech tends to stumble on most often is velocity-type metrics. The problem there is that you can’t pay the bills with velocity. And velocity metrics tend to favor cheap shovelware features that cohere poorly over anything that involves having the team slow down on churning out code long enough to work out elegant solutions to subtle problems.

Re: This Code Is CRAP (2011)

#39

Post by kps »

richardbarosky wrote: post #6

The pendulum has swung too far in the direction of class, function, cyclomatic complexity (and here, CRAP) and similar idiotic metrics. This reminds me of a talk Sandi Metz did called "All the Little Things" where she covers the Gilded Rose kata. In the talk, she reworks her solution until there's almost nothing left showing the essence of the problem being solved. The cyclomatic complexity metric is touted at each s…

> it doesn't account for the control flow indirection that happens through OO method dispatch itself

Every indirect call is a conditional branch, where the condition can be arbitrarily far away in time and space.

Post reply on HN