You've totally missed the point of his post. You're talking about Scott Hanselman here, he does understand all that.
"Is this a speed problem? Are we feeling we have to develop too fast and loose? Is it a quality issue? Have we forgotten the art and science of Software QA? Is it a people problem? Are folks just not passionate about their software enough to fix it? I think it's all of the above. We need to care and we need the collective will to fix it."
I.e, he attributes things to lack of: care, passionate people, the forgotten art and science of QA, etc. Which is BS. There will ALWAYS be many bugs and problems in systems that large in scope and complexity.
And it's not because "the guys that designed, say, GMail or FCP (that he complains about) do not care, or lack passion, or have forgotten the "art and science" of software QA.
Plus, the kind of bugs he describes are not that important compared to what we have actually achieved and DOES work.
FCP crashing when you "scroll too fast" while rendering?
Give me a break, these linear editing systems cost tens of millions of dollars, took half a room, and didn't operate in real time just 15 years ago. Oh, and had just as many bugs, and you needed support staff from Avid or whatever to come over to set them up. Now thousands of people all over the world edit their films and documentaries in their laptops.
Plus, the kind of bugs he describes are not that important compared to
what we have actually achieved and DOES work.
That's a lame excuse. Who cares that we are better than 15 years ago, the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases and that nobody cares enough to fix, because "bah, it's not that important."
The problem is not that the bugs exist, but how fast and how well they are being solved.
Well, this is my other pet peeve, people not understanding the notion of "opportunity cost".
>the point is that we have lots of (seemingly) low-hanging fruit that stays there for plenty of releases
The key word here is "seemingly".
Do you really think that the guys as Apple/Google that pull all-nighters and work themselves to death to finish iOS/Android don't have "enough passion to fix problems"?
Or do you believe that if they took their sweet time they would have fixed every "low hanging fruit"? Even a low hanging fruit can add a couple of days to a month to a project, or delay other, more important features and/or fixes.
"Go attack all the low hanging fruits" is a meaningless proposition. Some projects you use are open source. Why don't YOU go attack them? Who is gonna make those "low hanging fruit" interesting for a volunteer to work? Who is gonna make them profitable for a for profit company, so that it doesn't die in the market while fixing them?
Mozilla tried to build a better browser. They addressed all the low and high hanging fruits.
What happened?
It took them 5 years to ship something that worked kinda OK, by which time the company had died, and the market share went to IE. And even those releases 5 years after the new code started had lots of problems. Eventually they betted on the more minimal Firefox instead of ever perfecting the full blown Mozilla browser/suite. And it's still not perfect.
Result? Besides the parent company dying, they haven't got that old high Netscape market share back even now.
>Who cares that we are better than 15 years ago
I, for one, do.
Do you really think that the guys as Apple/Google that pull
all-nighters and work themselves to death to finish
iOS/Android don't have "enough passion to fix problems"?
Who is gonna make those "low hanging fruit" interesting for a volunteer to work?
The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
It's just using past progress to justify current mediocrity. We should accept that those bugs that affect UX are indeed very important, and not dismiss them.
Have you even thought how much better things would be if people actually gave this a higher priority?
About Mozilla, there are lots of things that went wrong, and not many of them were due to fixing UX annoying bugs.
Who defines it? The business. Opportunity cost is a business notion (even if that business is making a non for profit OS software).
>The pride on creating a mighty fine piece of software should do it. I actually DO try to attack all the user facing (annoying) bugs on my projects, always. I may or may not be successful at that, but I'll never use "we are much better than 15 years ago" as an excuse.
So you "may not be successful at that". So why don't you stop 100% whatever else you're doing until you are successful 100% at that?
Because, obviously, you also need/want to do other things that you consider more important.
What I'm saying is: give the same courtesy to the makers of software you use.
>The bottom line is that I feel it's disrespectful to a user to tell him to put up with the annoying "life-wasting five minutes at a time" bugs, only because 60 years ago he would have been playing cards over candlelight instead of trying to sync his iTunes library.
Actually I find that the user throwing a fit is immature and disrespectful to what he is offered.
And you can see that sense of entitlement all too often in OS projects: "your software doesn't do X, or has the Y bug, it is crap, etc".
There are programmers that want to fix bugs, and programmers that just don't care. But it's not like the "just don't care" is somehow the prevalent attitude, or that bugs that are not fixed don't have a reason behind them not getting fixed (even if it is the simple: "didn't get to it, yet").
Neither are all those bugs "simple UX bugs" as you seem to imply, meaning that they have no backend or deep dependencies, or are trivial to fix. The bugs the article describes for example are syncing bugs, or bugs in working with video streams a non linear video editor. Those can be very complex and subtle, and may not even appear except in some very specific setups.
>It's like starting to pierce people with a pin and when they complain say "be grateful this is not the medieval times, because the pin would be a broadsword and you'd be already dead."
No it's not like that at all. For one, in this example you compare small pain now to bigger pain in the past. But what people get now is much more features (with some bugs), compared to less features in the past (with some bugs). So, if anything, it's exactly the opposite.
I do think that "don't care about UX bugs" is a prevalent attitude among software developers. I may be mistaken, but let's not forget you even used it as an argument: "those bugs are not that important", which is what compelled me to reply.
I believe that death by a thousand cuts is worse than death by a single blow, each time these bugs occur make a little cut.
And of course some of them might be devilishly complex or E_NOREPRODUCE, but I believe they are pervasive mostly due to the industry being focused on having more features before stabilizing old ones, because, you know, those bugs aren't that important.
(Hint: Multiply 5 minutes wasted by an annoying bug by 12000000 users and you have a million hours down the drain, each time)