Locating Design in Latitude, Find My Friends, and Yelp

The conventional wisdom in computing is that the difference between Apple and its competitors, is design. This isn’t wrong, but it’s insufficiently specific: when people say that Apple focuses on “design,” they often mean that the visual, graphical, surface aspect of Apple products, is different. It is – but that is not a difference of “design.” Design is about fitting the designed artifact into human lives, and there are some crucially important non-visual aspects to design in this sense.

I’m going to talk about one specific group of non-visual design choices here, comparing Apple’s “Find My Friends” service to two similar services – Google’s “Latitude” and Yelp’s check-ins feature (used here as a stand-in for check-in services in general – e.g. Foursquare, Facebook Places, Gowalla). All three share a core functionality: they advertise the user’s location and allow them to discover the location of others. They differ in how they attempt to fit into users’ lives, and in how they execute their attempts. I want to illustrate how, in the areas where it is attempting to do the same thing as the other services, Apple’s service is different, and the difference is design.

As phones have become mobile computing devices, they’ve converged with desktop computing in some ways, and diverged in other ways. One of the convergences is the social experience: email, the original social experience in computing, was one of the first things that made smartphones smart. One of the big divergences is location: it may be advantageous to know where a specific desktop computer is, but that location is unlikely to change – it’s a single piece of information. With mobile computing, location is a stream of information instead of a single piece, and adding that stream to other streams of information, then distilling, is where many mobile companies have added value. One of the obvious results of trying to put the social and local aspects of mobile together is check-in services: a way to say “here I am!” to your social circle. Google participated in an early wave of such services with Google Latitude’s launch in early 2009, Yelp launched its check-ins feature in early 2010, and Apple’s offering appeared in late 2011. All of these services allow you to broadcast your location, to restrict who can hear that broadcast, and to view the broadcasts of others. Those functions are the core of any location-based social service: they are the same across all three services, even though these services all have different goals.

  • Apple, in characteristic fashion, makes the service’s goal very, very obvious. Its name is “Find My Friends.” There isn’t that much to say about the service – there’s a map, other users of the service show up on the map, and you can find them. That’s it.
  • Yelp’s service is slightly more complicated, but still straightforward. Yelp is all about restaurants, venues, and other businesses, so it lets you broadcast that you are at a specific business. It doesn’t show you a map, but instead a list of places where others have checked in – which is not very much help in finding them if you’re at Candlestick Park, for example. It also lets business interact with and reward patrons who visit frequently, and allows users to send short messages to Yelp, Facebook, or Twitter, about what they’re doing at the place where they’ve checked in.
  • Google’s service is open-ended. There’s a map, other users of the service show up on the map, and you can find them. Latitude shares a lot of genetic material with Find My Friends – they’re both implementing the most obvious thing you can do with social-plus-local. Google’s service is goal-agnostic: for quite a while, the map was all it was, but recently, they’ve added an API and a feature that tells users how much time they’ve spent at home, at work, or out-and-about.

These summaries show one significant design difference between the services: Apple and Yelp have clearly defined goals for how their services should fit into human lives. Apple helps you find your friends. Yelp helps you evaluate venues. Google’s service can do what Apple’s does, but also shows you a history of where you’ve been, has check-ins like Yelp’s, and lets you broadcast your location through other Google properties (for example, you can have your Latitude location displayed as part of the Google Chat interface). Its public API also lets other services build on its data and provide further services. Now, “you can’t summarize what Google Latitude does for users in a concise sentence” is not exactly a major flaw. It is, however, sloppy design by the criteria we’re using right now. Not having a clear answer for “how does this fit into users’ lives?” shows that you have a design problem. As long as that question goes without an answer, you will never have a well-designed product. Answering that question requires focus.

I’m going to diverge for a moment: we humans have a complicated relationship with choice and focus. Of course we want both: it is good to keep your options open, and it’s good to focus. But they’re mutually exclusive goods – and when the chips are down, we have a very strong desire to keep our options open. The best example of this is a study that Dan Ariely performed on MIT students and wrote about in Predictably Irrational: his study offered participants three doors on a computer screen, each of which offered varying rewards when clicked on. Participants were asked to maximize rewards with a limited number of clicks. They were easily able to do this in the first iteration – but in the second iteration, any door that went unclicked for a certain amount of time, closed permanently. At that point, participants’ efficiency fell dramatically – they went to great lengths to keep all of the doors available for opening. Participants “couldn’t tolerate the idea of the loss,” Ariely writes, claiming that we are all averse to foreclosing on possibilities in the same way – unless we consciously fight that bias. Good design is about fighting that bias:

In June of 2003, Steve Jobs gave a small private presentation about the iTunes Music Store to some independent record label people. … people kept raising their hand saying, “Does it do (x)?”, “Do you plan to add (y)?”. Finally Jobs said, “Wait wait – put your hands down. Listen: I know you have a thousand ideas for all the cool features iTunes could have. So do we. But we don’t want a thousand features. That would be ugly. Innovation is not about saying yes to everything. It’s about saying NO to all but the most crucial features.”

Apple and Yelp’s services have decided what they’re going to say no to. As far as I can tell, Google’s service hasn’t. This is consistent with the general way that these three companies work with focus and choice. Yelp has it easy: it defines itself as being a company that is about evaluating venues. That can be a big job – but that definition also excludes many things. Yelp will never be a peer-to-peer file-sharing service, create an operating system, or manufacture a tablet computer. Apple, by contrast, is big enough and ambitious enough that it might do anything – and it is very, very selective about what it does do. The credo of “say no to all but the most crucial features” is one that’s been reflected in every Apple product for the last decade. At this point, making a product that didn’t leave half of the technical press corps whiny and dyspeptic about missing features would be an astonishing thing for Apple to do. They say no to features all the time.

Google is having trouble learning to say no. Consider Google Wave – if Google Latitude has a half-hearted, lame answer to the question, “how does this fit into users’ lives,” Google Wave brazenly defies the question and jeers at its premises. But Google did eventually say no to Wave – and perhaps its features will in time show up in contexts where they can give a satisfying answer to the question. Google’s best products – for example, Search and Gmail – answer the question decisively. For that matter, Google’s corporate goal of organizing and making useful the world’s information, also is a good step towards answering that question of design.

Now, another piece of conventional wisdom in computing is that Google is bad at design. I think that that is true, but that it’s true in ways that people usually don’t consider. Just as Apple products’ good design isn’t just surface appearances, Google’s bad design decisions don’t happen in a vacuum. It’s ridiculous to suggest that Google commits bad design because they’re dumb or malicious. Nothing could be further from the truth about the Google employees of my acquaintance, and the company itself is only as dumb and malicious as Apple is – which is to say, many orders of magnitude less so than the average American corporation. I believe that Google’s design problems stem from business strategies in which design is irrelevant, from the cognitive bias of not wanting to foreclose possibilities, and, crucially, from having chosen extraordinarily difficult design challenges.

  • Google’s business strategy centers around widening its moat. This is a large part of why Google launched its social networking service, Google Plus – to protect its core business from Facebook. This is part of why Google launched its music product – to protect against Amazon and Apple trying to expand into its territory. This is part of why Google has Android – Google disrupts other businesses by being cheaper than free. What all of those have in common is that for them to succeed on a strategic level for Google, doesn’t require that they be dominant or highly profitable. If they did need to be dominant or highly profitable, there would be an evolutionary pressure to design them well – but there isn’t. When good design doesn’t help your business towards its strategic goals, good design gets thrown overboard. So it goes.
  • Google’s corporate culture is rooted in engineering. This has many positive effects, because Google is also obsessed with hiring enormously smart engineers. They’re very good at that. That means, however, that they inherit some of the cultural biases of computer engineering in general. One of these is the cognitive bias that the users must be similar to the programmers of software and devices. That causes problems for design, because the way that the “unwilling to foreclose options” bias operates in engineers, is that they don’t want to give up configurability – don’t want to give up control. As a result, if you’re the sort of person who is willing to be the sysadmin of your phone, Android is great for you. The cost of that configurability, though, is paid by giving up focus.
  • Finally, Google has taken on some enormously, enormously difficult design challenges. I think that this is a bigger factor than is usually acknowledged. With a shallower pool of design talent than Apple, and less time to nurture it, Google has taken on harder design problems. To see how hard they are, just contemplate that “organizing the world’s information” goal – and then realize that Google takes that seriously. Apple tries many things, but few ever leave the black box in Cupertino. The number of things that Google has tried is enormous, and the amount of money that they have put towards them, even more enormous. Google runs search, Gmail, YouTube, Blogger, Analytics, Adwords, Adsense, Calendar, Reader, Docs, Drive, Android, Chrome, ChromeOS, Voice, Translate, Earth, Groups, Latitude – and you’ll need to pause for breath again before you run out of recognizable Google properties. Further, they run many of them as public goods – the SPDY protocol, the public DNS servers, hiring on figures from the open-source world and essentially patronizing them to continue their work (e.g. Guido van Rossum). So with fewer design resources than Apple, they’ve chosen tougher problems. Once you look at it that way, their design woes are entirely predictable.

As a result of these factors, Google Latitude is a typical Google service – while it does some interesting things, and it’s improving over time, it’s unfocused and it’s hard to gather its features into a coherent value proposition. If you’re a developer and you’re interested in location services but not in Objective-C, you could do worse than to familiarize yourself with Google Latitude. Google has refrained from foreclosing on your options – you can reach out to Latitude from whatever you’re programming and make friends with it. Apple provides a location services API, but that’s not a Find My Friends API. Find My Friends is private property.

Private property is a good thing in a location service, though – a service that lets you broadcast your location is a service that can be used to follow you and to gather information about you. The privacy controls in Apple, Google, and Yelp’s services are very revealing: they show the differences in design clearly. Google Latitude maintains a list of people who are allowed to see your location. You can add and remote people from the list and tell Google whether they’re allowed to see your precise location or a less specific version, and you can turn on and off broadcasting your location at all. Yelp allows you to decide who will see your broadcast every time you use the check-in feature – you can tell Twitter, Facebook, your Yelp friends, or nobody in particular (although in the last case, you’ll still be part of the generally visible stream of checkins on Yelp, but you’ll be lost in a crowd).

Apple’s Find My Friends adds one important privacy feature that Latitude doesn’t have, and says no to one feature that Latitude does have. When you decide to share your location with someone on Find My Friends, you can also add “for the next few hours” – you can tell the service that your sharing is temporary. You can also manually turn off sharing with that person later, as with Latitude – but if you have already made a decision about sharing your location, Apple’s design lets you do all of your decisions at once, instead of requiring that you come back later and undo what you have done. I think that’s an important symptom of the difference in design. Apple’s design allows you to centralize decisions in time. Apple’s design also avoids burdening you later: you don’t need to go back to the service later and tell it to stop caring, after you already have. It fits into your life by not requiring that you take extra steps to stop doing something – you can just stop. Google Latitude needs more work than that to fit into your life – and surely people have wanted a feature like this since Latitude’s 2009 launch.

On the flip side, Google Latitude lets you manually set your location in addition to simply switching automatically-detected location on and off. I call this a “promised location.” Find My Friends does not let you do this, and I think that’s interesting. Why not? For one thing, I’d guess, a promised location doesn’t pull its own weight. You don’t need an app to make a promise about location to other people – if you have enough information about someone to share location on Find My Friends, you have enough information to use something else to make a promise about your location. So it’s redundant, and redundancy is a thing that good designs usually eliminate. More subtly, you might not keep that promise about your location – so you could say that Latitude permits you to lie about your location. If you were to look up my location on Google Latitude, you’d see me forever trapped in one Whole Foods market, never leaving it. You could also say that Google Latitude is less likely to break up a relationship. Yelp, for the record, uses location checking and other heuristics to check on your promised location.

So Apple’s design is missing that feature. Is that good or bad? It is opinionated – and that’s what good design fundamentally is. Design is about making decisions, and Apple’s design here definitely expresses opinions about how it fits into your life, and those opinions are consistently expressed, top-to-bottom. Of course people differ – part of the challenge of design as a field of endeavor is that people differ so widely in their needs and desires, and nothing will satisfy all of us. So of course Apple’s products don’t satisfy everyone. But what makes their product well-defined is that they have renounced trying to make everyone happy. That difference between Apple and the rest of the industry is visible in every Apple product: Apple has an opinion about how their products fit into humans’ lives, and that opinion is focused, saying no to possibilities that are appealing, but in the end sub-optimal. That is what it means that the difference between Apple and everyone else, is design.

§298 · October 25, 2011 · Comments Off · Tags: , , , , , ,

WordPress-Magento Integration Error

This is a quick pay-it-forward post to anyone else who was having the same problem, because when I searched Google for solutions, I didn’t come up with anything. I think it’s a bad thing when googling for the verbatim text of an error message produces nothing.

So: you’re running a Magento site, and you’re using the FishPig plugin to integrate WordPress into your site. You might end up in a nasty situation where the integration settings page in Magento is telling you that “Your blog URL (site address) matches your install URL (WordPress address). Please change your blog route or move WordPress to a different sub-directory” and that that’s a problem. It is. Things will 404 as long as that’s true. However, the closest thing you’ll find to help on the FishPig site is deeply obscure.

An error that can happen when trying to integrate Magento and WordPress

The problem might look like this.

The basic problem is one of terminology. WordPress is designed to play well with others, and to be highly configurable. So it cares about two URLs (URIs if you’re picky). It cares about “the file path that my PHP files live in on the server, relative to the root of whatever site I live in (e.g. in Apache, the DocumentRoot)”, and it cares about “the public URL that I will respond to.” In the database, these are ‘siteurl’ and ‘home’, respectively, in the wp_options table. It can be tricky to disentangle these two URLs, but for many WordPress installs, setting them both to the same URL is good enough and gets everything working.

However, that’s not the case when you need to integrate a WordPress blog into Magento. For the FishPig plugin’s “fully integrated” level of operation – which is good stuff, the best way to run that plugin – the WordPress PHP files need to live in the same site as the Magento files (when using Apache, they need to both be in the tree that starts at the site’s DocumentRoot), and, contrary to the usual WordPress setup, the ‘siteurl’ and ‘home’ values must not be set to the same URL. This is where we run into problems. The WordPress control panel refers to the ‘siteurl’ value as the “WordPress address (URL)” and the ‘home’ value as “Site address (URL)”. The FishPig plugin’s error messages, as seen above, will tell you that they can’t be the same, and will tell you that the ‘home’/”Site address” value has to match the “blog route” variable” in Magento. However, you have to fill in the third part of the syllogism yourself, and remember to set the ‘siteurl’/”WordPress address” to the same value as the “WordPress path” variable in Magento.

The final puzzle-piece is URL rewriting – most WordPress installs try to do a little .htaccess magic, and it can be tricky to keep it straight. If it’s not working correctly, you can end up in a state where the WordPress install, including admin pages, is completely inaccessible from the web and you’ve got to move down a layer and throw queries directly at the database to figure out what’s going on.

I imagine that this is obvious if you know WordPress better than I do, and it probably seemed obvious to the FishPig folks. However, if you’re in the same position I was in, where the WordPress admin page has become inaccessible, and there are no changes you can make in the Magento admin page that can fix the problem, I hope that this helps you.

§279 · September 14, 2011 · 2 comments · Tags: , , ,

A Recommendation I Can’t Get From LinkedIn

This one’s short. I had several short-term co-workers lately, and one of them at the end of her tenure left me a nice note.

That made me really happy. Helping people is a great feeling, and so is having your work acknowledged. It’s interesting, too, that the very things that make it easier to communicate, can also change the tone of communication. There are interactions where a written, physical artifact used to be required, and is no longer required. I don’t think this was ever one of them, really. So it’s interesting that someone went out of their way to create this. I think that’s perhaps a valuable way to look at the difference between digital and physical-artifact communications – you can send a different message, even with the same words. The range and shape of possible expression has changed. If we had actually lost handwritten artifacts, I’d be sad – but we haven’t. They merely say something different now.

Take ownership of all of your communication, no matter what form you put it in.

§269 · May 11, 2011 · Comments Off · Tags: , , ,

Generating vCards In Python

At work recently, I had to test an address book application. Part of the requirement for testing was that it handle large numbers of contacts gracefully – 100, 1000, 5000, or 10,000. My personal address book is nowhere near that big and I’m not about to use it for testing – so I turned to Python. The vCard format is pretty much a special kind of text file, so it’s easy to create new vCards, and a vCard can contain multiple contacts by just concatenating contacts.

I didn’t find exactly what I needed already in existence, so I wrote up a basic script to do it, and in case anyone else needs it, here it is. It is released under the Apache Software License 2.0, and I hope you find it useful.

#!/usr/bin/python
"""Generates an abitrary number of valid .vcf vCard contacts based on the
parameters set at the beginning of the file. See also:
http://softwareas.com/vcard-for-developers
http://en.wikipedia.org/wiki/VCard
"""
import random, sys
################################## Parameters ##################################
# We'll use this data no matter what the user tells us.
# What fields shall be populated?
target_fields = {"Name":True,
                 "FullName":True,
                 "Organization":True,
                 "Address":True,
                 "Title":True,
                 "Phone":True,
                 "Email":True,}
# Data that we'll use to populate the cards' fields.
first_names = ["Alice", "Bob", "Carol", "David", "Elena", "Farquahd", "Gretel",
               "Hans", "Iris", "Junichi", "Khalisha", "Lee", "Mina", "Nassif",
               "Oba", "Prudha", "Hida", "Kaiu", "Aaron", "Sangamon",
               "Ferdinand", "Sanjay", "Asok"]
last_names = ["Smith", "Jones", "Smythe", "Jorgenson", "Kim", "Luxury-Yacht",
              "Throatwarbler-Mangrove", "Cooper", "Black", "Ahmedinejad",
              "al-Tikriti", "al-Bagram", "von Trapp", "von der Wallenheim",
              "Gamgee", "Proudfoot", "Brewer", "Kagehiro", "Ng",
              "Nguyen", "Salzmann", "Bear", "Powers","Kusanagi", "Dengo",
              "Mukherjee","Balaam"]
# Street numbers will be generated at random.  All addresses are
# situated in Anytown, CA, ZIP 12345, United States of America.
streets = ["Paper Street", "Fictional Lane", "Placid Avenue", "Blank Road",
           "Suspicious Parkway"]
orgs = ["Monty Python's Flying Circus", "Golden Egg Bonus Company, LLC",
        "Dewey Cheatham & Howe, Tax and Family Law", "Improv Everywhere",
        "Owl-Stretching Enthusiasts' Club", "International R. Mutt Fan Club",
        "Paper Street Soap Company", "River City Pool Table Company",
        "Desert Bus Runs", "Impossibilities Inc", "The X-Men"]
titles = ["Mercenary", "Chief Tomfoolery Engineer", "Nonsense Supervisor",
          "Skylark", "Isn't It About Time For Lunch", "Famous Author",
          "Fictional Person", "Space Traveller", "Architect",
          "International Person Of Mystery", "Sith Lord", "Sith Apprentice",
          "Sith Intern", "Archaeologist", "Scout", "Heavy", "Sniper"]
# Phone numbers will be generated in the form 555-NNNN.
# Email addresses will be generated in the form  firstname.lastname@example.com
################################## Actions ###################################
class CardFiller:
    """A class whose instances take the basic dataset we're working with,
    shuffle it, and grind through generating VCard entries based on it. """
    def __init__(self, first_names, last_names, streets, orgs, titles):
        self.first_names = first_names
        self.last_names = last_names
        self.streets = streets
        self.orgs = orgs
        self.titles = titles
    def prepare(self):
        for lst in [self.first_names, self.last_names,
                    self.streets, self.orgs, self.titles]:
            random.shuffle(lst)
    def fill_card(self, target_fields, position):
        """Takes data and fills in fields, then creates a list of formatted
        lines that can be written into a .vcf file. Takes a position argument
        that it basically interprets as modulo the length of the list."""
        new_card = ["BEGIN:VCARD", "VERSION:2.1",]
        # Fill the Name field.
        if "Name" in target_fields:
            namefield = "N:"
            namefield += str(self.last_names[position % len(self.last_names)])
            namefield +=";"
            namefield += str(self.first_names[position % len(self.first_names)])
            new_card.append(namefield)
        if "FullName" in target_fields:
            fnamefield = "FN:"
            fnamefield += str(self.first_names[position % len(self.first_names)])
            fnamefield += " "
            fnamefield += str(self.last_names[position % len(self.last_names)])
            new_card.append(fnamefield)
        if "Organization" in target_fields:
            orgfield = "ORG:"
            orgfield += str(self.orgs[position % len(self.orgs)])
            new_card.append(orgfield)
        if "Title" in target_fields:
            titlefield = "TITLE:"
            titlefield += str(self.titles[position % len(self.titles)])
            new_card.append(titlefield)
        if "Phone" in target_fields:
            phonefield = "TEL;WORK;VOICE:("
            phonefield += str(random.randrange(100,999))
            phonefield += ") 555-"
            phonefield += "%04d" % random.randrange(0,9999)
            new_card.append(phonefield)
        if "Address" in target_fields:
            addrfield = "ADR;WORK:;;"
            addrfield += str(random.randrange(1,18234))
            addrfield += " "
            addrfield += str(self.streets[position % len(self.streets)])
            addrfield += ";Anytown;CA;12345;United States of America"
            new_card.append(addrfield)
        if "Email" in target_fields:
            emailfield = "EMAIL;PREF;INTERNET:"
            emailfield += str.lower(self.first_names[position % len(self.first_names)])
            emailfield += str.lower(self.last_names[position % len(self.last_names)])
            emailfield += "@example.com"
            new_card.append(emailfield)
        new_card.append("REV:%d" % random.randrange(100,500))
        new_card.append("END:VCARD")
        return new_card
def rolodex_engine(card_limit, target_fields):
    """Iterates over a range to generate a list of strings that can be
    sent to file or to stdout and which constitute a valid vcard file.
    Most programs that read vcards can accept a file that contains
    multiple vcards - all you have to do is concatenate them."""
    card_engine = CardFiller(first_names, last_names, streets, orgs, titles)
    card_engine.prepare()
    rolodex = []
    for i in range(1, card_limit+1):
        new_card = card_engine.fill_card(target_fields, i)
        for line in new_card:
            rolodex.append(line)
    return rolodex
################################### Execution ##################################
if __name__ == '__main__':
    """Run a variety of sanity checks regarding the arguments to the
    script.  If there are no command-line arguments, give the user a
    hint. If the arguments are weird, quit and ask them to try
    again. User input and the filesystem: two pain-in-the-butt parts
    of software engineering."""
    # Sanity checks.
    if len(sys.argv) != 3:
        print "This script requires exactly two arguments: \n",
        print "* The number of vCards to generate \n",
        print  "* The name of the file to store them in. \n"
        sys.exit()
    if type(sys.argv[2]) != type("string"):
        print "The first argument must be a number, the second a name."
        sys.exit()
    try:
        int(sys.argv[1])
    except ValueError:
        print "The first argument must be a number, the second a name."
        sys.exit()
    if int(sys.argv[1]) > 2**16:
        print "Try generating less than 65,000 cards."
        sys.exit()
    if len(sys.argv[2]) > 128:
        print "Try a shorter filename."
        sys.exit()
    card_limit = int(sys.argv[1])
    card_export_file = sys.argv[2]
    # Writing to disk.
    try:
        with open("./%s" % card_export_file, "r") as rolodex_file:
            print "A file with that name already exists."
            sys.exit()
    except IOError, ioerr_msg:
        try:
            with open("./%s" % card_export_file, "w") as rolodex_file:
                rolodex = rolodex_engine(card_limit, target_fields)
                for c in rolodex:
                    rolodex_file.write(c)
                    rolodex_file.write("\n")
        except IOError, ioerr_msg:
            print "The script couldn't create a file for the vcards."
            print "The specific problem was '%s'" % ioerr_msg

Writing this was basically like doing sit-ups in Python – not really challenging, but demanded, like all serious tasks, that you sit down and devote time and concentration to it. After that, results come easily.

§264 · May 2, 2011 · Comments Off · Tags: , , ,

Externalities Are Relevant

The online economy is deeply weird and breaks many rules that guide the functioning of the physical economy. However, there’s one concept that’s highly relevant to the online economy that I need to talk about: externality. We like to think that in any transaction, people are getting what they pay for – but that’s not always true. There are people who aren’t part of the transaction, but who are affected by it anyhow: those people are the recipients of an externality. A positive externality comes when you essentially get something for free that is the result of others’ transactions, and a negative externality is visited upon you when others get to fob off some of the costs of their transaction on you. Externalities are “external” because the people actually involved in the transaction haven’t captured all of the costs and benefits of the transaction; they happen all the time because there are some things it’s impossible to keep internal to a transaction.

Here’s an example: a major public transit agency near me, Caltrain, is about to cut service. Caltrain’s funding, in large part, comes from sources beyond its control. A little less than half comes from ticket sales – and the rest from local municipal governments. The local governments collect no taxes dedicated to and aren’t bound to pay for Caltrain: in years like this one, where tax revenues are shrinking, they can simply decrease their funding. That’s what’s happening now. That’s a transaction between them and Caltrain. I’m just a Caltrain rider, I’m not a party to the transaction – but it’s going to affect me anyhow. The service cuts that Caltrain has to make have major negative effects on riders who aren’t part of the transaction between Caltrain and local governments: they are the subjects of a negative externality. Similarly, if the service cuts go through, traffic on highways between San Francisco and San Jose will get significantly worse. Train service created a positive externality that benefited drivers – anyone who was taking the train was not driving, and congestion decreased. There’s also a positive externality that has to do with air quality: the train is a more efficient way of transporting large numbers of people than requiring each of them to drive their own car.

The reason that externalities are relevant to the tech field is this: most startups entirely rely on them. Free Software, whatever its intentions, creates enormous positive externalities. It’s almost impossible to name a tech company that doesn’t depend on some piece of free software. Further, most tech companies in turn create significant externalities because of their advertising-driven revenue models. I dislike advertising-driven revenue models – but like everything else, they’re a trade-off. An advertising-driven revenue model – for example, Facebook’s – means that all benefits to users are externalities on one level. Of course you are still in a transaction with Facebook – but most of that transaction is invisible to the average user. We users give Facebook data – the data that makes their vaunted social graph valuable and lets them produce creepy marketing videos. That tiny transaction, times hundreds of millions of users, gets refined into a product that Facebook can actually make money from. Any other startup with the same revenue model is doing the same thing: they’re purposefully creating positive externalities, because without those, they can’t do the transactions (with advertisers) that they actually make money from.

This is a highly interesting business model, and has created many interesting things. I personally think that in evolutionary terms it’s a loser: advertising as practiced in the modern world is a hostile, toxic, invasive species, and letting it into your ecosystem is a bad idea. But what I want to talk about now is a company that doesn’t share that revenue model, and about how it handles externalities. It’s time to talk, yet again, about Apple.

Part of the reason that Apple’s prices are what they are is that you are paying for things that you normally get for free as an externality. When you buy Apple products, you are forgoing a price that’s artificially low. I like to think of it this way: you are paying something closer to the ‘true’ price of the product. The price in dollars to the users of Google products like web search, Gmail, and Google Reader, is low or nil because Google relies on selling user data to others for its revenue. You get nice things for ‘free’ because the actual price you’re paying is invisible. Apple products, on the other hand, usually don’t do that – you will pay dollars, and you will get your product or service from them, and that’s that. I think of it as paying for peace of mind. Free services usually involve a third party, an advertiser, who has an enormous, overwhelming, powerful incentive to attack my peace of mind. That is what the modern business of advertising is: it is attacking people’s mental health.

Apple is in the tech news again because of externalities: they have allowed iOS apps to use a subscription-based revenue model, and the changes that they’re making are pissing off all kinds of people. As another economics-oriented blog post put it, “if you own the infrastructure, you get to charge rent.” What interests me, though, is that Apple has chosen to create a positive externality for user experience here – and they have deliberately done it, risked money to do it, risked business partnerships to do it. That’s interesting – and, I think, good. When the people who use your product are the people you make money from, you wind up focusing on keeping them happy. If you make money otherwise, you risk turning into Adobe (Microsoft also has bouts of this): making mediocre products at exorbitant prices and squealing when someone exposes the flaws of your product line.

Whimsically, I think that Apple also creates a huge externality for the tech journalism corps. They are the largest company that actually takes risks, and so they help ensure that there’s always something interesting to write about.

§238 · February 16, 2011 · Comments Off · Tags: , , ,

It Only Looks Easy

The Internal Revenue service has, as government agencies go, a pretty simple directive. Here is the tax code, which we can consider to be a big lump of business logic. Here are people’s statements of how much money they made and how much money they owe. Using those two, make sure that people stated both halves accurately.

It won’t surprise you to learn that that isn’t actually a simple task.

I do expect it to surprise you that it’s even more complicated than that. Here’s something that betrays the complication, one little directive from IRS Publication 17, Chapter 12: “If you receive a bribe, include it in your income.”

Yes, the IRS has to tax you on illegal income. No, the IRS isn’t allowed to fully care that it’s illegal income – otherwise the whole agency is a walking 5th Amendment violation, something that people frequently get on their case about. I am not the world’s biggest fan of the IRS – but I think that their position is a great illustration of how complicated systems work. Systems get complicated easily, and the ongoing task of “civilization” is to make complex systems manageable. This is difficult, and the difficulty scales up unpleasantly late in the game. It’s still worth thinking about.

My favorite exposé of this, especially in light of the California elections, is Steve Yegge’s Have You Ever Legalized Marijuana? He barely scratches the surface, but he very effectively demonstrates that legalizing marijuana, no matter how much you like the idea, is a huge and complicated thing.

Taming complex systems is never easy – but that’s pretty much how we get advances in civilization. So we need to be good at it. I’m always happy to see evidence of this happening, especially when it’s in entertaining form. Pac-Man comes to mind. Pac-Man is a great example of a complex system in this context – and a recent blogulator has given us all a fascinating look at the internals. This is the sort of thing I love reading, because it shows how aspects of ordinary life that we don’t always look at directly, are full of complexity and reward investigation.

Unfortunately, that complexity also means endless debate. Even when there is an authoritative answer to a complex question, someone whose salary depends on that answer not being understood, will probably be able to prevent people from understanding it. The long version of this is in Cosma Shalizi’s authoritative takedown of The Bell Curve tomfoolery, and the short version is in The Onion’s “New Study Finds Blacks More Likely.”

This is part of why simplicity and elegance are hard. We are surrounded with complex systems, and synthesizing something simple and useful requires taming complexity – which is a tremendous challenge. Fortunately for us hackers, that’s usually where the interesting problems are.

§227 · December 8, 2010 · Comments Off · Tags: , ,

← Older entries