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

What the Fastly outage can teach us about writing error messages

onlineornot.com

Post reply on HN
Print view View original

111–120 of 137 posts

Re: What the Fastly outage can teach us about writing error messages

#111

Post by sschueller »

aembleton wrote: post #105
sschueller wrote: post #76

Earlier quoted context omitted.

If we keep dumbing down the world for everyone instead of teaching those who don't know we will destroy ourselves. People are not stupid and if we keep assuming it we are doing a disservice to all. No more www, no more protocol in the address bar and apple is selling iMac colors in it's commercials...

How will it destroy us? Do you think we should use hex or binary instead of their ASCII or UTF-8 equivalents? After-all, ASCII must be dumbing down as it makes it easier for non specialists to read.

I am not saying that there shouldn't be some abstraction. However I think we are at a point where one additional customer at any cost results in products become so simplistic that they become useless for people who actually need them for work etc.

Not having people learning new things and learning to approach things with some logic results in them never having to do this in their lives. In the end you get a dumbed down public voting on their emotions and against their interests.

Re: What the Fastly outage can teach us about writing error messages

#112

Post by phkamp »

I created that particular error-message in varnish cache 15 years ago.

Max has many good points about error messages in general, but all of them require access to out of band information.

We in the Varnish Cache Project do not have access to that information, we dont know who runs the varnish instance or what kind of information they serve to what kind of clients.

This is why the default '503 message only exposes the "XID" nonce: That allows the administrator of this cache instance to find all the details in the log files.

Varnish Cache users who want to present something else can do that from VCL, and I'm pretty sure Fastly normally does.

But when all else fails, and here it must have, Varnish Cache errs on the side of caution.

Re: What the Fastly outage can teach us about writing error messages

#114

Post by tester34 »

bullen wrote: post #86
karlerss wrote: post #82

Earlier quoted context omitted.

This is considered a critical security vulnerability. [0] [0] https://owasp.org/www-project-top-ten/2017/A6_2017-Security_...

Not if it's open-source. Security by obfuscation is generally not a good option if you can avoid it.

>Security by obfuscation is generally not a good option if you can avoid it.

Of course, but obscurity increases security

Re: What the Fastly outage can teach us about writing error messages

#115

Post by phkamp »

phkamp wrote: post #112

I created that particular error-message in varnish cache 15 years ago. Max has many good points about error messages in general, but all of them require access to out of band information. We in the Varnish Cache Project do not have access to that information, we dont know who runs the varnish instance or what kind of information they serve to what kind of clients. This is why the default '503 message only exposes the…

I've taken the opportunity to write up the story of the first time Varnish Cache's 503 was heard around the world, or at least in Norway:

http://varnish-cache.org/docs/trunk/phk/503aroundtheworld.ht...

Re: What the Fastly outage can teach us about writing error messages

#116

Post by rantanplan »

manuelmoreale wrote: post #102
rantanplan wrote: post #101

Earlier quoted context omitted.

> Software is a highly personal and creative thing, it should have a personality Not it isn't and it shouldn't. The process of creating the software is; huge distinction. The product of your efforts should not have a personality or feel personal, it should just work as intended. Software is hard as it is and we don't need to make it more whimsical. A little experience can teach us, that whether we like or not, it wil…

> The product of your efforts should not have a personality or feel personal, it should just work as intended. Genuine question: why it can't have both? I know it's hard to convey tone on the web but I'm asking the question because I'm genuinely interested in knowing what you think. I personally think you can create software the right way, ship something that works and still incorporate some personality and make it l…

Because we haven't solved the main problem yet, which is to create robust software that does exactly what's supposed to do, no more no less. We have opinions, we have some indications of what may improve software development, but we are far away from comparing software engineering with other engineering domains. And it's only logical, because compared to other disciplines, software engineering is in its first baby steps.

Imagine if construction/aviation/etc engineers wanted their building/bridge/airplane to be whimsical and have its own personality. Are you scared yet?

Imagine if your out-of-band(not in the initial requirements/spec) and whimsical software contribution was responsible for a bug that brought down an airplane, or killed a patient. How whimsical would you be then? Well at least you wouldn't feel bored at your day job right? Anyway, I think you get my point.

Re: What the Fastly outage can teach us about writing error messages

#117

Post by marcosdumay »

rantanplan wrote: post #116
manuelmoreale wrote: post #102

Earlier quoted context omitted.

> The product of your efforts should not have a personality or feel personal, it should just work as intended. Genuine question: why it can't have both? I know it's hard to convey tone on the web but I'm asking the question because I'm genuinely interested in knowing what you think. I personally think you can create software the right way, ship something that works and still incorporate some personality and make it l…

Because we haven't solved the main problem yet, which is to create robust software that does exactly what's supposed to do, no more no less. We have opinions, we have some indications of what may improve software development, but we are far away from comparing software engineering with other engineering domains. And it's only logical, because compared to other disciplines, software engineering is in its first baby st…

> Imagine if construction/aviation/etc engineers wanted their building/bridge/airplane to be whimsical and have its own personality. Are you scared yet?

Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right?

Mechanical engineers have an habit of breaking that personality due to their profession constraints, so most airplanes lose the original ones, but bridges usually are built just as intended.

Anyway, it's not like you can avoid giving your software a personality. You can't. What you can decide is if it will behave like a dull humorless thing, a holier than you all knowing braggart, or something people like having around. And yes, some software should have those two first options too, it depends on their application.

Re: What the Fastly outage can teach us about writing error messages

#118

Post by userbinator »

Clewza313 wrote: post #44
anigbrowl wrote: post #29

I have a particular dislike for Apple over this - I think they set a trend of unhelpful error messages tied to obscure codes back in the 1990s. Sadly they've been joined by Google. 'Something went wrong' could have come from the Sirius Cybernetics Corporation.

Obscure but unique and googlable error codes are great. At a previous job, we had a large project to go through the codebase and tag every single user facing error with one, then publicly document them with likely causes and solutions. Support volume dipped noticeably.

Google is unfortunately getting worse for such things. Search for some error code and you get pages of spam and those that don't contain the code you're looking for, but a "very similar" one. Even one digit off makes a huge difference.

Re: What the Fastly outage can teach us about writing error messages

#119

Post by jmrm »

vort3 wrote: post #103
calvinmorrison wrote: post #20

Earlier quoted context omitted.

Right up there with Slack etcs fake loading messages "Gearing up the dildonator" "Implicating the fairies" "Hogtying George Bush" Dude - just give me a spinner or a progress bar, and if something errors during the load out give me some sort of stack trace or error ID I can use to help

Once I was at /r/androidapps and someone made a new app, asked for feedback, and «experienced devs» told OP something like «instead of „fetching data“ you should be using „getting everything ready“ because it might scare users to think that app is collecting their data». Are people really that dumb? I'm afraid to use apps made by those people.

We have to remember the median phone user isn't usually tech savvy. Is an average Joe or Stacy who use that device with communicate with friends and family, use Facebook, watch Netflix, and buy from Amazon, and that isn't something bad. Just we have in mind that most people doesn't know tech-related terms and can confuse them.

Maybe if we want to be a bit funnier we will write "changing the break pads" in the loading screen, but in case of error we have to write something clearer, like "error accessing to the game server" or "error reading cars data files", to being able to solve the problem.

Re: What the Fastly outage can teach us about writing error messages

#120

Post by mirker »

hvocode wrote: post #3

I've had more than one intern or young engineer that I've had to teach to resist the urge to put witty comments and jokes in project docs, comments, or errors. Especially in error messages or things that can be exposed to users/customers. Even if it's an error you think only the dev team will see, you never know if it will make its way out to audiences you didn't intend. Somehow I doubt people faced with this error m…

Show interns this story: https://devblogs.microsoft.com/oldnewthing/20201110-00/?p=10...
Post reply on HN