Hacker News new | past | comments | ask | show | jobs | submit login
Errors are constructed, not discovered (ferd.ca)
36 points by Tomte on April 15, 2022 | hide | past | favorite | 11 comments



This story makes me see a pattern in this author's writing: While looking at the world, they see that something is off, that something is not as one would to be expected, accurately points it out the dissonance, and then draws really weird conclusions that do not seem conclusive to me.

Yes, errors are not objective, but they aren't constructed, either. Our expectations are constructed (docs and standards likewise), and the mismatch to it (the error) is something objective that can be discovered.

Really odd framing...


It's "looking for an angle" for self promotion, instead of looking for truth. "X is not what everyone knows X is" is a fount of comtrarian hypotheses for attention seekers.


This explains many things! Your comment bought me forward.


To illustrate the point, let's imagine that 5 years ago, a driver in the linux kernel was written in such a way that interplay with a new disk drive could corrupt data when power failed. The disk on its own (and with other OSes) is fine, and the linux kernel in all other cases are fine.

An open-source database is being used and operated as a service by a vendor, which a SaaS company relies on to provide a feature that your organization uses to manage data on behalf of users.

We now have a chain that includes: users <- customer organisation <- SaaS vendor <- DB as a service vendor <- OSS DB maintainers <- Linux maintainers <- Driver writers <- Hardware vendors.

There is suddenly a power outage at the DB as a service vendor (because of an unmaintained powerline falling over) and their UPCs appear not to be functional for yet unknown reason (cost cutting or supply chain issues during covid time may receive some blame). Your users lose their data regardless.

What is the bug? Who is at fault? Is it the engineer? The team who wrote the code? The QA folks? The organization that hired them? Who should fix the issue? Who should be on charge with repairing data corruption? Whose backups should be trusted most? The least? Have you been lenient in your usage of a SaaS vendor? Has the SaaS vendor been lenient in the services they use? Which actors can be considered liable from a legal standpoint? Which actors can be considered liable from an ethical or moral standpoint? Are your customers the one who made a bad decision contracting you? Can there be more than one party responsible? Do any of these answers changed based on whether the power loss is caused by an act of god or bad maintenance? Based on which jurisdiction you're in? How do you define honest mistakes? Negligence? A bug is a bug because the software did not meet the expectations that were set. Were the expectations reasonable? Who should have managed them?

Events happen. The meaning we attach to them is of course based on expectations and standards and the environment and context, but the way we build our explanation, the ways we attach blame and accountability varies. You can sometimes decide to assign accountability to individuals, sometimes to systems, sometimes both. Sometimes only some or sometimes neither.

So sure, you can point at the actual technical lines of code and say "these aren't doing what they should", but if you do this in a vacuum without also wondering who decided what these lines should be doing and what pressures were at play when they were written, are you necessarily learning a lot about how events unfold and how they might unfold in the future?

A systemic perspective will yield different reactions than one based on personal engineer responsibility, which will be different from one that looks at it from an insurer's point of view, which will be different from one which looks at it from an education point of view, etc. So the lens you take to look at the events surrounding the error and the interpretation you make of it are absolutely crucial to the corrections and learnings that follow.


Nothing you wrote is about errors in itself, you exclusively talk about the social interpretations/construction of it. These are things that every adult needs to be able to improvise and express on-the-fly, nothing 'static' that could be fruitfully discussed independently of specific occurrences.

Late edit: So, when interpreted in my context, its utter crap! Your article is shit! You explicitly invited your readers to disregard cross-checking against your own intentions[1], saying they "don't matter". Its basically a free card for me to project my prejudices onto you, without you having anything to conter it. You are a fragile individual who does not think things through.

[1] https://ferd.ca/inclusiveness-in-language-for-outsiders-look..., Section "Death of the Author"


So this disagreement is an interesting example of error being a construction in itself: I will posit that you are wrong or not interpreting my point of view properly, and you will say that I am wrong or possibly not explaining things properly.

There is an objectively quantifiable disagreement. But its nature (and even whether it is desirable or not) are possibly camped in subjective terms. Of course you could argue that I am objectively wrong — though trying to prove that with my own writings is risky since we’ve established I’m not a trustworthy source — but that in itself does not resolve the overall disagreement from existing.

This sort of situation can also happen in software where an ambiguous specification yields two distinct compliant implementations that nevertheless do not work together.


This doesn't seem mysterious or confusing to me. What happened wasn't the launch of a new random power outage feature - it was a problem that needs to be fixed.


Fixing the bug does not necessarily fix anything else it caused though, and none of the questions in my post are answered by “fix it”.

Here’s another one: should the incident actually have an impact on anyone of the companies employees yearly reviews? Either positive or negative? Why?


It seems like you're conflating blame with bugs.


Well if all you have is bugs but you never look into how they get there and how they happen, you’re not going to improve your process or tools much.

Also blame and accountability and responsibility are all subtly different.


Yours os is a pos




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: