Why did Google release Ingress?

Google recently announced a move into a market that's confused many people - an Alternate Reality Game called Ingress.

It's hardly an obvious move - Google is a Big Data, search and advertising company, not a games manufacturer.  They provide services with mass-appeal that users typically use every day or so, like e-mail (GMail), search (Google search), social networking (Google+), blogging (Blogger) and others, but from the perspective of Google as a business these are - fundamentally - all merely ways to deliver paid advertising to consumers.

An Alternate Reality Game is none of these things - it doesn't have mass appeal (most people still don't fully understand what an ARG even is, let alone play one) and even dedicated ARG players spend most of their lives and leisure time not playing their chosen game.  It lacks mass-appeal, even dedicated players may not use the service from one day to the next, and there's no clear, obviously way to insert advertising into the game in any particularly lucrative way.

So why release it? 

What Google are good at 

As stated above, Google are a Big Data company - they excel at managing, querying and manipulating huge datasets, and at making simple interfaces to this data available to the public.

However, they also excel at another related skill - getting other people to generate the data for them in the first place.

Remember the free automated directory enquiries service that everyone wondered why Google would launch several years ago?  Much confusion was provoked by the choice - "why would they do that?  What's the benefit?  Where's the business model?", people asked.  It seemed mystifying at the time, but Google were cleverly using the service to quickly and effectively build a vast corpus of spoken word queries in a variety of accents, to train the voice-recognition systems that subsequently made it into Google Voice and Android.... and then as soon as it was built, they shut down GOOG-411.

It's worth pausing at this point to reflect on the genius of this move - most commenters were focusing on the (not-inconsiderable) expense of setting up an automated directory-enquiries service.  However Google was playing a much larger game, wherein this cost was trivial compared to the value of building a world-class database of voice-samples to train voice recognition software.  Not only did they gain a vast corpus of sound-samples, but by setting up an interactive service where users were strongly motivated to correct any misinterpretations (in order to obtain accurate results), they also ensured that they had the correct interpretation of each sound sample - neatly removing almost all of the effort from not only collecting but also categorising/interpreting the learning dataset.

The value of this dataset really can't be over-estimated - Google were already capable of indexing and querying all the digitised text data in the world, but they were completely incapable when it came to audio data - spoken-word, recorded audio, video soundtracks and the like.

By developing an acceptable voice-to-text system they made whole rafts of new application and services possible - automatically generated e-mail transcripts of voicemail messages left via Google Voice, auto-transcripts of video media (allowing both closed-caption subtitles and the possibility of text-searching within video media the way it's already possible to search within textual media), permitting reliable voice search and voice control of software and hardware, and many others.

Or for another example, consider ReCAPTCHA (initially created by an independent company, but quickly snapped up by Google), where their free CAPTCHA service also helped them to automatically resolve edge-cases and unrecognised words when production-line digitising books for Google Books (thereby turning analogue, offline text into digitised, searchable text).

Google Image Labeller was another - a small, fun game Google launched that got users to collaboratively tag images, which in turn hugely improved Google's image-search system's accuracy and specificity.

So how does this relate to Ingress?

At a guess, it's about getting Google good data for footpath routes to compete with Nokia's recently announced turn-by-turn navigation for pedestrians.Google maps/navigation are great for driving directions, but pretty terrible for walking - they typically just tell you to follow the nearest road, which can lead you on annoyingly roundabout, unattractive or even unnecessarily dangerous routes in many areas.

Many hints about the new game are dropped in this All Things D article.  Note how Ingress is specifically geared around pedestrians:

Users can generate virtual energy needed to play the game by... travelling walking paths, like a real-world version of Pac-Man. Then they spend the energy going on missions around the world to “portals,” which are virtually associated with public art, libraries and other widely accessible places... Outdoor physical activity is a big component of this, though driving between locations isn’t banned

I.e., it's very, very much about walking places... while carrying a GPS-enabled mobile device with a camera and accelerometer and wi-fi and mobile data connection built into it... while running their app that can report whatever it wants back to their servers and has to for you to be able to play the game (i.e., no privacy concerns, as would be the case if they started aggressively tracking and recording the movement of every mobile Google Maps user).

Players walk around footpaths and pedestrian routes that Google Maps currently doesn't cover well, and then as a reward they get to... walk around art installations, libraries and other large, pedestrian-only public areas that Google Streetview cars can't get to.  All the time the game client is reporting back to Google their position, speed and the like, so Google gets to build a massive database of popular pedestrian-accessible areas and common routes between and around them.  It's genius.

Based on this I also predicted that Google Ingress would also encourage users to take geotagged photos of these various locations in the game as mission objectives.  After all, if you've just managed to convince thousands or millions of people to build you a massive GPS-tagged pedestrian-accessible location and route database essentially for free, you'd have to be pretty stupid not to also get them to take geotagged photos and similar media for you while they do it.

I also argued that the game probably records wi-fi SSIDs and a whole bunch of other useful datapoints, too... both proven correct with further investigation in this reddit thread.

Google are very good at manipulating vast datasets, and if anything they're even better at finding inventive and mutually-beneficial ways to convince large numbers of people to voluntarily build those datasets for them.

In short, whatever the plot of Ingress is about, the point of it is to quickly and cheaply build an unrivalled corpus of pedestrian-accessible routes, locations and journey-times for the next generation of foot-enabled Google Maps and Navigation apps, or I'll eat my hat.

Postscript

This idea seems to have gained some traction since I first advanced it on reddit - within a day or two it was all over the social web, suspiciously similar ideas (usually with exactly the same examples) popped up without attribution on half-a-dozen SEO and spammy unattributed-aggregation blogs, passing reference was made to the idea in a FastCompany article about Niantic Labs, and it was even featured (and cited!) on Forbes' technology blog.

Geeks can be hard to work with

Geeks and especially programmers often have strong belief in "doing things right". People have remarked on this tendency, and given it a variety of negative characterisations: obsessive-compulsive, irrational, making a moral issue out of a pragmatic question.

As a geek and a programmer, I put my hands up to this stereotype - it doesn't affect us all, but enough of us (myself included) have some degree of it that I don't think it's inaccurate. However, I believe that far from being a drawback, it's arguably a vital component of a gifted developer.

I think this urge toward technical correctness comes from three main sources:

Obsessive-compulsiveness

Good programmers spend a lot of their time thinking in details - they have to, to be able to write reliable code. Programmers who gloss over or fudge details write buggy code with unhandled and unknown edge-cases.

Importantly, this code usually "sort-of" works most of the time (or at least, the obviously broken bits quickly get patched), and then occasionally fails spectacularly and catastrophically... at which point it's also usually blamed on the programmer who wrote it, rather than the manager who specified an over-complex requirement, or who provided an unreasonably small amount of resources (time, money, manpower) to achieve it.

Being a programmer is 50% artistic and 50% autistic, so it's hardly surprising that programmers can be a bit Aspergers-y about their code, especially when they're likely to carry the can for any catastrophic failures caused by it.

Artistic merit

Any programmer who isn't a journeyman or hack does the job because they like to create things, and as you get better mere creation isn't satisfying - instead you want to create things of beauty.

It's been noted before that (many or most good) programmers are makers - we need to feel that what we're creating reflects our abilities - something we'd be happy to put our name to - and we like delivering good, reliable, flexible, well-designed systems.

Banging out code or design you know is buggy, unreliable, inflexible or has unhandled edge-cases is simply not rewarding in the slightest. It's like hiring an artist to paint a wall blue, or hiring a sprinter to walk slowly to the shops for you.

To be fair, this is a very wishy-washy, non-business-oriented motivation, but I'd go so far as to say pretty much all the best programmers suffer from it - it seems to go with the territory, and not just from programmers, either - chefs are notoriously histrionic, artists are notoriously high-strung about their work and musicians are notoriously unstable or prone to mental illnesses. I don't think you can have excellence without pride in the work, and I don't think you can have pride in work without disillusionment and frustration when you're forced to churn out work you know is crap.

Pragmatism

I've been privately or professionally involved in software development for around 15 years. I've worked in a variety of companies, in a variety of languages and systems, and with a variety of different management styles.

Across all companies, management structures, languages, technologies and system there are only two things I'm utterly certain of:

1. Given the choice between a longer/more expensive design and a simpler, less flexible one, management will almost always say "design it to the current requirements, because we'll never need <hypothetical scenario X>, and it would be a waste of time to build a system which takes it into account".
2. From the date of hearing this, within six months to a year they will discover a pressing, immediate, unavoidable and business-critical need for scenario X... and if they don't react well to being told that this will now take longer to accommodate, they often react really badly to being gently informed this is the result of the decision they took several months previously, at which point you (or your predecessor) informed them that this would be the consequence if they ever encountered scenario X.

Personally I try very hard to avoid taking dogmatic positions on anything, but in the years I've spent programming (especially professionally, when you're most likely to have to compromise on the design or implementation to hit deadlines or budgets), I - literally, with no exaggeration - don't believe I've ever heard "we'll never need that" and then not had to implement it (whatever it was) within a few months of that date.

This only has to happen a few times (especially when you're responsible for cleaning up the mess) before you become firmly convinced that creating a system that's any less flexible than you can possibly manage is ultimately tantamount to just fucking yourself square in the ass.

There are reasons...

So yes - there are a number of reasons why programmers are obsessed with Doing The Right Thing, and why we tend to react with aesthetic revulsion to the idea of fudging designs, or hard-coding things for convenience.

Some of them are unfortunate but understood and accommodated in other disciplines - try commissioning an artist to produce art for your offices then ban him from using anything except potato-prints, or tell an architect (for deadline/budget reasons) to design you a building that they know damn well could fall down at any moment.

Others are actually vital aspects of being a programmer that you can't easily switch on and off - athletes have to be fit, programmers have to be anally-retentive and precise - and that you really wouldn't want to do without in your dev team.

Lastly, if you're a non-technical co-worker or manager, programmers often have a lot more experience working on software projects than you do, and have learned hard-won lessons you aren't even aware are available to learn... particularly lessons where they have to pick up the pieces from their own (or other people's) mistakes.

So yeah, geeks can be hard to work with. But then the guy who knows where the landmines are buried can be awfully prescriptive about where you put your feet as you navigate through a minefield, too. And unless you want your feet blown off, it's often worth listening to them.

Rules for system designing #1: If a system can be gamed, it will

I first encountered this rule in web development, but once spotted I discovered it holds true in many, many diverse areas of life.

When designing a system of rules or procedures (a computer program, laws, a business's internal policies and procedures, etc) it's always tempting to ignore or avoid edge-cases - they seem so obscure or unlikely it's tempting to decide they don't matter, and not to bother resolving or fixing any ambiguities or loopholes.

People think about systems of rules the way they think about other people - you don't have to be too precise, because it'll be clear what the intent of your words is.

However, once set up systems are administrated according to the rules which define them - while "the original designer's intent" is nebulous and open to interpretation, the letter of the law is usually quite specific, even if the eventual result of them is quite different from what the original architects intended. Nobody ever got fired for following the letter of the law, even if by doing so they did great violence to its spirit.

This can be seen in all walks of life - if you're a naive programmer developing a web application it can seem tempting to ignore security holes or undefined edge-cases. "Who will ever spot that?" you think to yourself, "nobody will bother poking around in odd corners of my application, or try firing odd url parameters into my server. I'm much better off adding Whizzy New Feature #436 to my application than tidying up some dusty old corner of the code".

This sounds perfectly reasonable to most people, but any experienced web developers will be shaking their heads about now - first off, when you write code for websites your code is exposed to the entire internet, and there's always someone out there who'll start poking it with a stick, just to see what it does.

Even worse, there are also whole swathes of entirely automated systems like web spiders, spam-bots and automated vulnerability scanners that will systematically follow every link and try every combination of URL parameters it can imagine, simply to see what will happen.

The key point to take away here is that - almost invariably - your audience will turn out to be a lot larger and more diverse than you imagine, and what might seem obscure, boring or unimportant to you might not seem the same way to all of them... and neglecting to handle these edge-cases can lead to the entire system becoming compromised.

Likewise, laws suffer from this problem - they're typically crafted using vague language, and - like any non-trivial system - typically contain numerous unspotted edge-cases and loopholes. Moreover, the equivalent of issuing a patch to an existing law once it has been passed is about as complicated, fraught and long-winded as passing the law in the first place, making it difficult, time-consuming and expensive to correct errors once a law has been passed.

Like programs, relying on obscurity to paper over these loopholes is a mug's game - when laws apply to the number of people in an entire country you're pretty much guaranteed that eventually someone will either deliberately target or just stumble upon an unhandled edge-case. When this happens the system can be gamed, and the laws fail to perform their required function.

When this happens, the results may be anything from a single individual getting away with a parking ticket to your entire society taking a turn for the worse.

Remember: if a system can be gamed, it will, so take care to eliminate all possible edge-cases, and practice defence in depth so when an unknown compromise or loop-hole is inevitably eventually discovered, the amount of the system which is affected and can then be compromised is limited.

This advice applies equally whether you're a developer writing computer code, a politician crafting new laws or a manager adjusting business processes in a company. If it's a system of rules, this design axiom applies.

The web is not a sheet of paper

Print-turned-web designers:

1. Learn the medium you're working in. A five minute video of even the best print advert makes for a lousy TV advert. Likewise, techniques and habits refined by years of print design are often sub-optimal or flatly counter-productive when applied to the web.
2. For the love of god, give up on pixel-perfect positioning and learn to appreciate flow layout. Sure, it makes design harder... but if you think designing flow layouts is hard, think about the poor schmuck developers who have to implement the damn things. And if you think flow layouts are ugly, let's see how good your precious pixel-perfect design works when I do something freakishly unusual like resize my browser window.
3. Print pages are Things To Look At. Web sites are Things To Use. Prioritising aesthetics over usability or functionality is like putting a car steering wheel in the middle of the dashboard. Sure it looks nicer, but it makes the whole product useless. Incidentally, I swear if I get one more design through with a "button" image specified but no "pressed button" image (or "link" style but no "active/hover/visited link" style) I will personally bite off your head and defecate into your body-cavity. You have been warned.
4. Conventions are not boring - conventions are your friend. Putting light-switches near doors is a convention. Sure, putting them square in the middle of the ceiling is innovative, but then so is cheesegrating your knees (hey - do you know anyone who's done it?). Innovative means "nobody else is doing it". Accept the possibility that nobody else is doing it because it's a fucking stupid idea.
5. I don't want to "explore the interface". I want to get in, do my shit and get out again. If you think forcing users to explore the interface is such a good idea, try ripping the labels off all the cans of food in your cupboard. A couple of meals of cat-food, chilli and peaches should demonstrate exactly how "fun" this is for your users.

PANT, pant, pant... pant... ahem.

---

Originally via reddit.