One of the many reasons leadership needs to change, they are now more aggressive towards exploiting their customers, especially in cloud, Kurain is ruining that platform, but the investors like it

Wow! Did not expect this blast from the past this morning. I worked with Alberto and Bob at the same startup long ago. Hello to any other Agitators who found this today.

(2011)

Neutering Popular Science clickbait titles like “This Koala has a Secret Trick!”

It's more of a gut feeling than anything else. I don't know what the normalization rules are, but I think we mostly notice the normalizer when it mangles something [1], and not when it's just quietly humming along. Someone with more spare time could probably figure out a dataset of original to normalized titles and measure that.

[1]: Example from the frontpage right now: "How Big Are Factorials?" probably got normalized to "Big Are Factorials?" originally, based off other previous manglings I have seen previously.

Maybe it's invisible when it works as intended, but the only times I notice a title has been changed, is when it's changed back to the original title, stripping most of the valuable context in the process. De-editorialization, I suppose.

(Or when the auto-renamer does a funny!)

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.

While that might be the case, best to normalize that: Title Normalizers are Crap.

Submitters can rectify the title after submitting.

Isn't that what this title is? Which part is editorialized?

The thing is, AI has no idea when an abstraction is good or not.

The reductio ad absurdum here is that, if abstraction can just be assumed to be bad for quality and maintainability, then perhaps we should go back to hand writing machine code for non-microcoded sequential execution CPU architectures. Conversely, if that idea sounds as preposterous to you as it does to me, then you’re stuck conceding that at least some abstractions are mostly good. So then, before you can automate deciding which ones should and should not count against a code quality metric that’s computed automatically, you need to find an operational definition that can be applied deterministically.

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/

cyclomatic complexity metric is touted at each step as a proxy for goodness of design and removal of complexity. However, a weakness of the measure itself

Amen, it’s hard to push back against an opaque term (cyclomatic!) when it isn’t really a measure of goodness, it’s a measure of branching, kind of a normal thing in code.

Early on I found that code with low cyclomatic complexity was just usually extremely verbose, lots of passing this to that while avoiding the branching necessary to get something done.

And yes, you can game the metric by hiding the complexity among the confusion of objects and components.

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.

"repeated use" seems to be doing the mitigation work here, though it does seem unusual that someone offended by the repetition would be unoffended by a one-off.

There's a good chance it'll be scrubbed now that it's frontpaged here

don't be evil!

every bit of humanity went with the motto

CRAP1(m) = comp(m)^2 * (1 – cov(m)/100)^3 + comp(m)

and

Here’s why we think that CRAP1 is a good anti-pattern to detect. Writing automated tests (e.g., using JUnit) for complex and convoluted code is particularly challenging, so crappy code usually comes with few, if any, automated tests.

This is so wrong.

The formula uses code coverage as a fundamental metric, when in reality, a lot of people write code "correct from construction", so coverage is not even applicable. Many times too, people only care the use cases they care about work perfectly.

There are also many other reasons code is not tested, not because it's complex, but because it's simple.

I have a goal to make the codebase at work cargo-crap compliant and enforce it with CI. I let an agent run overnight with it once and the diff touched like 40% of our codebase which is untenable for a single merge. So for now I’m doing it piecemeal as the opportunity presents itself.

No, we were writing them in 2011.

Or maybe test coverage has/will become too noisy a parameter to use at all.

It already is, ive banned unit tests via ci checks from our codebases, they were not particularly useful before LLMs and now they are a net negative.

We require int and some e2es and that does all that units do and more.

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.

Every time I see a software update I cringe inside.

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.

I've seen a couple of tools to calculate the CRAP score. I haven't used them in anger though.

For Rust there's https://crates.io/crates/cargo-crap, and for Go there's https://padiazg.github.io/go-crap/

When a measurement becomes a target, it ceases to be a good measure.