Hacker News Reader

Comment by jrockway | Hacker News Reader

I have always found this to be a weird take from a forum largely populated by software people. Every piece of software I have ever used has been riddled with bugs and security defects. This despite the fact that we have dedicated sub-fields for both (security engineering / test engineering). So when a journalist notices a bug in their article and has to "retract a release", how is that not what we do every single day?

I think you might just be disappointed in humanity, rather than any particular agency or person. Humans come together to get the right answer eventually; not multiple times a day, every day, without fail. Sometimes the software doesn't do what you want. Sometimes that article has a factual error. Eventually we figure it out. It's not the end of the world.

View on HN

In this case, it's probably justified to have gripes with the editors.

They got an opinion piece with an extraordinary claim about something the writer saw in a slide presented at a trial. She wrote the entire article about it creating theories and then how it needs to be stopped. Not to mention, she had previously worked with a competitive search engine. The central piece of fact checking was seeing that slide, that would have been the second question after "Are you sure you saw something like that?". The entire article hinges on that one slide she saw and what she understood from it.

This is not a case of missing a boundary condition. This is missing the central premise. At any level, it would be inexcusable.

PS: In a sense, as the artifacts are becoming public, i think more such confusions would surface in the coming weeks where merely misunderstanding what is on the slide would lead to a lot of rumors. Probably best we have an initial case and some intuition that this can happen.

I don't think you should derive a universal QA standard from specific release practices borne out of a specific risk/reward situation that depends on things like your particular business model or lack thereof.

There's a wide spectrum of how fucked your software can be when you release it without it being a huge deal, like if I push a broken release for my hypothetical build system that jumbles the error messages a little that's probably fine, if I push a broken build of the google dot com landing page that's raising a few more sirens and I really shouldn't make a habit of it, if I deploy critically broken firmware to your pacemaker or your crewed rocket ship I should probably be exiled from the field. I imagine there's a similar spectrum for journalists and we can't really figure out where on the spectrum to the article from the OP should be with just analogies to a different field. Complaining about a trend of publications slipping towards the yolo'ier end of the spectrum doesn't seem on its face hypocritical.

It's also an understandable mistake. The slide the GP mentioned doesn't provide a clear explanation and can be interpreted the way the original article did. It's no wonder multiple people didn't catch the mistake.

An article should not be published based on one person's interpretation of one slide. Basic journalistic standards would require having other sources that corroborated what the writer thought the slide meant.

It'd be an understandable mistake, for a non proficient English speaker.

Isn't one of the key elements of ethical journalism that you need to ask the subject of your article for comments? I have a hard time believing they asked Google to comment on this piece and didn't get "that is categorically false and if you publish it you will be hearing from out attorney" as an answer. So I don't really see how this one got through unless they didn't ask for comments.

This would be like the SWE equivalent of pushing to production without code review. It's not an excusable mistake like when a bug gets through.

I don't know about "need", but it's certainly common to reach out to them... But that doesn't mean that they respond quickly. Google does not have a rep for reliably getting back to people quickly or even at all, and when they do get back to people, they very often just say they can't comment, because there's no way for the people handling the press contact to reach a person who would know what was going on in a predictable manner. (Yeah, that sounds stupid. It is. And yet, nonetheless, you can regularly find that no one at Google can figure out who owns something or knows why it's the way it is.)

A difference being software engineering is a laughingstock no one expects much of, while worldclass publishing has a past excellence against which it's still frequently judged.

I also misunderstood the point—but if I now read correctly—it’s that to err is human, and something that we do as software developers constantly

People expect their software to work perfectly nearly all of the time. And for the most part, it does. So not really sure who you think these people are who think it's a laughingstock.

We also have the notion that fixing bugs at design time is easier than in dev, which is in turn easier than in prod.

Publications can simultaneously be praised for “rolling back a bad build” while being criticised for letting that build roll out to prod in the first place.

Journalists suck. They pretend to be bearers of the truth, and yet go forth with horribly biased and inaccurate claims. Nothing like software which does not wield anywhere close to the same cultural power to control narratives as the news media.

The same way we expect "QA" to pick up those bugs before release?

Think about the opposite. Imagine we pickup a bug in a live application and update it citing "our QA standards". This magical word does not absolve us of the fact that we let a bug through to production. And it's implied that we'll do better next time to pick up this kind of bug.

The post you are responding to is making the point that even though we have QA, dedicated jobs or even departments for these things … We, as a profession, still fail in releasing bug-free software. And that’s 100% correct.

Is that really something you are challenging? Which pieces of popular software you can think of are bug-free? And are you thinking of more than a handful?

They said "So when a journalist notices a bug in their article and has to "retract a release", how is that not what we do every single day?"

And they themselves were responding to someone criticizing media for using "editorial standards" as an excuse when they "retract a release".

And I explained how we are the same and supposedly strive to not release bad content/software, we just don't get to magically absolve fault with an excuse that "it doesn't meet our QA standards" as an analogy to "editorial standards".

Anywho, the whole thing breaks down when we have to beat it with a stick. It's a discussion, assume a charitable interpretation.

Retracting an article due to "editorial standards" is, to extend your analogy, like attributing the need for an emergency hotfix to "QA practices".

Editorial standards should stop bad stories from being published. Saying "we retracted this story because it doesn't meet our editorial standards" begs the question "why are you publishing things that don't meet your editorial standards in the first place?"

It doesn't take responsibility for or explain the mistakes in the article. It doesn't state that the article had factual errors. It's a frustrating cop-out. I sincerely hope this is a temporary measure while Wired gets a more comprehensive retraction put together.

Reply on news.ycombinator.com