3 ms·

Plus, the kind of bugs he describes are not that important compared to what we have actually achieved and DOES work. Bingo! This is one perfect example of t

by koide 14y ago

Plus, the kind of bugs he describes are not that important compared to what we have actually achieved and DOES work. Bingo! This is one perfect example of the problem he's referring to about people not being passionate enough to fix the problems: "Those bugs are not that important." 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.

batista 14y ago
>Bingo! This is one perfect example of the problem he's referring to about people not being passionate enough to fix the problems: "Those bugs are not that important." 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." 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.
- koide 14y ago
  The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken. 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"? Honestly, I believe their managers give new tasks the a higher priority and that there is a pervasive mentality among all the profession that these are "irrelevant" problems that everyone has become accustomed to put up with and, in addition, are boring to work on. Who is gonna make those "low hanging fruit" interesting for a volunteer to work? 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. And I'm certain you and I have both seen well designed and executed pieces of software, where care has been taken on the UX and have very few if any of these problems, so complexity isn't something that forces you to have annoying UX bugs. 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.
- batista 14y ago
  >The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken. 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.

by koide 14y ago

batista 14y ago

>Bingo! This is one perfect example of the problem he's referring to about people not being passionate enough to fix the problems: "Those bugs are not that important." 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." 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.

koide 14y ago
The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken. 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"? Honestly, I believe their managers give new tasks the a higher priority and that there is a pervasive mentality among all the profession that these are "irrelevant" problems that everyone has become accustomed to put up with and, in addition, are boring to work on. Who is gonna make those "low hanging fruit" interesting for a volunteer to work? 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. And I'm certain you and I have both seen well designed and executed pieces of software, where care has been taken on the UX and have very few if any of these problems, so complexity isn't something that forces you to have annoying UX bugs. 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.
batista 14y ago
>The key point is who defines what "opportunity" is and, most importantly, why. There are opportunities to build new features, or opportunities to fix what's broken. 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.