It's easy to find bugs in software, especially considering today's exceedingly complex systems and their frequent interactions with each other. Still, I think computers work rather well, much better than in the Windows XP era. Now, if someone would just tell me what that "Other" space is on my iPhone.
Hanselman goes on a rant about all the misbehavior of his computers and devices. Some problems are more serious than others. For instance:
My iPhone 4s has 3 gigs of "OTHER" taking up space, according to iTunes. No one has any idea what other is and all the suggestions are to reset it completely or "delete and re-add your mail accounts." Seems like a problem to me when I have only 16 total gigs on the device!
He makes a good "money's worth" argument here; I also have a 16GB iPhone 4S, but I have much less "Other" storage:
There's lots of Apple in the list, but lots of Microsoft also and some Google. I can relate, but I don't completely share his conclusions, which are all of these:
Let's take these in reverse order: I've never thought Apple products were all that simple to use. Hanselman gets into this a bit, particularly about iTunes. For years I've thought that iTunes was easily the worst piece of software I use on a regular basis. I'm mystified at how people think iOS is more accessible than the alternatives. But enough Apple bashing, for now anyway.
I think Rosoff is just plain wrong on this score. Consider Hanselman's problems: He's a pretty capable, technical guy and he has to deal with many problems in software. It's not that he's trying to do too much, he's trying to do things that are supposed to be within reach of the average user, let alone the likes of Scott Hanselman.
Hanselman's four issues miss the mark: Let's take developers out of the picture, because most of them are working on what their bosses tell them to on a schedule they are given. If they work too quickly or spend less time on QA than they might, that's a management problem. This particular barn door has been open since Netscape invented "Internet time" and the horse is hundreds of miles away now.
Common sense tells us there is a point at which the marginal utility of fixing the most serious bug outstanding doesn't match the cost in delaying the product. In fact, in most cases the software companies are probably more concerned with the bugs than the users.
And I don't buy his concern that users don't have enough opportunity to complain. Companies the size of Microsoft, Google, and Apple employ professional testers and other outsiders to collect such information. They have all the bug reports they can handle and then some.
The real heart of the problem is that this stuff is really complicated. The part-complexity of a PC running Windows 7, Office, and all the other usual crap is probably many times that of a Boeing 747, and those are operated by professionals and have dedicated mechanics, not Joe Average who barely made it out of high school. I'm more surprised that they work as well as they do than at the things that don't work.
Even on a seemingly quiescent PC a large number of interactions are going on between programs written by different developers who are either trying to conform to some standard or publishing their own specification. Some are local interactions, perhaps over a remote procedure call, some are over networks. But it's all so complicated that it's easy for mistakes to be made; incidentally, it's this same complexity that opens even the most professional software up to vulnerability exploit.
It's always going to be easy to find bugs in software. But on the whole, and (summoning Churchill here) it is on the whole that such things must be judged, the average user's software experience has gotten better over the last several years at the same time that it has gotten far more complex and ambitious.
InformationWeek Tech Digest August 03, 2015The networking industry agrees that software-defined networking is the way of the future. So where are all the deployments? We take a look at where SDN is being deployed and what's getting in the way of deployments.