Monthly Archives: October 2012

Mapping Errors and iOS Maps

There has been a lot of discussion over mapping errors and lack of detail in iOS Maps, so much so that Tim Cook issued an apology.  In the United States at least, I believe this is mostly being made into a bigger deal than it is.  Let me be very clear, as a whole, Google Maps is a better product than iOS Maps.

I don’t think anyone really expected iOS maps to exceed the quality of Google Maps.  Google has been in the mapping business for 7 years and has spent countless hours refining the data both through in-person ground crews, user location data and user error submissions.  Anyone who expected Apple to top that either has exceedingly high expectations of Apple or unbelievably low respect for what Google has accomplished.

Mapping Errors

The world is a big place; the idea that anyone can be expected to map it flawlessly at the level of detail modern mapping solutions provide is a pretty bold idea.  I’ve come across the following three examples, two from Google and one from Apple’s mapping solution, that I’ve experienced in the past month.  I did not seek out these errors they found me.

First and foremost, Google does not know where I live.  Every other mapping solution I’ve used gets it correct or at least identifies the correct road.  Bing, Mapquest, iOS Maps, VZW Navigator, Garmin all stop you at my driveway.  Google will put you about 4 miles away.  I blame the city planners for this a lot more than I do Google, but still others get it right.

Google Map Containing Mapping ErrorsNow for a more detailed example.  I was using Google maps to get an estimate of how long it was going to take me to get somewhere and it told me a number that seemed unreasonable.  I then noticed that it was taking me a really odd route.  The picture on the left shows Google’s proposed route which involves an approximately 10 mile detour.  The core of this problem appears to be that the routing engine believe’s the bridge is one way.  Zooming in on the image, will display bi-directional arrows across the bridge, but for some reason Google will not route you across it.



iOS Map Containing a more Logical Route

Here you can see that iOS has mapped a more logical route directly across the bridge. I will argue this is a pretty glaring error to put someone 10 miles out their way, in this specific example it would nearly double your trip length.

 The intersection around this bridge is a mess and is under major construction so the route will be changing and I’m sure Google will eventually figure it out.  But this serves an example where iOS data is superior to Google data.

Apple’s error is a lot less complicated and a lot more dangerous.  They have connected a cul-de-sac to an adjacent road through some trees and a pool in someone’s yard.  In the following screenshots I have dropped a pin and then toggled the view mode of the map between Standard and Hybrid.

iOS Map Containing Mapping Error in Standard View

iOS Map Containing Mapping Error in Hybrid View

 Why would Apple Switch?

 It’s no secret that Apple and Google are in the midst of a rough patch in their relationship.  So is Apple sacrificing the end user experience just to punish Google?  I don’t believe the answer is clear-cut either way.  Clearly the map quality on iOS devices has been reduced so the user experience has clearly been negatively affected in that way.  However the launch of the new mapping application also includes turn-by-turn navigation that users have been wanting and competing Android devices have had for a year or more.  It’s rumored that Apple and Google couldn’t come to terms on Google providing this sought-after feature.

Does the gain of turn-by-turn out-weigh the mapping errors?  I think that largely depends upon how you use your device.  If you use it primarily to find locations prior to driving, Yes your user experience has been sacrificed by the fighting couple.  If you use it to get directions while you’re driving the switch is probably a net gain. 

Improve Code Quality by Disabling Copy and Paste

Integrated Development Environments (IDEs) should ship with Copy and Paste disabled by default in an effort to improve code quality. I acknowledge this is an extreme position that will not be popular by the majority of those who happen to read it.

Reasons why Copy and Paste should be disabled by default.

  1. It promotes what I have to believe is the most frequent code smell; duplicated code.

    Recently I was upgrading some commercial libraries and it was found to cause problems in numerous areas of the application. This is par for the course whenever you wait two years to upgrade libraries. I was appalled to learn that nearly character for character code had been repeated no less than 5 times within a single file. To better put this into perspective, the source file was 1800 physical lines when I checked it out and 1100 lines when I checked it back in; nearly a 40% reduction.

    I imagine the development went something like this. The programmer started by making the initial segment of code and got that working to their satisfaction. Once it was finished they went down to the next set of requirements and found that it was nearly identical, but with a few variations to the code they had just written. They took the code from before, duplicated it, and then modified it slightly to fulfill the second requirement. This repeated 5 or more times and allowed the author to finish their code quickly, which naturally makes most programmer’s bosses happy.

    I believe it’s natural for all people to want to do the least amount of work possible to accomplish a given goal. I jokingly call this being lazy and genuinely believe it’s a positive thing for a wide variety of careers; software developers included.

    The problem here is that it is easier to copy, paste, and then alter the already working code than it is to break it out into reusable functions, classes or extension methods. Imagine for a second that Copy has been disabled.

    It’s clear the author already recognized that the problems were similar enough to use the previous code as a starting point. Since they would be unable to duplicate the code via copy and paste it would be advantageous to them, at that very moment, to move that code into a common area.

    This is the main reason why disabling copy and paste in IDEs would encourage better quality code. It eliminates the requirement to have foresight to the future maintainability of the code or a desire to produce high quality code and transitions it to being the easiest way to do it right now.

  2. It would promote writing reusable code from the very first time you start to program.

    I think anyone who has been programming for any length of time can remember a time where design decisions they made have come back to bite them hard. This is frequently how I learn new programming techniques. I run into a problem that’s going to be difficult to fix due to poor design and I find a new technique that makes it easier. Mistakes are essential to learning.

    With that in mind it may seem contradictory that I want to discourage beginners from making this very common mistake. The thing with code smells, in particular duplicated code, is that the code will work perfectly fine and it is only when it is revisited that the problem becomes apparent. For beginning developers this may never happen until long after the bad habit has been learned.

I’m not suggesting that all ability of pasting code should be removed, just the repeated pasting of code. Cut and paste should remain as it’s a convenient way to move code around. I would just like to see the paste buffer cleared after code is successfully inserted.

I realize that even with the measure described here it’s still going to be possible to duplicate code via a plain jane text editor that you use as a scratch pad or simply by typing the same thing over and over again. My suggestion is that by making it inconvenient it would encourage the better practice and improve code quality.