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

121–130 of 137 posts

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

#121

Post by rantanplan »

marcosdumay wrote: post #117
rantanplan wrote: post #116

Earlier quoted context omitted.

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, b…

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

Not really. I see quite the opposite; during the design phase the team sets the rules in order to guarantee consistency and cohesiveness and avoid any deviation from what has been agreed upon. This rules out personal or whimsical contributions, because by definition it would ruin the process.

> Anyway, it's not like you can avoid giving your software a personality. You can't.

I alluded to that, if you re-read my comment, but a software having its unintended whims, compared to intentionally trying to give it some "personality" is not the same thing at all.

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

#122

Post by [deleted] »

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…

[deleted]

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

#123

Post by Xorlev »

QuinnyPig wrote: post #33
donavanm wrote: post #19

I'm a principal at AWS and spent years dealing with this on CloudFront and Route 53. A lot right, and a little off, in the post. Yes, we should definitely communicate to the viewer what's happened and appropriate next steps if any. But there are a handful of challenges that Ive not seen reasonably solved. The first problem is that different viewers need different context, which is especially true for service provider…

Very true, at the individual error level. That said, Fastly fixed the entire issue in less time than it would have taken AWS to update the status page to the blue diamond, so there’s that.

In large organizations, status boards are "external communications" and this must be handled by a team dedicated to that. It works about as well as you might expect.

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

#124

Post by sbadger »

More in reply to the comments than the original article.... In my experience no developer ever actually imagines that their code could possibly have bugs. Yes yes, they will say that of course all software has bugs, but deep down they know that that doesn't mean their code, just other's code. Turn all that code into products and that means when something goes wrong it isn't the product's fault. Therefore it must be the user's fault.

Error messages can't possibly explain the problem, because the product can't know what the dumb user did. So don't bother really trying.

This from the perspective of someone doing customer support.

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

#125

Post by eecc »

system2 wrote: post #94
eecc wrote: post #92

Wow, the internet. It’s like my meetings where everyone feels entitled to expressing their opinion, splitting hairs on the most tangential aspects of the issue. Thanks god for coffee, and nice views out of the window

10 of our clients called and asked why they are paying us if the sites are not working today. I think a proper 503 browser message could help us a little?

Uh, really? I bet Prometheus would do a better job

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

#127

Post by IshKebab »

chakkepolja wrote: post #81
IshKebab wrote: post #78

Earlier quoted context omitted.

Also, consumers may not understand backtraces but they generally understand how to Google them or ask other people what they mean, or tell you about them. Technical errors are way better than just "I'm sorry we couldn't process that right now."

This is probably a dumb question, but isn't a backtrace likely to reveal some sensitive information from a security perspective?

Possibly, though I would say that is a little paranoid.

But anyway I was really using "backtrace" as a synonym for "technical details that users don't understand". Not very clear, sorry!

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

#128

Post by marcosdumay »

rantanplan wrote: post #121
marcosdumay wrote: post #117

Earlier quoted context omitted.

> 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, b…

> Are you aware that those things go through a design phase with the explicit objective of giving them a personality, right? Not really. I see quite the opposite; during the design phase the team sets the rules in order to guarantee consistency and cohesiveness and avoid any deviation from what has been agreed upon. This rules out personal or whimsical contributions, because by definition it would ruin the process. >…

Teams? Rules?

The bridge architects you are talking about behave very differently from the ones I've met.

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

#129

Post by jandrese »

cerved wrote: post #100
jandrese wrote: post #64

Earlier quoted context omitted.

> Showing the error itself only opens the provider to information disclosure No offence but as an end user I really despise this attitude. Sure there might be automatic monitoring at a place like fastly, but even they can use help in tracking down the problem. Also, if the error is distinct people can put it into Google and call on the vast power on the Internet to help figure out how to fix it or work around it, esp…

It's a matter of information security. Error messages potentially disclose sensitive information on the internal workings of the service. Disclosing that information is a potential security vulnerability. Also note that SE went down yesterday

I would counter that your service is not as special as your security guys think it is. The paranoia over "Oh no! Those dastardly hackers will discover that we use PostgreSQL on our backend! Our secret sauce will be spread all across the Internet!" is usually overblown.

Obviously this does require your developers not to be complete idiots by putting their passwords in the error messages or something, but this is an extremely easy bar to hurdle.

At the very least you can put an error code up. Just make sure it is a reasonably long string so you don't have collisions. If you are big enough people will work out what the codes mean and what they can do. For example, I know 0x80D02017 on Windows means Microsoft has broken their IPv6 service endpoint for the Windows Store again, and you can temporary disable IPv6 support to work around it. Even though the error message is the monumentally unhelpful "Unknown", the Internet can come to the rescue. Of course if the error message had been something like "Windows Store update connection to address 2603:1061::9f4d failed: Service responded with protocol version 4, this client only supports version 5" it would have been even better.

Would it disclose data about how Microsoft internals? Maybe a little, but most of that was observable anyway and maybe if you had error messages like this maybe it wouldn't take them 8 goddamn months to find and fix the problem?

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

#130

Post by iudqnolq »

aniforprez wrote: post #10

Reminds me of the quintessential tweet about error messages https://twitter.com/cherrikissu/status/972524442600558594?s=...

Relatedly when I opened that link I got "something went wrong. Try reloading" when I opened that. I happen to know that's usually rate limiting with twitter (since Firefox is suspicious, maybe?) so reloading is exactly the wrong thing to do, but switching between the mobile and desktop sites seems to work (maybe they have different quotas?).
Post reply on HN