On Overestimating Google

Zac Cichy made an observation at 22:32 in to Episode 005 of The Menu Bar that “we’re way overestimating just how great Google is at the things that they do.”

Zac goes on to say that Google are “more vulnerable than people in the technology community currently believe.” This is, I think, due to the “creepiness” of Google in recent years. To people with a deeper-than-average understanding of the Internet (such as understanding, say, tracking cookies or javascript), Google has always had that element of creepy¹. Creepy that an advertising company tracks every move possible that you make online (they even used to let you view what they had on you, but they’ve since shut that off). A little off-putting that an advertising company sank millions in to building the fastest web browser so that you could surf the web faster and see more ads. Google’s data collection policies are becoming more pervasive (invasive?) at the same time as Google is serving more consumers than ever². It’s getting to the point that “normal” people are starting to notice how creepy they are as a company.

But back to Zac’s original comment³: I’d go a little further and say that they have some glaringly obvious problems stemming from what they don’t do. Google may be one of the least human companies in all of tech. Not in the sense that they see no problem with people walking around wearing HUD’s with attached cameras mounted on their forehead, but in the sense that they seem to suck, badly, at actually dealing with actual humans. It is notoriously impossible to talk to anyone at Google if you were to, say, get your AdWords account banned unfairly. I’ve heard multiple horror stories about people trying to get service on a Nexus 7 when it breaks. They seem to outright hate dealing with people, which must be especially frustrating since they’re now entering the business of selling hardware to consumers instead of just selling consumers to advertisers. This is probably why their foray into “social” is failing so badly – they just aren’t that social.

Introducing Ratchet

Ratchet is an extension for Chrome that is made to hide inane comments on HackerNews. It was a weekend project, and before this, I hadn’t ever written a Chrome extension, or very much JavaScript.

How it Works

Ratchet uses some simple jQuery to traverse the DOM looking for the span of class comment, then measures the grade level of it using the Flesch-Kincaid method. If that grade level is less than 8, it goes up by a few parents (to make sure and hide the entire tr) and adds a hidden class.

Three things needed to be calculated for this equation: the total number of words in the comment, the total number of sentences in the comment, and the total number of syllables in the comment.

Total number of words is by far the easiest. Just discard all special characters, then load each word of the comment into an array. The word count is the number of elements in this array.

The sentence count is more difficult, but it is possible to get it right most of the time. This is done by using a regular expression to find the amount of things in the span that match a given “end of sentence” pattern, such as a period or exclamation point, followed by a space. There actually isn’t a nice way to do this with 100% accuracy – What if a sentence contains a Mr. or Mrs.? What about abbreviations? Sure, they could just be excluded, but then what if a sentence ends in an abbreviation? Not a pretty situation there, but this is a weekend project so we’re probably okay.

After some Googling, I found that counting syllables is one of the classic “Really Hard Programming Problems.” English is an especially hard language for counting syllables, and there are some really gigantic libraries out there for doing this. I got a series of decent regular expressions from a StackOverflow commenter, tested it on several paragraphs of text, and decided it was good enough. Besides, in the entire Flesch-Kincaid equation, the syllable count is only one part, and having it be plus or minus a few will not dramatically alter the result. The result COULD be altered handily on shorter comments, but most of those will get hidden anyway due to low word / sentence count.

Some Opinions

This works best for just browsing HN (maybe on your work computer), and I in no way suggest using it while actually trying to participate in conversations. It can break the “parent-child” style of comments, as well as make you miss important parts of the discussion. Just because a comment is easy to read does not mean it’s inherently worthless, and in some cases these are the most important ones. Such is the case when trying to explain something really technical in simple terms. Conversely, some of the most inane comments of all can escape this filter by not using any punctuation (the script will read it as one long sentence).

But it was a nice exercise, and a nice way to dive into building Chrome extensions.

Everything Sucks and Nobody Cares

The title of this article is a riff on Louis CK’s “Everything is Amazing and Nobody is Happy”

Everything sucks and nobody cares. This is true for almost all aspects of product design but is, I think, especially prevalent in software. Its the year 2013, and a lot of people who have to use computers every day (but who aren’t nerds that think computers are a hobby) still find software completely obtuse, confusing, and generally impenetrable beyond the most basic of uses. Of these people, many of them assume that the software isn’t working correctly because they’ve broken it, or because they’re stupid.

This is wrong.

In general, the reason that software doesn’t do what you want is not because you’re stupid. Software doesn’t do what you want because it is truly, genuinely terrible¹.

Why, though, is software so bad? A few thoughts:

Excellence is Expensive

Also known as the “Good Enough” mentality. For software companies that exist to make money, compromises almost always have to be made somewhere. If we all obsess over making everything absolutely perfect every time, we’ll never ship anything. 80% of your users will use 20% of your features, so a lot of ground can be covered just by choosing the correct 20% of features to really hit home (not that this is an excuse to cut corners on the other 80%).

Consider a few popular examples: Adobe Creative Suite, Microsoft Office, Apple iTunes, etc. The reason this software is expensive isn’t because it works correctly 100% of the time (no software does that). It works more correctly, more often, for most users and in the case of big, old code bases like these, has essentially become a standard. Because of this, users and businesses who depend on this software gladly pay for it. It’s important to keep in mind, though, how much more expensive this software would need to be if it did work 100% of the time. Would you pay $1200 for Office instead of $200 if you knew that Excel was going to be more helpful when there was an error with a macro? Would you pay $5 per song instead of $1 per song if you knew that iTunes was going to correctly save edits to ID3 tags²? For “normal” users, the answer is no.

Of note: There are a gifted few who are either so prudent or so in-touch with their users that they are able to make great software without incurring great expense. I would like to write a post in the future highlighting “the good” of the world of software.

Learning Something New, No Matter How Much Better it is than the Old, is a Major Time Investment

As an example to illustrate this point, here’s a description of someone we all know: the middle-to-old-aged man, usually found in a management position, who to this day absolutely refuses to give up his Blackberry for a proper smart phone. Touch screens never work the way he wants them to, the software keyboard is useless (“how can I tell what I’m typing??”), and he is generally lost when the tiny icons or widgets are flying around on the screen. The effort required to learn these things poses not just a time overhead, but a mental one as well. Never mind how much easier life would be if time were made to learn something new. Lots of people just can’t be bothered.

It’s not that there aren’t legitimate reasons for this mentality. This hypothetical person grew up in a world where phones were tethered to wires and where we had to actually push numbered buttons to call one another. The Blackberry that, to us nerds is the most ancient, boring hardware there is, was a giant technological advancement requiring a significant time investment for some people.

Few people demand anything “better” than what is already out there because to them, it’s amazing we’ve even made it this far. This lack of demand from “normal people” means there are few inherent forces that incentivize us as developers to ratchet up the quality of our work.

Spaghetti Code, or The Big Ball of Mud

This one is also common in very large, very old code bases. A piece of software has been around for 10+ years, always building on the same original code base, and eventually the entire project resembles a big ball of mud. It’s a developer’s nightmare, even if it compiles and works fine and the users don’t know the difference.

When software reaches this point, the most valuable person working on it is the one who’s been there the longest and who understands all the intricacies of the code. They are the ones who will know where to look when bugs need to be squashed or when junior engineers need help finding something. These people are the “swamp guides.” They know their way around The Big Ball of Mud, and whether they are particularly great programmers or not, when it comes to getting this kind of sofware out the door, they are more useful to the company than the best programmers in the world.

When the swamp guides are more valuable than real software architects, quality will always suffer³.

All Software is Made by People who Understand Software

A lot of people who deeply understand software, and who have lived with it for a long time (most programmers) end up making bad software because they’ve forgotten what it was like to not understand how this stuff works. In my experience, this isn’t due so much to outright apathy as it is to a lack of imagination.

For some teams, this can be helped by having a person whose only job is to defend the users. Sometimes there’s no budget for this and the team has to find a way to live with it. Other times, the user experience can be pretty much fine, but bugs slip through based on simple probability – if there’s a bug that only happens to 1 in 50,000 people, you aren’t likely to find it by having 200 people test the software.

One Last Important Note

These factors each contribute to a resistance to change, which is one of the seeds of demise. Software that has these problems though, can still continue to persist. That is, bad software isn’t going away for a very long time, including bad software made by people who should know better.