Even the best software sucks

I rant a lot about user experience.  If you know me, you've probably heard me ramble on about it.  And when I talk about user experience, I don't just mean a slick UI.  There are a lot of aspects to user experience, like performance, responsiveness, obviousness, etc.  I'm not going to go into all of that here, as this is a rant about traveling.

I recently embarked upon a cross-country drive with my family to attend my wife's family reunion.  It was a good trip overall, except for one thing.  Google Maps!  Oh, how I have learned to hate thee.  Now, don't get me wrong, I love Google Maps.  It's saved my bacon on more than one occasion.  There have been times where it has wrong information and has led me astray, but that's understandable.  It's a difficult task to keep that much map data up-to-date and accurate with how frequently things change in our world.  What happened to me was far more annoying.  I use the built-in turn-by-turn navigation feature of Google Maps when traveling by car, and it's almost always been great.  However, a recent update has made it extremely unstable.  It crashes every hour or two.  No notification, it just silently exits and my phone eventually goes to sleep if I don't notice in time.  This wouldn't be a huge deal, except for two factors that the developers seem to be unaware of:

1. Google Maps actually does crash.
2. There are areas of the country that have unreliable or nonexistent cellular data signals. 

You would think this would be common knowledge, but I guess over in California, they have miles and miles of reliable data signals, and they never, ever leave their little bubble.  There's no other explanation for a few of the behaviors of Google Maps.  Let's go into them:

Google, Google, where art thou, Google?

After restarting from a crash, Google Maps forgets that you were mid-navigation.  I can understand that it doesn't want to just assume you didn't exit on purpose.  That's fine. But it could pretty easily prompt you.  "I see you were in the middle of a trip.  Resume?"  This would have saved me from so much pain that I might have forgiven the fact that the app crashed approximately 40 times on my trip.  This would depend upon Google Maps actually storing ANY trip data on the phone itself, which apparently it does not or else you wouldn't have to do the following.

Houston, I'm broadcasting in the blind.  Is anybody out there?

To restore your trip, you have two options.

1. Type in the destination again.  Wait until it finds it.  Click on the navigate link.  Pick the route.  Click navigate again.  Wait for it to get the GPS sorted out.  Go.
2. Click in the search box.  Wait for the recent history to appear.  Click on the navigate link, etc, as above.

So option 2 would be acceptable, if a bit tedious, if Google Maps actually kept your recent history on your device.  Alas, no, it does not.  It has to go out to the internet and get your history so you can start your trip again. Did it never occur to the developers to follow basic mobile app development guidelines and assume that the data connection is unreliable?  I can understand that Google has to spy on everything you ever do and wants to store that data online, but there's absolutely no reason it doesn't also keep a local copy that it just asynchronously updates when the internet reappears.  No data connection?  We got you covered.  But, no, that isn't how they do it.  There's nothing quite so infuriating as having the map die a few miles before a turn in the middle of nowhere and you furiously are trying to get it going again before you miss your turn, only to see a "no connection" error when trying to start the trip again.  Why isn't the trip already downloaded?  Don't you know what local storage is for?  It got to the point where my wife just loaded the trip in Waze on her phone as a backup, and while having the same directions parroted to me from two devices within seconds of each other was kind of amusing at first, it was also a sad statement about how badly Google Maps was performing for this trip.

To err is program

To me, this is just a basic feature of a navigation program that should have been solved years ago.  I'm not even getting into nice-to-have features like displaying speed limits on the map.  Seriously, why isn't that a thing?  You already have the data or you wouldn't be able to calculate how long the trip takes.  So, instead of asking for the bare minimum of caching the trip after you search for it, and not requiring an internet connection to see your recent searches, I'm going to one-up that and say what Google Maps really should provide: the ability to pre-cache an entire trip from your cushy, safe, wifi connection at home that never needs to touch the internet again the entire trip. It should download the entire route and all maps within a reasonable distance of the trip (say, 1 mile on both sides of the road, to cover pit stops and small detours). I've got gigabytes of free space just begging to be used for this. Bring it on, Google.  Based on the difficulty of your interviews, even your HR interns should be capable of providing these features.  They aren't that difficult to program.  Now, where's that bug tracker...

Making sense of the Hadoop ecosystem

I've been learning Hadoop for my job at Rackspace, so I wrote up a rather lengthy treatise as a primer on the various pieces of software in the Hadoop ecosystem.  After asking for some fact-checking from my team, it was suggested that I post it to the Rackspace blog instead, so I did.  They said it was too much awesome for a single post, so they had me split it into two posts, kind of like Kill Bill or the last Twilight movie.  Writing these posts is what got me to finally start this blog, so now you know where to point the blame.

Part 1

Part 2

Things have changed a little in the last month since I wrote the posts.  Maybe I'll do a Part 3 at some point with what I've learned since then.

Edit: Fixed the link to Part 1 - it had changed since they originally published it for some reason.

On recruiting at conferences

I always find it interesting, if a bit sad, that at every conference I attend, every talk has an obligatory "we're hiring" slide.  It's always delivered with such a lackluster, almost apologetic tone, that it probably only serves to turn people off of the option, honestly.  It feels like whoever is presenting was forced to include it by an overeager recruiting department.  The same thing goes for trying to recruit by having a booth or by networking at the conferences.  A girl came up to the table I was having lunch at recently, and very bluntly said she was looking for people to come work for her company.  My response was "so is everyone else".  The fact of the matter is that people who come to conferences are sent there by their employer, which means that a) they're employed and b) their employer thinks highly enough of them to pay a lot of money to send them to a conference.  It's just not a receptive audience.  The best thing you can expect out of conferences is to get your name out there so when people are looking, they're aware of you, and all the awesome stuff you're doing, and how happy all your employees seem, and the fact that you didn't force your presenter to post a "we're hiring" slide in their talk. You're better off investing that effort and money in getting involved in the community by hosting local user groups, contributing back to open source projects, and building a good, developer-friendly reputation.

Anger-Driven Development

If you've been a programmer long enough, then you've come to realize one simple, universal, unassailable truth: all other programmers are morons.  Then if you've been a programmer a little bit longer, you realize that to every other programmer, you *are* the other programmer, but I digress.  There's been a slew of X-Driven Development methodologies talked about over the years: Test-Driven Development, Behavior-Driven Development, etc.  While those are all good in theory, what I find that actually gets things done is what I like to call Anger-Driven Development, or Frustration-Driven Development.

The basic gist of it is "these floors are dirty as hell and I'm not gonna take it any more!".

Here's how it goes:

1. You repeatedly have to do some mundane or menial task that the idiot who designed the system should have automated (note: the idiot might be you).
2. You get sick of doing it, and yell "Khaaaaaaaannnnnnn!!!!!" a lot.
3. You channel that anger, ignore your deadlines, and automate it away so you never have to do it again.

Or alternatively:

1. You have to maintain some software written by a moron.  You know you've been there.
2. You keep having to use some awkward-to-use, obtuse interface that only makes sense to the moron who wrote it.  Good thing he no longer works there or you'd give him  piece of your mind!
3. You cry when nobody's looking (hopefully nobody's looking).
4. You channel the rage and rewrite or wrap the problematic code so that you don't have to waste one more second of your precious life dealing with it.

That's basically it.

1. Situation sucks
2. You get angry enough to do something about it
3. You fix the glitch.
4. ???
5. Profit

The problem with all that anger is, if you bottle it up too much, it tends to come out in powerful bursts.  You become the Hulk and rage on the source of your frustration, which is counter-productive.  Joss Whedon, the wise sage, has taught us the secret in the recent Avengers movie:

I think that's about where we need to be as developers: always angry.  We maintain a base level of righteous indignation about the code we have to work with, but we keep the Hulk at bay by fixing just enough of the brokenness to keep the blood from boiling over.  Always just on the cusp of blowing up, but channeling that anger into productive change.  You let the anger drive you to produce better code, better systems, and better processes just so you can sleep at night, despite someone being wrong on the internet.

I'd like to say I'm at that point of anger zen, but I still let the Hulk out at times.  Fortunately for me, my current situation is very empowering, so I'm able to fix things as I run into them for the most part, and Hulk stays within.  For now.