Live data from Hacker News

Bug Blindness

danluu.com

81–90 of 263 posts

Re: Bug Blindness

#81

Unnecessarily long post. It could have been 4x shorter and conveyed the same message better.

I usually agree with this sentiment. I have a general disdain for elaborations and novelization. Get to the point! Give me the necessary facts and make it concise!

In this case for some reason, I disagree. This post is engaging for me. I sometimes elaborate on how I came to a conclusion because that journey is equally as fascinating as the conclusion itself. While reading this authors post I was happy to see what seems like a very thorough thought process.

It was actually refreshing for me to see someone write at such length and find myself engaged.

It worked for me.

Now, putting my self in your shoes, as I have regularly had the same opinion, I have more empathy and understanding for how people consume and enjoy writing.

The world is fascinating.

Re: Bug Blindness

#82
Some developers treat their software like a baby when they test it or show it to others. Tapping cleanly and slowly, giving animations time to finish, scrolling slow and smooth, etc.

I like to beat the shit out of my software when testing. Constant erratic scrolling and zooming, multi-touch shenanigans, pressing multiple buttons as fast as I can, using back gestures and the browser back button (if it's a web app), changing the window size and orientation frantically, and just all kinds of rough usage.

If your software can't cope with these things then you're doing a disservice to your users.

Re: Bug Blindness

#83

I’m really anal about the Quality of my own software, and tend to be hard on others’ software (doesn’t make me too popular). > I've had multiple jobs where directors/VPs/execs/etc. sometimes ask me to evaluate something when they want an actual opinion from someone who is relatively likely to notice issues (and fix them or drive fixes for them if necessary). I’ve had the experience where I need to be asked, and even…

I feel for you and I'm similar too. However, there's a fine line between what you are describing and "perfect is the enemy of the good". I've seen some who claim to be like you but in practice they are a net negative to everything because they can never agree to anything until it is perfect even when the perfect solution is beyond the capabilities and/or out of project scope/budget and/or take too long to implement ignoring business needs.

Re: Bug Blindness

#84
post #65

Earlier quoted context omitted.

> a common way for regular people to interact with a system is they just... don't have a model. None at all. Like, they click a thing and see what it does, and if it doesn't do what they expect they shrug and click something else. The horror of seeing a non-software person using a software system is realising that they usually cannot tell the difference between expected and unexpected behaviour, because they don't re…

I think I can see where you're coming from - and it is true that there are cases of dogmatism as a defense for just sucking at UX - but I violently disagree here. Good UX I believe doesn't mean that the implementation details are hidden, but conveyed in a way that is human-readable. You do not hide the machine from the man, but translate between them in a way that makes neither of them invisible. This makes for bette…

That's one of the things that surprised me (in a positive way) about Mac OS X when I first got to use it -- it actually does indeed do lots of things in an _understandable_ and genuinely simple way. It's also clear how much work went into making the system behave in this way, it certainly wasn't an accident.

In the era of web apps and Electronification of anything I believe most of this is sadly gone, but in the older Mac OS X models you could clearly understand and see the logic behind the software and I believe it worked well for non-technical people from what I observed.

Re: Bug Blindness

#85
From the article: “For well over a decade, the reliability data that exists (and I think this is backed up by the anecdotal experience that mechanics who work on Volvos have) is that Volvo reliability is mediocre to poor, but of course Volvo forums are full of people who insist that Volvos are among the most reliable cars and that the data are all wrong.”

The author mentions one explanation, which is that most people driving a Volvo won’t experience a breakdown (and then generalize from that). Another one is of a very different kind known as post-purchase cognitive dissonance (https://en.wikipedia.org/wiki/Cognitive_dissonance#Consumer_...).

Re: Bug Blindness

#86
I find the ad blindness and bug blindness similar but on opposite ends: I also notice bugs easily, but I also notice ads (instead of skimming — when ad blockers do not work or apply), yet I consciously make an effort to not be tricked and sometimes explicitly decide to not buy the product if the ad is obnoxious or really abuses the psychological findings for business' gain.

Re: Bug Blindness

#87
post #56

I had to give up when the first example of a "bug" that the author could see, which others are blind to, was search results. "In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see" Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, i…

At what point does search quality degrade to the point where is becomes a bug? A bug is when actual behavior does not match stated or intended behavior. If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned. Or maybe you mean to say we should reserve the word bug for deviations that are unintentional?

The trouble is, there are three different "versions" of "the search didn't work," only one of which I would say is definitely a bug:

- The thing the user searched for doesn't exist, so it wasn't found. This is not a bug.

- The user did a good job of searching, using relevant keywords etc, but the relevant thing (which exists) didn't come up. This is a bug.

- "Search didn't read my mind" -- if search is a core competency this is a bug, but otherwise I would consider it a deficiency or a missing feature.

Re: Bug Blindness

#88
post #56

I had to give up when the first example of a "bug" that the author could see, which others are blind to, was search results. "In some cases, people sent me their actual search results. In every such case, the search results did not contain a good result that I could see" Software that does not meet expectations, especially in a field like search, which is basically a long running war between SEO and search engines, i…

At what point does search quality degrade to the point where is becomes a bug? A bug is when actual behavior does not match stated or intended behavior. If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned. Or maybe you mean to say we should reserve the word bug for deviations that are unintentional?

For me the idea that poor quality search results are a bug muddies the idea of what a bug is. It's like saying the colour of the paint in my living room is buggy because I don't like it. It might be an ugly colour that I don't like, but it is what it is. A bug would be if the colour doesn't match what was shown on the tin.

> If the search bears little connection to what was searched for, then it is a bug, as far as the user is concerned.

A bad product perhaps, but not a bug.

Re: Bug Blindness

#89
An interesting version of this is when a team basically internalizes some issues in the software they work on and it turns into something they accept as a fact of life or even turn into a joke. „X failed again? Don’t bother, it’s been a shitshow for years.” What?!

A few years ago I started leading a team working on a product that had a lot of „legacy” quirks like that. It took me a good while to set a strong quality bar, both mentally and technically. I would frequently point out where the mindset was wrong, prioritize certain fixes over project work, fix a lot of issues myself, fight with other teams to fix their stuff, run silly contests such as „who solves the most support tickets this month gets a prize” and sometimes even „stop the world” for a few days until we got something in order.

Some people might be prone to think their team will never have the time to do that (and some may be right) but in my experience quality pays back. Often fixing a small bug takes about as long as discussing if it’s important, properly filing it in JIRA and then communicating to the outside world it’s not the priority. And eventually you reach a point where you have way more calm and focus than before because nothing is burning.

Re: Bug Blindness

#90

>I thought this had something to do with how I use computers but, over time, I've realized that it's mostly that people are hitting the same bugs and don't notice. I suspect I know why they do not notice. See below. >it works well, etc., but when I open up the thing and try it, it's in a state where the thing only works if you do quite a few non-intuitive workarounds. I suspect most people are so inept at navigating…

>I suspect most people are so inept at navigating UI because even a good UI is not intuitive to them. A bad UI is equally not intuitive. They do not know it is a bug because everything is a bug to them. This seems a weird thing to believe given that we know there are such things as black UI patterns designed to keep users from doing things they might want to do, but which the company might not want they do yet still…

>I just give up on because they don't realize that a thing should not be working the way it does, they think it is them that are wrong - as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development, which world I assume you are a part of?

I agree with, "They think it is them that are wrong", essentially. The end users that I deal with at the consumer level usually think they messed up when something does not do what they thought it was going to do.

>as evidently you do as well. I think it is frankly a strange viewpoint to have in the world of software development

Can you elaborate on this statement? I do not know whether you are agreeing with me and implying we are both strange or you are implying that I think that way and that is strange. Either way, I am not a developer, yet. I dabble in things.

Post reply on HN