Comment by batista | Hacker News Reader

Comment by batista | Hacker News Reader

So, your amazing feat of engineering phone, with a color retina display, audio-video capabillity, 700.000 apps, gyroscope, HD cameras, etc has some extra stuff taking 3GB drive space (of the 16GB device).

Your amazing, multi million lines of code Windows desktop, the work of some 1000 people or more, has a problem with indexing.

The protocol and apps that connect you via email to everyone you want, free, globally and instantly, sometimes loses a mail. Or the UI is slow to load your new messages.

A program with which you can do on your laptop what it took huge teams, million dollars of equipment, and professional expertise to do (FCP), has a crashing bug in some particular action.

The program that lets you talk to everybody on the planet, instantly, with video, and paying nothing, has a badly designed UI.

etc...

Yes, I can see how "everything is broken".

Because, when we didn't have any of these, when 30 years before you had a rotating dial to dial numbers on your phone that only called landlines and cost mega bucks to call internationally, when you had MS-DOS as the most prevalent desktop OS, when 20MB was a huge disk in a desktop system, and before something like video chat was only possible in huge organizations with special software, everything was perfect...

Wanting to improve things? Fine.

Not understanding the complexity and magnitude of the technical achievements you use everyday? Bad.

So, your amazing feat of engineering car, with automatic transmission, ABS, a GPS, incredible fuel efficiency etc. stops in the middle of the highway sometimes.

Your incredible display, which somehow manages to use liquid crystals to display beautiful 1080 HD video develops a jitter and bright line down the middle after a month.

The machine gun which lets you launch tiny projectiles at speeds high enough to kill a person sometimes fires rounds without you pulling the trigger and causes a casualty.

...

Yes, the technology is incredibly complex and represents a huge transformation in the way we do things, but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly. Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.

This is not to say that the people who made the tech are at fault per se, just that the customer is not at fault either for complaining when things dont work.

>Yes, the technology is incredibly complex and represents a huge transformation in the way we do things, but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly.

In some ideal world, where you can have things with MILLIONS of moving parts and TRILLIONS of states, designed by mere mortals and still have them be faultless, yes.

In the real world, the customer will have to settle for things not being 100% perfect.

He can now do things unheard of even in science fiction 20-30 years ago, and takes for granted things only appearing like 6 years ago (e.g YouTube).

>Given the fact that most (all?) of the products mentioned in the post have some kind of price associated to using them, its not unreasonable to expect they work correctly.

I think that, yes, it is unreasonable. That you pay for something doesn't mean anything related to it's error margin. You cannot demand the impossible just because you paid for something. It's like saying: "hey, I paid for this car, why does it is disfigured when it crashes and can kill me?".

Consumer products (non digital) break all the time. You can even pay top dollar and yet have crap food served to you. And all those are far less complex than software.

My argument is not that consumer products should be perfect; it is that when consumers see deficiencies in them which could reasonably be fixed, they have every right to complain. In fact, they should complain because it will help make things better.

What makes things better is that they buy a competing product.

Are they meant to be examples of complex tech that aren't allowed to fail and don't? Or examples of complex tech that does fail, but really shouldn't?

>but a customer doesn't and shouldn't need to understand that, and certainly shouldn't be offered the complexity as an excuse for it not working correctly

It's not an excuse - it's an explanation. These things are complex, and complex things sometimes fail. The average user can be forgiven for not really appreciating this, but lack of knowledge of the nature of complexity doesn't magically make it disappear.

Of couse companies could take the NASA approach of spending huge amounts of time and money on formal requirements/analysis methods, building massively fault-tolerant solutions etc etc, but I doubt there's a vast amount of users out there willing to buy tech that's 5 years behind cutting edge, and costing many times more, simply because it (almost) never fails.

They are meant to be examples of failures which are extremely rare and would be unacceptable to consumers. Sorry, I realize they are quite unimaginative :P

My response to your comment is the same as the previous one:

>My argument is not that consumer products should be perfect; it is that when consumers see deficiencies in them which could reasonably be fixed, they have every right to complain. In fact, they should complain because it will help make things better.

>They are meant to be examples of failures which are extremely rare and would be unacceptable to consumers. Sorry, I realize they are quite unimaginative :P

Cars stop moving on a fairly regular basis, often as a result of the comparatively simple mechanical side of things. In the case of Toyota a couple of years ago, they didn't stop moving at all when the driver wanted them to.

The other examples you gave have happened too - this despite the rather more critical nature of the machine gun issue and again its relative simplicity compared to, for example, a modern phone.

I've got no problem with people calling out where they see problems, expecting someone to at least take their complaints seriously, and in a lot of cases expecting the company to do something about trying to resolve it.

But that's not really the message I took from the article - the idea that that these problems are caused by lack of passion or quality on the part of the people making this stuff rather than being an almost inevitable result of the complex nature of these systems.

TBH, I'm not even sure I buy that it's really that much of a problem. Almost everything isn't actually broken - the vast majority of our tech works remarkably well the vast majority of the time, and I prefer having tech that mostly works and is both available and affordable than having the same tech that will work perfectly when it's delivered in 5 years time at a vastly increased cost.

Stop. Re-read the post. Try to understand the point of the post. Understand what it is he's saying about process, craftsmanship and trying to fix things that are broken instead of making excuses. Understand it as a call to action to do better, to be better and to care more.

Then re-read your response and see what a defensive crouch you immediately took. How that immediate defensive reaction led you to miss these points. Crying "complexity!" for things that don't work is not a solution. Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.

>Stop. Re-read the post. Try to understand the point of the post. Understand what it is he's saying about process, craftsmanship and trying to fix things that are broken instead of making excuses. Understand it as a call to action to do better, to be better and to care more.

"Calls to action to do better" are a dime a dozen.

You can get them in $5 self-help books, motivational posters and bs marketing gurus. For all I know, they come free with Cheetos.

The problems he describes are not because of some "lack of craftmanship". They are inevitable in large scale, enormous complexity systems, that also have to SHIP some day. Things that CAN get fixed, ARE getting fixed.

>Time, money, education and understanding are required to implement a solution, and I believe that Scott is explicitly calling for the latter and implicitly calling for the rest.

Saying that "Time, money, education and understanding are required to implement a solution" means absolutely nothing. At best is a platitude that goes without saying.

Do you or Scott thinks that the major software players do not spend time, money, education and understanding on what they are making?

Microsoft, one of the software makers he complains about (and he knows internally), spends tons of money on testing and QA. And it has some of the top minds in software engineering. Ditto for Apple, ditto for Google.

You've totally missed the point of his post. You're talking about Scott Hanselman here, he does understand all that.

I don't think so. Read his postscript:

"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.

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.

>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.

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.

>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.

Open Source complaining assholes apart, which can fall high on the disrespect scale sometimes, users have all and every right of complaining about the things that are not working, always. Users are not in debt of software developers in my view. If you think otherwise, then that's the key of our disagreement.

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)

The point is Mr. DoYouKnowWhoIAm is getting old.

Reply on news.ycombinator.com