(Disclaimer: I in no way speak for Playdom.)
There’s a certain strain in the criticism of social game development that has always sounded bizarre to me, and I think I’ve finally understood why. It’s really a two-fold strain: on the one hand, it complains about the metrics-driven approach to game development that social game studios typically take, and on the other hand, it complains about the focus that social game developers typically have on how exactly they’re going to make money. With these two hands frequently united in an allegation that all that social game makers care about is whether a feature increases or decreases revenue.
These complaints were so foreign to me that I ignored their existence for quite some time, until some smart people that I have quite a lot of respect for caused me to realize that yes, many people really do have that point of view, and it was one that I should take seriously. And, once I started taking it seriously, I realized that it’s actually a completely natural point of view! I like making analogies on this blog; and if I replace video games by, say, books or music, then the idea of a metrics-based approach and a business focus would sound pretty weird/unpleasant to me, too. So what I’d discovered was that I had a pretty big blind spot in that area myself; where did it come from?
The answer that I’ve come to is that it’s because I’ve spent the last seven or so years immersed in agile software development; and a metrics-based approach and a business focus both fit into agile quite naturally. One of agile’s key tenets is that you should have a precise notion of what ‘done’ means: agile recommends this in your tight coding loops, with TDD; it recommends this at longer-term levels, with acceptance criteria for stories. And a metrics-based approach fits into that point of view very well, helping to extend the importance of ‘done’ from the programming side to the product owner side: it encourages the product owner to also have green bars of their own that their feature prioritization process is trying to attain, it encourages them to come up with formal criteria that they’re trying to satisfy.
Furthermore, looking at metrics is a way of paying attention to what your customers (and potential customers) are actually doing. And this, too, is firmly established within agile: XP has a “Customer” role, with a strong suggestion that that person be an actual customer of the product. This, of course, doesn’t make sense in all circumstances, but even when it doesn’t, similar ideas appear: e.g. Toyota famously sent its designers of their first minivans and first Lexus models to live with their target customer base.
So, the upshot is: paying close attention to customer-focused metrics makes a lot of sense from an agile viewpoint. Indeed, not doing so when such metrics are easily available (as is the case for web-based software) would be rather odd.
That’s the metrics side of this puzzlement; what about the business focus? A business focus is, honestly, something that I couldn’t have cared less about when I was younger—I was all set out to be an ivory-tower academic—but here too, agile was an awakening for me. Take the Customer concept I mentioned above: that person may not be an actual customer, but she’s definitely somebody with the business goals firmly in mind. This business/engineering collaboration is firmly established within agile: the business side sets the priorities, the engineering side takes charge of getting those priorities done. And both work together to proceed in an iterative approach, to deliver business value as quickly as possible and to discover actual (not hypothetical) business value as quickly as possible, allowing them to sculpt the product’s goals to meet business needs.
And this, it turns out, is pretty fascinating. It’s especially fascinating for me because of my personal history: I worked on the same product for several years before joining Playdom, and it was never a business success. Some of that is the fault of engineering execution (for which I shoulder as much blame as anybody), but a fair chunk of that is that we never managed to find a way to engage the market that allowed our engineering strategy to work. And that wasn’t because people thinking about the business side of the product were stupid, or made obviously bad choices: it’s because it’s a really hard problem to solve. So, from that point of view, working at Playdom is a huge relief: I can frequently point to something that I worked on last week that is making money for us this week, and that feels great.
So: agile has trained me to like metrics, agile has trained me to take a business focus. But where does that leave art, where does that leave craft?
Here, too, we run into a blind spot of mine: I wouldn’t normally think of those (especially metrics) as being in any way antithetical to art or craft. The reason for that again, of course, being agile: it has strong statements in favor of the craft of programming, paired with quite a lot of explicit guidance to that end. My favorite agile practice is TDD, and craftsmanship is right there on an equal footing with measuring your results: yes, you have to come up with a metric (“red”), but you also have to make your code look good (“refactor”). And lean also has an extremely strong craft focus.
It is, of course, the case that working to satisfy metrics and business concerns puts a constraint on your choices. But this isn’t inherently antithetical to art or craft: in general, I think that constraints are as likely to help art as they are to hurt it.
So, that’s where my blind spots in this area come from: my recent background means that certain questions that are natural to others just aren’t questions that I’d be likely to think of. At least if I’m primed to be in an agile mindset by being in a programming context; as I said above, I’d be quite likely to raise those complaints in, say, a literary context. Which raises the question: which is the best model to consider here?
And, to that, my best answer is “it depends”. If you’re driven to create games that come out of your experiences and vision, if you couldn’t care less what most people think or whether or not you make money, then I will in all sincerity say that that’s wonderful. (On which note, everybody please chip in some money for Jordan Magnuson’s Game Trekking project!) Even when doing so, you may find the occasional metric useful—see this report of how dramatically differently users may approach our games from what we expect for an example of why—but you may not.
But, for better or for worse, most video games take rather more work to produce than most books. So I personally would not be comfortable working on a project that multiple people depended on for their livelihood without a hard look at business considerations. (Heck, forget “multiple people”: I wouldn’t be comfortable working on a project that I depended on for my livelihood without a hard look at business considerations.) I don’t care about business considerations at all when writing this blog; I care about them a lot when working.
Our art form will become better the more tools there are in our bag. Being aware of tensions is great; treating tensions as creating separate worlds, not so much.
This post has not been revised since publication.