With the Light is a comic book (a manga, specifically), rather than a game; in this country, both art forms are similarly marked as juvenile/adolescent, though I suspect that isn’t as true (especially for comics) in Japan, where With the Light comes from. (I could easily be wrong, however.) This series isn’t juvenile literature, however, though my daughter can attest that at least one kid finds it accessible, even engrossing.

And I’m very impressed by the book. A few reasons:

• The variety and realism of its characters.

The book’s subtitle is “Raising an Autistic Child”, and the most prominent characters are Hikaru, the child of the title, and Sachiko, his mother. Which goes some way towards breaking the characters out of cookie-cutter mode, but runs the risk of setting up cardboard characters of a different sort. To me, though, the book never fell into that trap: Hikaru in particular isn’t presented as some sort of generic autistic child, he’s got his own specific characteristics, weaknesses, and even (as seems to be somewhat a theme of the second volume) impressive and idiosyncratic strengths.

• Its focus on interactions and interaction pitfalls.

Over and over, we see the book seeing people who are talking right past each other, acting at loggerheads; if and when they finally manage to understand what the other side is doing and get a glimpse of the other side’s perspective, everything about the pair’s interactions improves. The book is filled with compassion, but compassion in a hard-nosed sense: not “just try to understand the other person and things will magically get better” but “here are some of Hikaru’s triggers, here are some specific perception differences between autistic kids and non-autistic kids that can lead to behavior that you may misinterpret, here are some strategies that have been known to help bridge communication gaps in these contexts, give them a try and keep your eyes open as to what’s working and what’s not”. (There seems to be quite a lot of detailed research and experience informing the book’s descriptions of strategies and perception differences, incidentally.)

And the interaction problems aren’t just between Hikaru and non-autistic people: most of the characters in the book have their quirks and issues that cause them to behave badly at times, understanding what’s going on helps a lot. This was the part of the book that hit home the most to me—I’m sure that if I’d been in a slightly more maudlin mood while reading it, I would have broken down crying—because I’ve certainly been known to put a less-than-gracious mental spin on what I label as recalcitrant behavior from my own daughter when all that’s going on is that she’s tired! It’s a lesson that I still need reminders of; popping up the stack a bit, it’s a mistake that I probably make most frequently when I’m tired or upset for some other reason, so I should probably also use these tools to improve my interactions with my own mind…

• The way goals change when they meet reality.

The book doesn’t focus on Hikaru’s father Masato as much as on his mother, but he’s certainly there, and portrayed none too flattering at first. He has a goal for his life; it’s a lot more focused on his business success, with his family playing a fairly distant second fiddle, and Hikaru’s diagnosis throws a rather large wrench into those plans. Which Masato reacts badly to (to put it mildly); eventually, though, he comes around, and is much the better for it.

Which is, perhaps, a fairly banal plot point; I bring it up for two reasons. The first is that it’s a banal plot point that games don’t typically manage: while sudden disruptions are common in the start of games, games usually have characters react by attacking the disruption rather than by working with the disruption. (Though Passage did a wonderful job of handling having your plans change because of the presence of another person.) The second is that I’ve gone through one major career change in my life that wasn’t initially particularly of my own volition; even though my disruption was much less profound than Masato’s, I can sympathize with him, and I can very much relate to ultimately ending up in a better situation than I was in before that career disruption.

• Its balancing of contingency and personal efforts.

Hikaru and Sachiko go through a lot, but much of the time things end up turning out pretty well. Their own hard work is very important to that end, but equally important is the fact that they run into some pretty special people along the way. And, again, this matches my own life: I try to work hard to put myself in a position to succeed, but over and over again I’ve gotten extremely lucky with the people I meet and the situations I’m in. (There was certainly a good deal of both in the last two jobs that I’ve gotten, for example.) So I appreciate it when I see a book that doesn’t attribute good outcomes solely to one factor or the other.

It’s a really special book, and thoroughly engrossing to boot. I’ll certainly happily cite its existence as an example of the contingencies that have enriched my life: I’m very fortunate to be living in an era when manga featuring an autistic lead character is being translated and brought over the ocean so I can read it, because I can imagine many many worlds where that would never happen. And I look forward to a world where games’ conception of understanding interactions more regularly goes beyond finding the weak spots in a boss monster’s patters so you can attack it and instead moves on to lower key but much more profound appreciations of differences in perspective.

But it’s also thrown me for a bit of a loop, because it’s undeniably a juvenile game, in the same way that, to pick a random example, Comet in Moominland is a juvenile book. Which is absolutely fine, even delightful—I read ten books by Madeline L’Engle during the last month alone, so I’m certainly not one to shy away from books intended more for my daughter than myself! But I’ve studiously avoided thinking about video games in those terms, avoided trying to distinguish between games intended for kids and games (e.g. Wii Sports) that are accessible to a wide audience but not targeted specifically at kids.

The main reason why I’ve avoided classifying games in that fashion is because I see that classification made far too often around me, in the context of polemics that I disagree with; it’s usually used to support claims that I consider both wrong and boring, leading me to head in the other direction when I run across such discussions. But given the existence of MySims Agents and the usefulness I find in the distinction for books, it’s time for me to take another look at the idea of juvenile games.

For example: are the Mario games juvenile games? What about the Zelda games? Honestly, I’m at a bit of a loss here. The Mario games certainly have something in common with juvenile literature, in that they’re quite happy to not locate themselves in the real world—see the aforementioned Moomintroll series for a delightful literary example. I’m loath to make too much of this particular distinction, though: aside from the existence of many many fantasy and science fiction novels for adults, I tend to think that the insistence of the importance of the fantastic/realist distinction in adult literature is more of a bug than a feature, and a bug that’s localized to my particular location in space and time at that.

And juvenile novels are written in a language that kids can read, and frequently features child protagonists. But I’m loath to make too much of those distinctions, either: we don’t have to use fancy words to prove how adult we are, and surely we can all enjoy books that feature protagonists that differ from us in one way or another? So, while I can come up with ways to tell that a books isn’t juvenile literature (because of the style of language, because of sex, because of certain other topics), I found it surprisingly difficult to come up with a positive and non-banal description of what it means for a book to be juvenile literature. And that carries over to video games as well: to return to my examples above, I still don’t know if the Mario games are juvenile games or not. (And I am apparently not alone; though, if I had to come down one way or another, I suppose my gut would agree with Stephen Totilo’s in labeling the series as juvenile. It’s less clear to me than MySims Agents, though: in the latter, having kids acting out adult roles in a non-realistic context is a marker.)

The other series I mentioned, though, is a different case: the Zelda games are, at their core, adolescent games. Not in the sense that adults or children wouldn’t enjoy them, but in the sense that they’re about boys growing up (literally, in the case of Ocarina), forced to be men a little earlier than they’d like to, but rising to the occasion, finding out who they really are, finding unexpected depths inside themselves. As with juvenile books, I want to emphasize: this is in no sense a criticism, I love bildungsromans enough to have copies of most of Herman Hesse’s books on my shelf in both German and English. (And one could claim that I’m still trying to figure out what it is that I want to be when I grow up!) But a coming of age story is, to me, a strong indicator of adolescent literature.

And it’s one that you’ll find all over the place in video games, present in a deep structural sense. In every role-playing game, your character starts out weak, but becomes more and more competent over the course of the game, with his or her capabilities consciously guided through your choices. And these elements are popular enough to have gotten grafted onto other genres—BioShock, for example takes RPG elements and melds then with an FPS core foundation.

And, of course, BioShock is an adolescent game in other ways—its core conflict comes down to, basically, “Son, do this. No, dad, you can’t tell me what to do! Yes, son, I can! No, dad, you can’t!” This is repeated with a second father figure, just in case you didn’t get it the first time; if that’s not a sign of a game about adolescence, I don’t know what is.

Actually, BioShock grabs me in this context for a second reason: Andrew Ryan’s “these are my toys, and if you don’t like that, I’m going to take my forest and go home” speech. I was going to say that that’s not just adolescent, it brings us back to our “juvenile games” theme, but, actually, most kids I know wouldn’t behave that way, either; it’s using the term “childish” instead in the sense of an anti-child prejudice that adults bring out when discussing aspects of their own behavior that they’d prefer to ignore.

Which brings me, in turn, to another context in which the word “adolescent” has come up recently in video game criticism, namely Heather Chaplin’s GDC 2009 rant. I didn’t attend it in person, but I have listened to the audio, and in general I think she’s spot on. She’s not using the term adolescent in the positive sense of growth, of figuring out who we are: instead, her complaints are with game designers and players who are childish in the sense of my previous paragraph, who refuse to grow up and take on real responsibilities, who are instead mired in “guy culture” despite being grown men, who “fear responsibility, introspection, intimacy, and intellectual discovery”. And, as she continues, “when you’re talking about culture makers, this is a problem.” Indeed.

(And, just in case you might think that her concerns about the omnipresence of guy culture in game design are overblown: the very next speaker in the rant, when needing to fill some time while fiddling with his computer, decides to joke about blow jobs. And yes, I realize that the GDC rant panels are situations where one might reasonably say things that you wouldn’t say in the more polite sessions in the conference, but he wasn’t doing this for any sort of polemical or oratorical reason, he just thought that such joking was a great way to spend time in a professional conference; and the next two voices we heard after him, both also male, thought that this was a good enough idea that they both took the joke and ran with it. Really, guys, what the fuck?)

Returning to my previous themes: while I have a hard time carving out distinguishing characteristics of juvenile literature, I have an easier time carving out distinguishing characteristics of adult literature. Heather’s list of guy culture fears gives some candidates; parenting is one candidate that I’ll nominate from my own life, as is moving beyond romance and the initial falling in love and instead making a life with your partner through thick and thin, through excitement and banality. And these are, in general, sorely absent in video games, or present only in a distorted form. (I just finished Yakuza 2, and the one bit of hands-on parenting in that game rang horribly false.)

There are, perhaps, glimmers, of hope—I hear that Dragon Age: Origins handles relationships in a more nuanced fashion, and there’s always Jason Rohrer to give me hope. (In that same GDC rant panel, Clint Hocking warned that AAA game makers were having their butts kicked by indie game makers, which is all to the good.) But there’s an awful lot of adolescent guy culture to make our way out of, first.

And of course, as with my discussion of the term “childish”: the examples that Heather gave of responsibility, introspection, intimacy, and intellectual discovery aren’t things that real adolescents avoid in general, or even that children avoid in general. They struggle with the weight of those terms, as we all do, but frequently that struggle is done positively, rather than by running away from them, or hollowing out a facade behind them. (As we see in every game that blows up a bildungsroman plot into a chosen hero saving the world; I love the Zelda series to pieces, but it bears little relation to the way responsibility plays out in my own life.)

In fact, in juvenile and adolescent literature, these concepts (especially responsibility and intellectual discovery) are often front and center. So maybe that’s a more positive way to look at the appearance of overtly juvenile games? Maybe overtly juvenile games will have a harder time pretending that they’re grown up because they have a big hero who can order other people around or kill them if those others don’t obey, and will instead have to confront responsibility in a more honest fashion? Maybe (I write just after having learned that our neighbors of six and a half years, who are closer to Miranda than anybody outside of her mother and myself, are moving to Cyprus in a week) replacing the romance subplot of your favorite RPG with the poignancy of your neighbor moving away in Animal Crossing is the first step towards a real treatment of intimacy?

Something to hope for; something to open my eyes and look for.

According to the work of Bergson and Minkowski, two profoundly interrelated aspects seem to coexist with reference to time:

• Becoming. An abstract, dimensional aspect of time, which gives rise to the habit of measuring time (seconds, minutes, hours); the idea of representing time on an axis, as we would spatial dimensions; the concept of the duration of an event (the distance between two points on the temporal axis); the idea of being late (once again the distance between two points on the temporal axis).
• The succession of events. A concrete aspect of temporal order: we wake up, we take a shower, we have breakfast, we study, we have lunch, we have a nap, we play, we eat, and we go to bed. Children come to have this notion of time before they develop the idea of abstract time which passes regardless of the events that take place.

Of these two aspects, it is becoming that generates anxiety – it is, by nature, elusive, indefinite, infinite: time passes, slips away, moves toward the future. If we try to measure ourselves against the passage of time, we feel inadequate, oppressed, enslaved, defeated, more and more with every second that goes by. We lose our élan vital, our vital contact, which enables us to accomplish things. “Two hours have gone by and I’m still not done; two days have gone by and I’m still not done.” In a moment of weakness, the purpose of the activity at hand is often no longer even clear. The succession of events, instead, seems to be the less anxiety-ridden aspect of time. At times it may even represent the regular succession of activity, a calm-inducing rhythm.

I’d heard a bit about the technique before, enough to know that it tells you to break your work up into 25 minute chunks and to try to really focus during those chunks, avoiding distractions and interruptions. It turns out that there’s more to the technique than that, however: it gives guidelines about breaks between chunks (3-5 minute breaks normally, longer breaks after every four chunks), there’s a whole planning and estimating mechanic you’re supposed to use with it (starting each day estimating your tasks in terms of pomodori, and reviewing your day at the end), and there are also mechanisms for tracking and actively tabling your interruptions.

What really sold me about the talk, though, was that, 25 minutes into it, a timer went off, and we all took a break for a few minutes! We took another break 25 minutes later; I think that it’s a great idea to break a 90-minute presentation into three chunks like that. As it happened, I’d been feeling over the course of the conference that I hadn’t been getting enough done over the evenings; so, that evening, I decided to give the pomodoro technique a try, and really focus on things for 25 minutes at a time.

Which turned out to work remarkably well: I probably got as much done that evening of the conference as in the other four evenings put together. Despite which I didn’t use the technique over the next month or so: I was pairing on a project in my last weeks at Sun, we were doing quite a good job concentrating as it was, and it didn’t seem to be a good time to introduce something new.

When I started work at Playdom, though, I picked up the technique again, and I’m glad I did. When I describe the technique to other people, one frequent concern that comes up is: doesn’t the timer going off interrupt your flow? For me, though, my problem is almost always too little flow rather than too much; and the pomodoro technique works great with that. I can stop myself from wandering for 25 minutes if I try, and I know I have a little release valve coming up in the not-too-distant future if I need one. And it occasionally happens that I’m banging my head against something unproductively and need the cooling off period between pomodoros to get myself thinking that I really should take a different approach. Also, it can be a big help if the next task seems frightening in some way: you’re not faced with wandering through something unknown and probably unpleasant for an unbounded amount of time, you’re faced with spending 25 minutes trying to shed a bit more light on your current situation, which is a much more palatable prospect. And I think the explicit guidelines for both shorter and longer breaks are helpful for me.

I’ve tried other aspects of the technique as well; they have had benefits, but I’m less sold on them. The planning period is a helpful reminder that I should think about all the different things that I’m considering working on (my next actions for my various projects, in GTD speak), and pomodoros give me permission to carve out a bounded amount of time to work on tasks that are important but not urgent. Having said that, I haven’t found much of a benefit from the actual process of estimating how many pomodoros a task will take at the start of the day: it doesn’t seem to be solving any problems that I have, and I have other mechanisms for telling myself when I’m getting stuck. (E.g. if I’m not doing multiple git commits over the course of a pomodoro, that might be a sign that things are going well.) So I’m stopping that for the time being.

And there’s one aspect of the pomodoro technique that I’m actively dubious about. One of the core rules is that the pomodoro is indivisible: if you don’t spend the whole 25 minutes working on what you planned, then it doesn’t count as a pomodoro, and you’re strongly encouraged to have as many pomodoros count as possible. There’s a bit of wiggle room here—if your plan at the start of the day has tasks that you think will take less than one pomodoro, then you can combine multiple of them in your plan to make a single pomodoro, and if you finish a task within the first five minutes of a pomodoro, then you’re encouraged to cancel the pomodoro, with the feeling that it was “really” finished in the last pomodoro. If you go beyond the first five minutes, though, you’re supposed to stick it out until the timer rings: in particular, the technique recommends that you spend spare time overlearning, delving into the area in question more deeply than you would otherwise.

Don’t get me wrong, overlearning is a great idea: it’s a similar philosophy to always doing a bit of refactoring once you’ve got your code working. Except that the pomodoro philosophy is different: you don’t always do it, you only do it if there’s time left on your pomodoro, and the amount of overlearning you should do is proportional to the time left. And that just seems bizarre to me.

Take this blog post, for example: I have a pomodoro timer running as I type this. If the timer goes off when I’ve got it done but not properly edited, I don’t want the pomodoro technique encouraging me to hit publish so that I won’t have a big gap to fill in my next pomodoro. After I’ve hit the publish button, probably a bit of overlearning wouldn’t be a bad idea—e.g. this blog post is suggesting an idea for another blog post I could write, so maybe I’ll take some notes on that. But that sounds like a good idea no matter how much time is left on the pomodoro; and those notes will probably take about 5 minutes, so what am I supposed to do if I turn out to have 15 minutes left on my timer when I hit the publish button?

So that doesn’t make much sense to me. The result is that I’m not feeling any guilt about either canceling a pomodoro if I finish a task in the middle of one or about not canceling the pomodoro and launching into a second task without a break in the same pomodoro. (Hmm, I probably should have a preference for one or the other of those solutions, maybe the former?)

But the core idea seems sound, and many of the surrounding ideas have seeds of something that I quite like (e.g. the concept of overlearning), even if I’m not convinced by their details.

Some resources I’ve found useful:

• The main pomodoro technique site. In particular, it contains a 45-page PDF book giving more details into the technique.
• Pomodoro Technique Illustrated. I haven’t read the final version, but the author had a beta version on his web site for a while, and I quite liked it.
• The pomodoro timer I’m using on my Mac.

So we’re forming a book club. And I figured a few of my readers might be curious about the language as well. If you fall into that bucket, let me know and I’ll add you to the mailing list.

The first was given by Jon Dahl, on “Aristotle and the Art of Software Development”. You can see video and slides of an earlier delivery of the talk. (I don’t think it changed much between deliveries; I also don’t know how much sense the slides will make out of context.) He viewed this subject through a lens of ethics: a Kantian view focusing on actions (and, in particular, universal principles motivating them); a Millsian view focusing on outcomes; and an Aristotelian view focusing on actors.

As you might suspect from the title of the talk, Dahl was most taken with the third point of view. (Which begins about 15 minutes into the video or 70 slides into the deck.) He presented Aristotle as linking ethics with happiness and a life well lived, and with virtue (in the sense of performing your function well). Honestly, it may be the case that many of these words had significantly different meanings for Aristotle than they would for us; in particular, Dahl glossed the Greek term that he translates as “happiness” as coming from “good” plus “spirit”; depending on how one takes the compound, I could imagine that as meaning “one whose spirit is good”, which makes the idea that ethical people are happy potentially more of a tautology than an an interesting statement.

Leaving these glosses aside: the point is that being good (virtuous) at something is inherent in the people who are good, rather than being rule-based. Which raises the question: how do you become a virtuous person? In the talk at Agile 2009, it sounded like at least some of Aristotle’s answer to that is fatalist: virtuous people are born, not made. (And—stop me if you’ve heard this before—virtuous people always turn out to be rich non-barbarian males. Sigh.) Watching the video of the RubyConf version, though, there’s a less fatalistic point of view: you gain virtue through practice and through modeling. So, to become an expert, you should hang out with experts, and practice; as you gain expertise, use your improved understanding to improve both your expert detection and your practice.

In contrast, if you’re a Kantian, instead of looking for good people, you look out for good principles, and follow them rigorously. In an Aristotelian point of view (again, with the caveat that it’s been decades since I’ve read any Aristotle myself, I’m just going by the talk), it would be possible to have virtues without formalizing the principles at all; furthermore, Aristotle’s virtues are means between excesses and defects (see slide 95; this gives me a Buddhist vibe, too), so following rules too strictly may actually be a sign that you’re straying from virtue.

The other talk was one by Mary Poppendieck on “Deliberate Practice in Software Development”. It discussed the nature versus nurture question of becoming an expert. My memory of the talk is that she strongly came down on the nurture side of that; rereading the slides, I’m not sure my memory is correct, but what is correct is that she claimed that nature alone is not enough: the way you get to Carnegie Hall is, indeed, to practice. Specifically: people need to practice their field for about 10,000 hours before becoming experts; and those who do eventually become experts practice longer and harder than those who don’t.

This last sentence, of course, doesn’t settle the nature or nurture debate: it may be that those who aren’t naturally gifted won’t become expert violinists no matter how long they practice. On a more meta level, it may also be the case that, without the appropriate nature, you’ll find practicing violin for 10,000 hours so offputting that you’ll give it up long before then. So it’s not clear (at least to me) to what extent nature is necessary; it does seem to be the case, however, that nurture (in the form of practicing) is necessary to become an expert, and in fact quite a bit of nurture is.

It’s not the case, however, that any old 10,000 hours of practice will do. As the title of the talk says, it should be “deliberate practice”, and Poppendieck listed four key factors in making the practice successful: a mentor, a challenge, feedback, and dedication. You want somebody else to guide you; you don’t want to be complacent; you want to know how your work is turning out; and, even with that, you need to put in the sweat. And she gave examples of how you might structure your work to support this. (Looking at it through a lean viewpoint; the slides don’t mention them, though the talk may well have, but I’ll bring up A3 reports.)

I was planning to turn this post into some sort of grand overarching pulling together of the above with some other articles that had come across my twitter feed. But, after listening to Dahl’s talk again, I’m having a hard time finding any nice symmetries. So, I’ll conclude with talking off the top of my head (as if I ever do anything else!):

Poppendieck’s recommendations don’t contradict the Aristotelian point of view: in particular, it sounds like Aristotle would wholeheartedly support having a mentor. Can we make other links: maybe Mill’s utilitarian point of view resonates with feedback, for example? Actually, I’m surprised at how hard it is to find explicit Kantian resonances with the deliberate practice model; is that a sign of something deep, or is that just a sign that the idea of having principles to guide us is to obvious as to not need stating? (As a side note, right now I’m finding the idea of following quite detailed Kantian principles in software development to be strangely appealing.)

The nature versus practice question is one that I’m interested in for both personal reasons and parental reasons. Take the question of how nature affects our practice habits: I’m a decent musician, but I was never one who was drawn to spend hour after hour after hour in practice rooms honing my art. I’m sure I could have become a better musician than I actually am, though I don’t know where my ceiling would be (if that concept even makes sense), but I do know that doing so would have required quite a bit more desire out of me. And I certainly support Poppendieck’s claim that not all practice is created equal: I’ve seen more than enough of people doing “practice” in ways that strike me as noticeably suboptimal.

As for nature and raw talent: I’ve seen enough exceptional people that I don’t believe that nature is irrelevant to becoming a world-class expert, from an outside point of view. But, from an internal point of view, it’s probably best to pretend that it is irrelevant: Poppendieck’s deliberate practice recommendations sound pretty solid to me, and I’m fairly sure that anybody following them and putting in the time would improve anybody’s skills. They also suggest a meta-approach: improve your skills at deliberate practice. Though, of course, you can’t just do that in isolation: you want to deliberately practice deliberate practice, which (among other things) means actually learning stuff.

Looking at holes in my own practice: of Poppendieck’s four recommendations, the area where I probably do worst is in finding mentors. (Indeed, in retrospect I probably should have spent rather more time acting as a mentor while managing the last few years. Sorry!) I imagine I shy away from feedback (both giving and receiving), too.

Important stuff; I hope we can all figure this out.

So I filed away their existence in the back of my brain (well, actually, in my GTD someday/maybe list) and mostly forgot about them. Not completely: at the time, I was thinking about possibly changing jobs. But my general conclusion was that I was in general rather happy with my current job, and that while I was starting to feel a bit antsy, I’d probably prefer to change jobs towards the end of 2009 than towards the middle. I sent out a few feelers at the time, but none of them paid off, so I was happy enough to shelve the issue.

It turned out, though, that one of the feelers wasn’t dead, it had just gotten buried for a bit. It resurrected itself in the middle of the summer, and shortly after that happened, I got cold-called by a recruiter who mentioned Playdom! So I sent in my resume, and went in to interview. And I’m very glad I did, they look like they’ll be a very nice match for what I’m looking for. In fact, going down the checklist from the aforementioned blog post, they hit on almost every front: a local game company working in small, cross-functional teams with very fast iterations and which would expose me to many domain and technological areas that I’m not very well steeped in yet. (No Erlang, but I can certainly live with that. It’s also not clear to me how many of the agile technical practices they use, but that’s an area where I should be able to contribute if doing so turns out to be useful; anyways, right now I’m a lot more curious to see what a fast-moving team looks like on the business side than the technical side.)

They focus on social games. Which might seem like a bad fit for me, because my taste in games is fairly traditional. Actually, though, it’s something that I’m rather excited about, for two reasons. (Or perhaps one reason with two sides?) One reason is an aesthetic one, or a cultural one: a new art medium is a gift that we should cherish, so the last thing that I want is to see it have its practitioners bore into a tiny area of the design space, ignoring vast reaches of what is possible. That is, unfortunately, exactly what several major players in the game industry have been doing over the last decade, so I’m very glad to see companies like Playdom consciously setting their sights elsewhere.

The other is perhaps the business side of the same argument: one excellent book that I’ve read recently is The Innovator’s Dilemma. (Ironically, I read it because my current boss made it sound so interesting.) The thesis of that book is that highly successful companies, exactly by doing such a good job of paying attention to their best customers, end up refining their current technologies to make them more and more appealing to the core of their customer base. As part of this, they discount customers that are on the fringes (low-margin customers, frequently with somewhat different interests); new companies can then take slightly modified (and less technologically advanced) versions of those same technologies and use them to build up a following in a new customer base. (And, more importantly, using a new value network: their suppliers, their income sources, their distributors are all different from those of established companies.) What starts as a small market soon grows to a quite respectable size: also, the companies in the new market can typically improve the quality of their technology at a faster pace than companies in the original market, so after a few years, the new companies end up making products that are technically quite adequate for the majority of customers in the original market (but with lower prices and otherwise more appealing!), which quickly spells doom for those original companies. And, as far as I can tell, Playdom looks like a textbook example of a company at the early stages of such market innovation; if they follow the course outlined in that book, the sky’s the limit.

Of course, future promise is one thing, but the question remains of how interesting their current games are. Some of their early games seemed to me more like experiments than compelling packages (though they’re experiments that many people were happy to play); within the last month, though, they launched Mobsters 2, which I’m really quite enjoying. It took me a few days to figure out how the mechanisms in the game worked, what they meant and how they interacted together; that was enough time to get me sufficiently hooked that, even though I’m in general not uncovering too much more in the mechanics, I still happily log into the game a couple of times a day to do some leveling up. (And, as I said before, they iterate quickly, so for all I know they’ll introduce interesting new mechanics next week, next month!) So if that’s what their second wave of games looks like, I have high hopes for what they’ll be producing a year or two from now.

Ironically, the one part of the game that I haven’t explored is its social aspects: I’m currently not much of a Facebook user (follow me on Twitter instead if you want to know my hour-to-hour activities), so I don’t have a big pool of friends to draw from to expand my mob. I would like to change that: if you’re a blog reader, feel free to add me as a friend; if you do so, please give the game a try and ask me to join your mob! (Do Facebook friend requests include a note? If not, and if you’re not sure I know you, just e-mail me or leave a comment or something—I’m happy to add any blog reader as a friend.)

I’ve very much enjoyed my current job: it’s been a wonderful place to spend the last few years, I’ll miss my coworkers very much, and it looks like the product is going through an exciting phase in its development right now that I wish I could see the other side of. Having said that, I’m very excited to be joining Playdom at the end of the month, and I can’t wait to see where that journey will lead me.

Which Galison takes issue with, both for conceptual and historical reasons. As he says, “When a radically new theory is introduced, we would expect experimenters to use their best-established instruments, not their unproven ones.” (p. 799) And indeed, as he discusses on pp. 811–812, when theorists were fighting over the nature of space and time, they took great care to translate their theories into terms that could be tested by the experimentalists of the time; different paradigms fought, one of them (special relativity) won, but the results were agreed to by all parties, there was no incommensurability that the notion of a paradigm shift might suggest.

So, rather than breaking at the same time, the experimental practices and theoretical practices underwent changes at different times. In fact, Galison introduces a third strand here, namely instrumentalists, with its own pattern of breaks, and several other practices (electrical engineers, the military)make a showing at various points in the book as well.

And the fact that breaks occur at different times in different strands, Galison claims, is a source of strength. One analogy to think of here is a brick wall: when you line up bricks, you want them overlapping rather than sitting directly on top of each other. That way, the weak points of one row are supported by the strong points of adjacent rows.

So: what does this have to do with agile? The first strands with breaks that come to mind are the TDD cycle. You don’t simultaneously write new code and new tests: instead, you write the test first, giving a break in the testing strand (manifesting itself as a red bar), and subsequently advance in the implementation strand (manifesting itself as that red bar changing to green). And then, of course, you refactor; I’m not sure yet if this is a break in a third strand or if it’s a further advance in the implementation strand. (For that matter, the refactoring can be an advance in the testing strand, as well.)

One special aspect of this example: while the strands don’t have their breaks at the same time, they have their breaks in close sequence, in a specific order. Is this a general property of best practice in interwoven traditions? I tend to think not; having said that, it doesn’t seem all that unnatural to me for breaks in one tradition to be followed reasonably closely by breaks in closely related traditions. So perhaps if you measure this with a sufficiently coarse granularity, these breaks look simultaneous, giving rise to the paradigm shift idea; I’m not sure.

Another example from the agile realm: iterations. Here we have breaks in the implementation, in the testing, and in the customer requests. And they’re all supposed to happen at the same time! Which looks dubious from Galison’s point of view; does that mean that Galison is wrong, that iterations are a bad idea, that I’m misreading him or stretching his analogy, or that these breaks aren’t in fact simultaneous?

It certainly seems likely that I’m stretching Galison’s analogy; having said that, I think you can also make a case that these breaks aren’t simultaneous. It’s not the case that Customers approach the planning meeting that kicks off an iteration with a blank mind: they’ve been thinking about what’s most important to work on next, and while they’ll certainly use feedback during the planning meeting to inform the details of what the team should do in the next iteration, there’s not a split in the Customer practice right before the planning meeting. And there isn’t one right after the planning meeting, either: the Customer has to spend a fair amount of time at the start of the iteration helping the rest of the team understand what that iteration’s stories means. And breaks in the testing and implementation strands don’t happen simultaneously in this example any more than they do in the TDD example.

This last case, in fact, brings us to the second point of Galison’s chapter. The chapter is titled “The Trading Zone: Coordinating Action and Belief”, and he claims that these “adjacent” strands can’t naturally talk to each other without misunderstandings. Instead, members of different strands have to work quite hard to find a way to work together that allows the two strands to learn from each other, to find a common way forward that advances both of their interests. (C.f. Star and Griesemer’s notion of boundary objects, which Galison comments favorably on in a note on page 47.) To do this, the parties develop pidgins or creoles; these languages aren’t enough to allow complete understanding between the two sides, but they are enough to let both sides agree on some amount of focused exchange.

I particularly enjoyed the example that Galison gave on pp. 820–827 of a pidgin language developed during World War II to allow theoretical physicists and electrical engineers to discuss the construction of radar and microwave devices using circuit diagrams. Returning to our programming examples: while, in the TDD case, there’s relatively little scope for misunderstanding (since the same people are doing the testing and the implementing!), we can nonetheless see unit tests as a pidgin language (or perhaps more of a creole) in this case. In fact, maybe that’s exactly the strength of unit testing: forcing a creole language into the situation sets up an explicit trading zone where one would have only been latent without that language, and in doing so it makes you aware of the split betwen the latent testing and implementing strands, increasing the strength of your work. The example of Customers, testers, and implementers working together is more clear-cut: agile suggests that the three groups spend quite a bit of time talking together, and acceptance tests give an example of a pidgin language that they can use to coordinate their activities.

And, as with the second agile example, Galison suggests reinforcing these trading zones with a shared physical space, to increase the chances that active trading will happen. The physical layout of the MIT Radiation Lab was designed to increase the amount of chatter between different groups; he gives examples of areas in later buildings designed to support particle physics research that are intended to increase the chances that members from different specialties will spend time together.

Though one aspect of agile practice that Galison’s text, to me, doesn’t clearly support is an erasing of boundaries: Galison seems happy to have these specialties to remain largely distinct, whereas the agile ideal is the concept of generalizing specialist. Or at least that’s the agile idea in the context of implementation; agile draws a particularly bright boundary between the business and implementation sides. (Though the lean tradition prefers to create an explicit bridge there in the person of the Chief Engineer.) Galison’s book is full of examples of fertile cross-pollination between disciplines, and even of individuals moving between disciplines (from meteorology to particle physics!), but the disciplines nonetheless retain their own individual character.

What should agile learn from this latter difference? I can think of two arguments in favor of breaking down such boundaries in the agile tradition: one is that it increases knowledge sharing (and the fertilization that results), and the other is that it increases resource flexibility. Galison certainly agrees with the former, but, as we’ve seen above, provides other mechanisms by which it can occur. He doesn’t, as far as I’m aware, address the latter; certainly something for me to think about in the future.

It’s an excellent book. I’ve only discussed the last chapter here, but I really enjoyed the more historical sections that preceded it. Great stories, great pictures, I found something new and interesting in every section.

As I’ve been thinking about it more, though, I’ve realized that there’s more to my unease than a philosophical distate: it turns out that I don’t have a very good answer myself to the question of why I play games! Do I play games for fun? For beauty? To learn something? For some other reason? It’s actually not at all clear to me.

And what makes this especially weird is that, even though I can’t explain why I play games, I am quite confident that I’m not playing games just out of inertia. Over the last few years, I’ve been getting more and more conscious in my choices of how I spend my time. And I’ve chosen over and over again to continue to make time to play games, even though I have enough time pressure that it would be very easy for me to stop doing so and fill up that time with other activities that I would also find very rewarding.

I’m not even doing this out of a sort of inertia once removed, e.g. because games are an entry (a few entries, actually) in my GTD projects list. GTD is a way of structuring my life to increase the chance that I’ll be able to do what I most want to do at any given moment, not something that I follow indefinitely on autopilot. Every week, I have to ask myself “is playing games really part of what I want to be doing?” And, so far, the answer has always come back “yes”. (With the occasional caveat.)

Part of the answer, I think, comes from my recent Christopher Alexander reading: he’s gotten me using the word “soul” in public, and asking myself how I feel at a fundamental level about various choices. With that in mind, it may be that the question of “why do I do X?” (for broad questions X) is becoming, to a larger and larger extent, irrelevant to me: on the one hand, perhaps I’m getting better at telling which broad choices feel right to me, and then using techniques like GTD to have me spend as much time as possible actually doing that.

But, though I’m sure there’s some truth to that, it’s not all of the answer. In particular, it’s also true that both of the influences I’ve mentioned here, GTD and Alexander, have analytical components that I’m not actively using. GTD has its horizons of focus (which I should consider taking more seriously at some point); Alexander has his characteristics of living structures. So it’s entirely possible that, if I were to apply similar techniques here, I’d be able to figure out better what makes those parts of my brain tick.

Indeed, it’s possible that I’m being somewhat disengenous by writing this post—I have, in fact, been known to spend time thinking in public about various choices that I’m making. But I’m not being completely disingenuous: I really don’t have a great explanation for why I play games (or program, or read), but at the same time that lack of an explanation isn’t giving me the slightest pause that I might be spending my time in ways that aren’t good for me.

Who knows. I suppose the most likely explanation for my lack of worries in those areas is that I’m turning into a fundamentalist, or indeed have long since done so…

Deep within the bubble chamber, the inner beryllium window had shattered along a microscopic imperfection in its surface. Splintering outward, the inner window fragments blasted open the outer beryllium window accompanied by the pressure wave of the expanding hydrogen. Within half a second, the laboratory floor was bathed with some 400 liters of turbulent, burning hydrogen. Ignited when the outer window failed, the fire burned wherever the hydrogen and air were mixed. Seconds later, a fierce explosion ripped through the laboratory, strong enough to blow the 31,000 square foot laboratory roof 10 feet into the air. As it crashed back down, roof material cascaded onto the floor and began to burn, raining down hot tar. Now other areas erupted in flames as the soft soldered joints melted in the tubes that linked large quantities of liquid petroleum gas, as well as other combustibles. (Galison, Image & Logic, pp. 356–357.)

Fortunately, it was shortly after 3am, so not many people were around, and only one person died. The most dramatic survival:

One graduate student had managed to crawl into a space between the bubble chamber electronics room and the south wall. Unable to escape further because of his injuries, he remained there until the fire seemed to be closing in. Radioing an ambulance to the east exit, the deputy fire chief, an engineer, a cryogenics expert, and some firemen hacked their way to him and brought him out on a stretcher. (p. 359)

And the end of one eyewitness report:

“I did not consider 80 PSI as extremely serious at that instant since all the peripheral systems are capable of easily handling such a pressure. At this point I turned to check the pressure in the Bubble Chamber to make sure that it was not rising excessively. I never did see the Bubble Chamber pressure gauge.” (p. 356)

Actually, I subscribed to several of the company’s series: I was pretty sure that the lowest level they offered was too basic for me, but the next five levels (going from 2-year-old through 6-year-old) all seemed plausible. So I subscribed to all five, planning to unsubscribe from the lower levels as I got more confident. In fact, I subscribed to them several months before I finished the textbook, so I had a backlog built up before I started reading any of them.

So I started working through my backlog of the 2-to-4-year-old fiction level, こどものとも年少版. (Which means something like “child’s friend early years edition”?) It was surprisingly hard, in some ways harder for me than later levels: it uses an awful lot of onomatopoeia (which Japanese uses much more than English in general), and I’m fairly sure that some of the speech forms are somewhat nonstandard parents-talking-to-kids forms rather than what I’d learned in grammar books. Fortunately, the books were totally charming, and while I wouldn’t want all books to be as repetitive as those ones are (a lot of doing the same thing on different pages with different numbers or colors or animals or whatever), it really helped me to have the same sentence structure and half of the same words to cling to while figuring out the rest of what’s on the page. And I’ve gotten a lot better at reading books in that series over the intervening months; the onomatopoeia words are even starting to stick.

Once I made it through my backlog of books at that level, I started on the next level: ちいさなこどものとも (little science’s friend?), nonfiction for 3-5 year olds. This was a great level for me: the sentences didn’t have the word usage quirks that previous level had, and the sentences were a bit more interesting while still not requiring me to look up an overwhelming number of words.

About a month ago, I made it through my backlog of those (I’d been reading one every weekend), and moved up to the next level. It’s called こどものとも年中向き (child’s friend targeted at intermediate years?), and is fiction for 4-5 year olds. And I’m enjoying the transition: the books are a bit longer than previous volumes (28 pages instead of 24 with more words to a page), but my practice from previous levels is paying off, as is my memorization practice, so they’re not taking too long. I’ve only read three books from that level so far, but they’re really quite varied: one was a regular story that confused my a lot until I realized that some of the word endings were in regional dialect; one consisted of scenes from a train station that might have fit better in the science series; and one was a counting/animal story that, honestly, probably would have fit better at an earlier level.

I’ve subscribed to but not started reading two more levels after that (one nonfiction, one fiction, both going through age 6); for now, I’m staying subscribed to the earlier levels, but I imagine at some point I’ll unsubcribe to those and add a subscription to something still more advanced. Also, for what it’s worth, all of the levels I’m subscribed to are kana-only, so my kanji practice isn’t paying off here yet. Though it’s paying off in other areas: for example, it’s kind of weird looking over at the spines of my Japanese go books and realizing that I actually recognize most of the characters I see there, even the non-go-specific ones.

I’m still listening to JapanesePod101, of course (incidentally, they just added a Chinese sister site, if you’re interested in learning Mandarin), and I’m spending a lot of time (almost certainly an unproductive proportion of time) memorizing vocabulary in general and Kanji in particular. In particular, I basically haven’t skipped a day using my memory program since it went live almost 10 months ago. (I usually use it during my lunch break at work.)

Which has been an interesting experience: in particular, at first, I ignored some of Wozniak’s suggestions, and I’ve learned that I was wrong to do so. To be clear, I don’t claim to be following any of his algorithms at all—I’m sticking with the algorithm I outlined here—but there are recommendations he makes that would apply to my algorithm that I ignored. In particular, he suggests a floor of 1.3 for the exponent; initially, I figured I’d put in a floor of 1.0 instead. But, after a few months, that turned out not to work at all: it was taking more and more time each day to review stuff because, once an item got tagged as “most difficult” (not too hard with kanji), I’d review it every single day for a month, and that clogged up fast. So I bumped the floor up to 1.2, and things got better; I then figured I should stop reinventing the wheel and bumped it up to 1.3, and I’m glad I did.

I’m also doing a better job now of following his suggestion of breaking up items into small chunks to memorize. Before, I would list all of the readings of a Kanji as one item: e.g. for the question 問 I would list the answer “もん、と（い）question, problem; と（う）matter, care about”. But now I break that up into three pairs: Q: 問, A: もん question, problem; Q: 問い, A: とい question, problem; Q: 問う, A: とう matter, care about. That has several advantages: individual items are smaller (as Wozniak recommends), I naturally focus more on the readings that are harder for me to remember, and I’m testing myself on something that actually matters when reading instead of an abstract skill. (I.e. I will encounter 問う when reading, but I will never be in a situation where it matters if I can list all the endings that you can stick after the Kanji 問.) In particular, the previous method wasn’t good at training me to tell whether, say, 上る was the reading のぼる or あがる. (It’s the former, the latter is written 上がる.)

Also, I made another Japanese-specific change while breaking up the kanji into multiple questions: I started writing the On readings (derived from Chinese) in katakana and the Kun (native Japanese) readings in hiragana. (So the answer to 問 is really モン.) It’s actually usually pretty obvious whether a reading is On or Kun, so that’s not important from a memorization point of view, but it meant that every day I was exposed to hundreds of katakana characters, so my katakana recognition speed has increased dramatically. (Incidentally, if any of you are learning Japanese, a recommendation: learn how to use your keyboard input method. Under Linux, you can convert a word to katakana by hitting F7; under OSX, by hitting control-k.)

Another surprise: I’d sort of assumed that some sort of geometric series magic would mean that I would be able to keep adding items to the database without increasing the amount of time I need to spend reviewing each day. Which, if you think about it for a minute, isn’t the case at all: e.g. if all items are at exponent 2 and I never make a mistake, then every day I need to review all the items I added yesterday, all the items added 2 days ago, all the items added 4 days ago, all the items added 8 days ago, all the items added 16 days ago, etc., and the growth here is unbounded. (Or rather, is bounded only by my lifespan!) I don’t think this is a big problem, but it might be; it does suggest that if I have too many items with small exponents then I’m in trouble. I hope that that problem will naturally ease: there’s a limit to the number of Kanji I have to memorize (I’m almost halfway through the official common usage Kanji list), and as I start reading more, I’ll get exposed to vocabulary more frequently in other contexts, which should manifest itself by the vocabulary seeming easier from the program’s point of view. We’ll see how it goes; if it gets too bad, I’ll cut down on the forced memorization and spend more of my time just reading and not worrying much about words I don’t know.

I had plans to quickly spiff up this application and make it multiuser, but that didn’t happen: basically, it became useable shockingly quickly, and I really didn’t have much of an impetus to improve it past that stage. It’s amazing what I’ve managed to leave out: for example, I assumed that I would have to implement a search functionality early on. But part of the basic Rails CRUD functionality is a URL that lists all the items, and combining that with browser search still works acceptably for search even though I’ve got over 3000 memory items listed. Or I assumed that I would have to secure it (and probably naturally add multiuser functionality as part of that) to get it useable while at work or travelling, but ssh tunnelling to an unsecure deployment was working fine for me until I got my new iPod and wanted to be able to use the program from the iPod’s web browser.

That’s changing now: aside from the iPod issue, I’ve recently gotten a bit frustrated with some UI elements, Miranda has shown some curiosity in using the program, and I just finished reading the paper version of the third edition of the Rails book. So now I’m pretty excited to start up my tinkering again! And in fact I started that last weekend (I continue to be impressed at how easy it is to write functional tests in Rails, incidentally), and I plan to continue with that on future weekends until the program looks/works a lot better. So: Jim and Praveen, I apologize for the delays, I’ll have a multiuser version available soon if you’re still interested! And anybody else who is interested, let me know; I’ll announce it here when it’s ready for use by people other than myself.

To counter these catastrophic possibilities, efforts are made to routinise component actions either through technicians’ training or by automation. Once a string of operations has been routinised, one can look at the figures obtained and quietly forget that immunology, atomic physics, statistics, and electronics actually made this figure possible. Once the data sheet has been taken to the office for discussion, one can forget the several weeks of work by technicians and the hundreds of dollars which have gone into its production. After the paper which incorporates these figures has been written, and the main result of the paper has been embodied in some new inscription device, it is easy to forget that the construction of the paper depended on material factors. The bench space will be forgotten, and the existence of laboratories will fade from consideration. Instead, “ideas,” “theories,” and “reasons” will take their place. Inscription devices thus appear to be valued on the basis of the extent to which they facilitate a swift transition from craft work to ideas. The material setting both makes possible the phenomena and is required to be easily forgotten. Without the material environment of the laboratory none of the objects could be said to exist, and yet the material environment very rarely receives mention. It is this paradox, which is an essential feature of science, that we shall now consider in more detail. (p. 69)

The production of a paper depends critically on various processes of writing and reading which can be summarised as literary inscription. The function of literary inscription is the successful persuasion of readers, but the readers are only fully convinced when all sources of persuasion seem to have disappeared. In other words, the various operations of writing and reading which sustain an argument are seen by participants to be largely irrelevant to “facts,” which emerge solely by virtue of these same operations. There is, then, an essential congruence between a “fact” and the successful operation of various processes of literary inscription. A text or statement can thus be read as “containing” or “being about a fact” when readers are sufficiently convinced that there is no debate about it and the processes of literary inscription are forgotten. Conversely, one way of undercutting the “facticity” of a statement is by drawing attention to the (mere) processes of literary inscription which make the fact possible. (p. 76)

A fact only becomes such when it loses all temporal qualifications and becomes incorporated into a large body of knowledge drawn by others. Consequently, there is an essential difficulty associated with writing the history of a fact: it has, by definition, lost all historical reference. (p. 106)

Can we profit from focusing on objects/processes that “facilitate a swift transition from craft work to ideas”? I spent a few pleasant hours this afternoon doing some Rails programming; that framework shines because of the small amount of craft work necessarily to see a manifestation of your ideas. Does a software framework count as an “inscription device”? Does a programming language? Does a compiler, an interpreter? If not, is there some generalization of that concept that we can use here?

Agile processes value a swift transition between the programmer’s craft work and the Customer’s ideas. (A transition in both directions, I should add.) What are the inscription devices here? Ironically, one of the key mechanisms that agile uses to speed this transition is to remove certain inscription devices, or at least inscriptions, in favor of people talking directly to each other.

Can we relate tests to inscriptions and inscription devices? Test runs can certainly lead to thousands, millions of inscriptions over the course of a day; most of those inscriptions are internal, in that the software is noting that an assertion passed, but I label them as inscriptions nonetheless. They’re a very good form of persuasion; if you’re on a project where test runs act as a reliable safety net, then your worry level decreases, you can treat the software’s behavior as a “fact”, and spend time in idea land. Until, of course, a test failure (or, much worse, a failure that your tests didn’t catch) undercuts your software’s facticity.

I’ve been pretty obsessed with A3 reports for the last few months, which are certainly a form of inscription. And one of the strengths of the process is the extent to which the A3 report doesn’t serve as a source of persuasion, the extent to which the “sources of persuasion seem to have disappeared”: if the process is doing well, it’s a summary of facts to which all participants agree. Or have the sources of persuasion disappeared? Perhaps better to say they’ve been distilled down to a trace, as with a scientific paper; I don’t want to underestimate the importance of that trace.

I don’t suppose I can relate this to video games somehow? One issue that I struggle with, especially in games with a large variety of techniques to reach a goal, is how to internalize the various gameplay options that are available to me. Most of the time, I end up leaning on a few standard ways of progressing through a game’s levels; I suspect my experience would be richer if I had a broader tapestry of “facts” to choose from in the form of live tactical (or, better yet, strategic) options. What can games do to help me reach this state? What inscriptions can they present me with to ease this journey? How can I modify my own play styles to reach this state?

And in all this that I observe, when I talk to politicians, to townspeople, to developers, when I watch the reaction in the newspapers, when I observe the studied (and to me frightening) neutrality of the journalist preparing to write his story, the most frightening thing of all is the loss that people have of their own feeling.

They no longer know what is inside them, they no longer know what they do know. That is the birthright I refer to, that is the birthright which is being lost.

The birthright being lost is not only the beautiful Earth, the lovely buildings people made in ancient times, the possibility of beauty and living structure all around. The birthright I speak of is something far more terrible; it is the fact that people have become inured to ugliness, that they accept the ravages of developers without even knowing that anything is wrong. In short, it is their own minds they have lost, the core, that core of them, from which judgment can be made, the inner knowledge of what it is to be a person, the knowledge of right and wrong, of beautiful and ugliness, of life and deadness.

And since this inner voice is lost, stilled, muffled, there is no possibility—or hardly any possibility—that they can cry out, “Oh stop this ugliness, stop this deadness which floods like a tide over the land.” They cannot do that successfully, too often they cannot even cry out, or let the cry be heard, because the source of such a cry has almost been stilled in them.

(A Vision of a Living World, pp. 681–682)

Reading The Alchemy has done nothing to lessen my suspicion that the color volumes of Kabuki are the most beautiful comics in existence. This volume is perhaps less so than, say, the fifth volume, but that’s okay: its style fits in with this volume’s experimentation, the way it puts together sometimes simpler fragments in unexpected ways.

I’m not sure what I expected this volume to be like, but I’m quite sure I never would have imagined how it actually turned out. Which is good: the series could easily have fallen into a rut, as an action series about beautiful women fighting crime. Instead, it took a fairly large turn away from that; the main worry that I have now is that the series will go too far into megalomania, in the “grand theory of everything” direction.

Or maybe not; for all I know, this is going to be the last volume of the series. Which is fine with me; I have a hard time seeing how Kabuki’s story is going to develop further, and while I wouldn’t be against individual volumes about the other agents, I wouldn’t want to see that at the expense of the main story. Then again, David Mack clearly has more imagination about how to develop Kabuki’s story than I do; if more volumes do appear, I’ll be first in line to buy them. But if he decides to work on something else instead, that’s great too.

Anybody read any of his Daredevil volumes? Are they anywhere near as interesting or visually stunning as these ones?

Mass Effect was a fabulous game, but it had problems. Elevators are one example; also, the world where you found Liara was once intended to be the same length as the other key worlds, but they ran into late issues that they couldn’t solve in time. There was costly, unplanned rework; insufficient cross-department communication; and performance issues that they couldn’t iron out in the final product. One factor contributing to several of the problems was that levels were rarely playable: this made it difficult to evaluate the game and its mechanics, it made QA testing quite difficult, it lead to late revision instead of early revision. So they wanted to do better in Mass Effect 2.

To fix these problems, they broke down the work on each level in the sequel into six phases; each phase was designed to answer a specific question, you were supposed to avoid any work that didn’t bear on that question, and the end result of each phase was a deliverable that bears specifically on that question. In addition, they had three ground rules: they game should always be playable, the current stage should always be a foundation for future work, and the game should always have acceptable performance.

The stages:

• Stage 0: Narrative Overview. This stage is answering the question “What is the story?”, and the deliverable is a document describing the narrative, the characters, the 2D layout, the art themes, and the cutscenes. This stage is different from the others (hence the numbering) in that it largely involves the writers rather than the full team and in that there’s nothing playable at the end of it.
• Stage 1: Narrative Playable. The question: “Is the pacing and spacing good?”; the deliverable is the first playable. At this stage, the level only contains its box-level geometry, placeholder set pieces, and “box level” dialogs (i.e. saying “X will tell Y to do A, B, C” rather than the actual words that X will use); there are pop-up cutscenes, and prototype level mechanics. But it’s still enough to get a feel for what’s going on, and an awful lot gets changed at this stage. In fact, this can even be enough to get a global overview rather than a local overview: over Christmas, team members took the game home, even though many of the levels were at stage 1, and discovered that, while the endgame felt fine in isolation, it didn’t work well in the context of the whole story. Which led to significant rethinking, but it’s much less costly to do that rethinking at this stage than later on, or to not do that rethinking at all.
• Stage 2: White Box. The question: “Can you see the fun?”; the deliverable is a level with representatitive collision. You have first-past modeling on the geometry, and a first pass at the dialog. There’s basic placement of cover for the combat scenes, and animatronic cutscenes. And there’s placeholder music: without that, levels felt blah, leading to criticisms that, in retrospect, weren’t well-founded.
• Stage 3: Orange Box. The question: “Is it fun?”; the deliverable is a level with actual collision. The textures aren’t all there, yet, but it’s working; the dialogs are ready for voice acting and are cinematically blocked out; there’s full cover placement for combat; and they’ve done the basic motion capture for the cut scenes.
• Stage 4: Hardening. The question: “Could this be shipped?”: they’d rather not ship the level like that, but if the rest of the game was polished and a deadline was coming up, they could ship the game with a level in this stage. The deliverable is a “finished level”: the level art is textured and lit, the voice-over dialogue has been recorded, and unfortunately I didn’t managed to take notes about what the other aspects of the level should look like. But you get the idea, I hope.
• Stage 5: Finishing. The question: “Can you feel the awesome?”; the deliverable is the final shipping level.

After this, they talked more about some of the lean principles. They avoid muda (waste) by only doing work that they’re willing to iterate upon. They avoid muri (overburdening) by time-boxing and load balancing. (But they don’t load balance across teams.) They avoid mura (variation) by having established deliverables at each phase. They do kaizen (continuous improvement) with level reviews at each phase, with peer reviews (once per level, at the phase in which that department’s work should be final), and they have level design mindshare meetings weekly.

In general, they use a scrum-like process, but not completely; in particular, the individual components (art, cutscenes, modeling, etc.) didn’t always proceed in lock-step, so they felt that sticking too rigorously to sprint goals slowed them down. This is one difference from a pure software development context: in software development, it’s frequently reasonable to have enough cross-training that everybody can swarm on unfinished tasks, whereas a writer is unlikely to be able to help with cinematic rendering. They do have final reviews by the product owner, preceded by at-desk previews; this is a creative signoff, and makes sure that the next steps are clear.

What worked:

• Pairing level art with level design.
• Colocated teams.
• Time boxing.
• Going deep with some levels: rather than doing stage 1 on all levels before going to stage 2 on any, they finished a few levels much earlier than others. Among other things, this helped make sure that the process worked, and improved the quality of their estimates.
• Testing out the combat systems in game.
• Evaluating levels in sections, as necessary.
• Being agile with their Agile process.
• Stopping to assess the big picture.
• Having different goals in different phases. For example, each stage’s question let QA know what bugs can be legitimately filed at a given stage; incidentally, one of the stage exit criteria is that they can’t have any bugs at major severity or higher.

What didn’t work:

• Sometimes, they skipped a step; it came back to bite them.
• Not every level can be a “special snowflake”.
• Level teams that got too big.
• Creatures need to be “representative” early: it’s hard to build a space around a creature if you don’t know what it looks like, how it will fight, how big it is.

That’s my notes from the presentation. What I found most exciting about the talk (other than its heavy lean focus) was the intelligent questions that they used to differentiate stages. In a lot of the agile software literature, you’re told that you not only can but should ship your software frequently (weekly, daily, hourly), leading to a feeling that there’s a lack of texture in the development process. But that simply won’t work for a long narrative project like this. You can imagine breaking the game up into smaller episodes (c.f. their point about going deep on some levels), but nothing that gets you close to a weekly ship cycle. And I think it’s not a coincidence that they went beyond agile to lean in their inspirations: Toyota also has people working on a project with significantly different skills (somebody designing the shape of the body of a car won’t be able to contribute meaningfully to refining the engine), and Toyota is unlikely to have a genuinely shippable car at many of the stages in their design process.

So what they did was keep the core of that “constantly shippable” idea (indeed, they heartily embraced the core, getting huge amounts of mileage out of it), in that the game was always playable and performant; but they explicitly iterated up to a releasable version instead of pretending that the game could always be releasable. And they turned this into a further strength by combining it with the notion of mura: the focused questions for the stages of the iteration turned into a very powerful tool for the elimination of waste.

Of course, their questions, while applicable to many projects, won’t be applicable to all situations. In particular, this game is a sequel, which reduces the scope of the experiments that you’ll want to perform. And they were very up-front about this: when asked if this process would have worked on the original Mass Effect, they answered that yes, they felt that the process would have worked, but the questions would be different.

Which raises the issue of how you come up with the questions that will fit your situation? Further combining my obsessions, I’m wondering if Christopher Alexander’s The Nature of Order might give us some ideas. The second volume is all about growing your structures by amplifying centers, which seems to me to be quite consistent with this sort of phased process; I’ve just started reading the third volume, and I’m cautiously optimistic that some of the worked out examples there of how designs got fleshed out might give some insight into how to structure the specifics of this sort of iteration, how to give up on the notion of a product being always releasable without slipping back into Big Design Up Front.

That last paragraph is probably pretty unlikely; I really don’t have enough of a feel for how, or even if, Alexander’s techniques work in practice to know if they can be turned into concrete guidance like this. Something to dream about, though; certainly this talk was a fascinating talk and a wonderful end to the conference.

• My favorite new blog: Dear Planetary Astronomer Mike. Learn about the history of the earth, or Pluto’s status as a planet.
• An excellent Rock Band story. (I agree with the post that the comment is attached to as well, of course.)
• A cool multimedia take on Borges’s “The Garden of Forking Paths”.
• A particularly good optical illusion, from a blog full of them.

• I’ve been meaning to do a longer response to this video by Shamus Young on why the difficult level in the new Prince of Persia game is so important, but I don’t seem to be getting around to it, so I’ll at least link to it here.

• I am now convinced that I have to play Mother 3.
• The Princess Rescuing Application: how game design might teach us to design better applications.
• The latest Brainy Gamer podcast had a very interesting interview with a couple of the people behind Flower.(And yes, though it feels ridiculous, it seems increasingly likely that I’ll be buying a four-hundred dollar game console primarily to play a couple of downloadable five/ten buck games.)
• I don’t generally have any interest in the “games as art” discussion (largely because many of the answers are so obvious; see the Rock Band post linked to above for another example of a discussion that I’m similarly bored with), but this post was worth reading.

• A dot-matrix printer in Conway’s game of Life:

• Ben Abraham just finished an excellent interview series with Marty O’Donnell on video game music: here’s the first part, and here’s a search for all the parts.
• A soothing, meditative game.
• Right vs. effective.
• A pair of thoughts on choices in games.

His book begins as a reaction against the split between nature and society, the split between facts and values. He sees in this split a misplaced polemicism: if, for example, these two worlds are separated by a vast gulf, then how is it that scientists, as members of society, manage (quite successfully!) to understand the workings of nature? In place of this split (the “old bicameralism”), Latour proposes a new split (the “new bicameralism”), between the “power to take into account” and the “power to arrange in rank order”.

This isn’t to say that Latour finds the old bicameralism to be completely useless: in particular, he uses both bicameralisms at once to create four quadrants, leading to four requirements, which are, in (temporal) order, “perplexity”, “consultation”, “hierarchy”, and “institution”. The first and last are related to the concept of nature from the old bicameralism, while the middle two are related to society; in the new bicameralism, the first two form the power to take into account, while the last two form the power to arrange in rank order.

To these four requirements, Latour adds two further functions: the separation of powers actively maintains the new bicameralism, the scenarization of the totality works to unify the resulting collective. Finally, the seventh function is the power to follow up, which reminds us that this is an ongoing process rather than a one-time activity that will analyze the world once and for all.

To make these seven functions more concrete, Latour discusses each of them in the context of various professions (scientists, politicians, economists, moralists, administrators); some professions are more associated with one side or the other of the old bicameralism, while some straddle the boundary. I’ll devote one section to each of the functions, giving a brief explanation of that function, a summary of how each of those professions contributes to that function, and ending with a discussion of how that function might be viewed in an agile context.

The Requirement of Perplexity

The first requirement is the requirement of perplexity, also known as the requirement of external reality. It says that “you shall not simplify the number of propositions to be taken into account in the discussion” (p. 109); or “First, the number of candidate entities must not be arbitrarily reduced in the interests of facility or convenience. In other words, nothing must stifle too quickly the perplexity into which the agents find themselves plunged, owing to the emergence of new beings.” (p. 110) In the old bicameralism, it was part of the notion of nature, while in the new bicameralism, it is part of the power to take into account.

Scientists bring to this requirement their remarkable ability to create speech prostheses: they’re wonderfully capable of creating instruments that allow us to be perplexed by the behavior of entities (or candidate propositions, if you like) whose existence we didn’t even suspect a few years prior. Politicians bring their sense of danger to this requirement: if they ignore the wrong people, the wrong facts, they may find themselves out of a job and disgraced before they know it. Economists are particularly sensitive to attachments between humans and nonhumans, increasing the ties between the two as a result. Moralists continually go outside the collective, actively attempting to ensure that those previously excluded have their say. And administrators can keep track of external reality over long periods of time, enabling us to be perplexed by phenomena that we might otherwise miss.

In an agile context, the first thing that the requirement of perplexity brings to mind is tests. An unexpected red bar is a wonderful example of perplexity, a reminder that our intentions of what the software should do aren’t always matched by reality. Like scientists, agilists go out of their way to build pervasive networks of speech prostheses in the form of comprehensive automated test suites. Though there is more to testing than automated tests: perhaps recent discussions of exploratory testing in the community are a reminder of the role of moralists, that we should actively look for the excluded.

Like politicians, agilists also have to have a sense of danger: if what we implement isn’t what potential users want, then we’ll be out of a job. The Customer role is our main defense here: like tests, Customers are a speech prosthesis, this time speaking for humans rather than nonhumans.

The Requirement of Consultation

The second requirement is the requirement of consultation, also known as the requirement of relevance. It says that “You shall make sure that the number of voices that participate in the articulation of propositions is not arbitrarily short-circuited.” (p. 109) Alternatively, “the number of those which participate in this process of perplexing must not itself be limited too quickly or too arbitrarily. The discussion would of course be accelerated, but its outcome would become too easy. It would lack broader consultation, the only form capable of verifying the importance and the qualification of the new entities. On the contrary, it is necessary to make sure that reliable witnesses, assured opinions, credible spokespersons have been summoned up, thanks to a long effort of investigation and provocation (in the etymological sense of “production of voices”).” (p. 110) In the old bicameralism, it was part of the notion of society, while in the new bicameralism, is is part of the power to take into account.

Scientists consult their colleagues through a process of peer review, and ease this consultation through descriptions of their experiments that are precise enough to be replicable. Politicians can really shine here, discussing matters with a whole range of people and groups who might be affected my the matter at hand. Economists can use their practice of attaching a value to interactions to smoke out stakeholders that might be ignored otherwise. Moralists can make sure that the people who are affected by a problem get to chime in, instead of leaving decisions solely up to the traditional powers that be. And administrators help ensure appropriate consultation by verifying the credentials of those wishing to participate.

And agilists? Certainly having a Customer make the business decisions is a big step up from, say, having engineers make those decisions. Of course, you don’t want the business side to go so far as to make decisions without appropriately consulting the engineering side; to that end, having the engineering team in charge of primarily technical decisions is probably consistent with this requirement. In general, I think collective code ownership is aligned with this requirement as well: given that database changes affect everybody working with the data, for example, you don’t want to give a DBA magical powers over them. And retrospectives give a forum where the whole team can be consulted on areas that matter to all of them.

Having said that, I’m not entirely comfortable that the agile role of a Customer does adequate justice to the requirement of perplexity. There are a lot of people outside the engineering team who will be affected by non-engineering design decisions; putting all of them behind a single Customer point of decision doesn’t fit the requirement of relevance, to me. I’m not saying that having a single Customer decision maker is bad—this requirement doesn’t mean that everybody has to have a direct say in every decision, just that they have to be consulted—but there’s a whole lot of consulting that has to go on behind the Customer’s decisions to fit this requirement. And agile is neutral on that: a non-consulting Customer is just as consistent with agile practices than a broadly-consulting one.

The Requirement of Hierarchy

The third requirement is the requirement of hierarchy, also known as the requirement of publicity. It says that “you shall discuss the compatibility of new propositions with those which are already instituted, in such a way as to maintain them all in the same common world that will give them their legitimate place” (p. 109), or that “no new entity can be accepted in the common world without concern for its compatibility with those which already have their place there. It is forbidden, for example, to banish all the secondary qualities by an ultimatum, on the pretext that one already possesses the primary qualities that have become, without due process, the only ingredients of the common world. An explicit work of hierarchization through compromise and accommodation makes it possible to take in, as it were, the novelty of the beings that the work of taking into account would risk multiplying.” (p. 110) In the old bicameralism, it was part of the notion of society, while in the new bicameralism, is is part of the power to arrange in rank order.

The example that Latour gives of this requirement for scientists is their ability to come up with potential compromises through innovations: pig organs might give a way around some of the moral concerns pitting human transplant recipients against their potential donors. If I’m understanding the requirement correctly, scientists also have examples within their own discipline: if you’re trying to overthrow an existing theory, you have to treat the phenomena that it can explain with appropriate respect. Politicians satisfy this requirement in a more straightforward method: they must always compromise in order to get bills passed, to have the government continue to run. Economists can make a whole range of phenomena commensurable, by discussing them in financial terms. The very process of moralizing involves establishing a hierarchy, making judgments of how entities fit into a common framework. And administrators have recorded the previous hierarchization decisions, giving us the framework to enable us to discuss the new hierarchization.

The first agile example that comes to mind here is the existence of your test suite, thought of as regression tests: that’s a very stark example of new entities having to show concern for existing entities. They don’t mean that the world is rigid, that existing features can never change; but if you want to make a change, you’ll have a red bar which you’ll have to explicitly decide how to turn green again. I suspect that the notion that the Customer decides business issues while developers decide engineering issues is consistent with this requirement; certainly the idea that you have a single linearly-ordered stack of incoming stories to implement is. Perhaps Kent Beck’s rules of simple design could also be seen through this prism?

The Requirement of Institution

The fourth requirement is the requirement of institution, also known as the requirement of closure. It says that “Once the propositions have been instituted, you shall no longer question their legitimate presence at the heart of collective life” (p. 109), or that “once the discussion is closed and a hierarchy established, the discussion must not be reopened, and one must be able to use the obvious presence of these states of the world as indisputable premises for all the reasoning to come. Without this requirement of institution, the discussion would never come to an end, and one would never succeed in knowing in what common, self-evident, certain world collective life ought to take place.” (p. 111) In the old bicameralism, it was part of the notion of “fact”; in the new bicameralism, it’s part of the power to arrange in rank order.

Scientists are very good at instituting propositions, at reaching a consensus on a theory and then building upon it. Politicians institute the results of their work in the form of laws; they are willing to bring closure by making enemies instead of trying to keep everybody their friend. Economists document the results of their deliberations in the form of measurements and calculations which can be used to make further decisions. Moralists, perhaps, help us understand the boundaries of institution through their concern for those who are left on the outside. And administrators ensure that the procedures are followed so that the institution happens according to due process.

Agilists have a few tools in this regard. The Scrum notion that you can’t add anything to a sprint once it’s begun is a form of closure, as is the existence of a Customer who has final say on business matters. The existence of an acceptance test suite that isn’t allowed to go red is a manifestation of institution. And agile teams generally have a specific process that they follow (perhaps one of the standard processes combined with local adaptations); that process, together with the idea that you can only alter it through an explicit process (retrospectives, typically) also brings closure to discussions of what to do, instituting the results.

Separation of Powers

The first four functions led us through the process of constructing the collective, leading through the quadrants that were formed by analyzing candidate propositions both through the old bicameralism (facts versus values) and the new bicameralism (the power to take into account and the power to arrange in rank order). The fifth function focuses explicitly on this new bicameralism: it is the separation of powers, “the maintenance of the separation or shuttle between the power to take into account and the power to put in order.” (p. 137)

Scientists bring to this function their tradition of autonomy: you can’t ignore something because it’s not part of the current version of the collective. The very notion of separation of powers comes from the political tradition. Economists are a bit harder to analyze in these terms; Latour’s claim is that their extreme simplifications of attachments between entities helps preserve this separation of powers, but I don’t completely understand his argument. Moralists emphasize the relation between the two houses by concentrating on the shuttle between them rather than the separation: decisions made in the ordering will have effects that we’ll have to take into account. And administrators will be unable to effectively coordinate activities and ensure that proper procedures are followed unless they keep track of which actions are within the one house, which within the other.

Agilists have several rhythms that, I think, fit well into this separation. Perhaps the red bar could be thought of as within the power to take into account, refactoring could be thought of as arranging in rank ordering, and the green bar is the shuttle from the first house to the second? Frequent releases are part of the shuttle from the second house back to the first. I mentioned the Scrum notion that you can’t add anything to an iteration once it’s begun back with the forth requirement (that of closure), but perhaps it fits better here, as part of the separation of powers? At first I thought that the customer / engineering split was part of this separation of powers, but now I’m dubious about that: it’s a separation of powers, certainly, but I don’t think it’s this one, because I don’t think either the Customer or the developers fit in one or the other of the houses.

Scenarization of the Totality

The sixth function is that of scenarization of the totality: “instead of starting from an already-constituted unity (nature or society), the various skills (of the sciences, politics, government, and so on) propose scenarios of unification that are all provisional and that the reconsideration of the collective will quickly make obsolete”. (pp. 248–249)

Scientists package all their individual findings into grand theories, grand narratives, happily rewriting past discoveries into a new narrative structure based on their latest understanding. Politicians are at their most effective when using a narrative that resonates with as many people as possible. Economists provide a scenario for the collective through their model of interactions, through what that model takes into account and what it excludes. Moralists I have a harder time with; my first inclination is that their grand moral statements provide scenarios, but Latour suggests that I’m misreading the intent of this function, giving them instead a role similar to their role in the requirement of closure, as a sort of loyal opposition to the very idea. And unless I’m missing something, Latour doesn’t even propose a role for administrators in this sixth function.

For agilists, that most obscure XP practice of Metaphor is doubtless relevant here. I suspect that refactoring as a whole is: for example, ensuring that each relevant concept lives in one and only one place in the code is a miniature bit of scenarization here. And I suspect that there’s a gap here in agile practices on the Customer side: an effective scenarization is an essential part in presenting your product to its buyers and users, as is the ability to change scenarios as the product evolves.

The Power to Follow up

The seventh and last function is the power to follow up. The journey through the first four requirements isn’t a one-time thing, leading to a collective that has reached its final form. Instead, the resulting collective is a provisional construct, and those placed outside the collective at the end (“enemies”) are there to perplex us, kicking off a new round in which they are candidate members of the perspective at the end of the next cycle.

Scientists bring to this the notion of a research front: the end of one experiment and its analysis suggests many more candidate experiments to carry out. Politicians bring an awareness of changing power relationships: the slogans that got them to power may be as likely to disgrace them two years later. Economists continuously measure the health of a system, its booms and busts and the shifts from one area of the economy to another. Moralists are always on the lookout for areas where we aren’t living up to our ideals, are seeking to represent those who have been previously excluded. And administrators bring continuity to this whole process, making sure that we follow up according to our protocols.

For agilists, this power is embodied in the concept of the iteration or, more generally, the various cycles (minute by minute, hour by hour, day by day, week by week) that pervade an agile product. We know as well as anybody that all decisions are provisional: the code that we write to get a test to pass this minute may look quite different fifteen minutes later after we’ve gotten another five tests to pass. The candidate features that have been excluded from this sprint may well be added to the next sprint; alternatively, our experiences over the course of this sprint may bring new candidate features to the fore that we hadn’t dreamed of a day ago. The composition of the collective is constantly in flux: the release that users are using today will differ, perhaps subtly and perhaps remarkably, from the release that they’ll use next month, next week, or at times even an hour from now.

This power is also at the core of the agile desire for clean code. We know that we’ll be going through this process many more times; we want to make sure that our pace through this process doesn’t slow, that our power to follow up doesn’t weaken. More subtly, the agile obsession with the notion of “done” plays into this power: we want to know when we’re following up and when we’re going through the various requirements, and the sharp boundary of doneness is an essential tool in that regard.

Final Thoughts

Looking back through the previous sections, in general I think agile comes off pretty well. Our tests serve us well right at the start, by giving us speech prostheses to detect entities that would otherwise be hidden within the software, and they also assist with the requirements of hierarchy and institution. And our appreciation of the power of iteration is an excellent embodiment of the power to follow up.

There are gaps, however. In particular, I think we’re weaker than we could be when it comes to the requirement of consultation: having genuine customer involvement is much better than having developers make business decisions on their own, and having the developers use velocity as a metric to inform the pace of development is much better than having a product manager try to decide both what goes into the product and the date at which the product will be released. But the idea that a single Customer makes all business decisions is a mockery of the notion of consultation, of seeking out appropriate spokespeople; while nothing forbids the Customer from consulting appropriately, surely we could give more assistance in that regard?

Looking through the examples that Latour gives from other professions, I wonder what agile could learn from them. I think we’ve done a reasonable job at learning from scientists, and even from some of the other professions (e.g. our focus on a few key metrics has something to do with the virtues that economists bring to this enterprise), but not from all of them. In particular, I suspect that digging into the contributions of politicians would be fruitful: like politicians, we have to win a contest by successfully navigating the desires of various interest groups (both internal and internal), so perhaps we should pay more attention to their skills.

As always, I suspect that lean has much to teach us. The single Product Owner doesn’t bother me in the way that the single Customer does, because the Product Owner’s role is symmetric across business and engineering. Set-based development is one answer to the requirement of consultation: it helps ensure that we don’t cut off discussion prematurely. Going to the gemba comes straight out of that requirement: if you’re perplexed about something, go to where that something exists, consulting with both humans and nonhumans who are located there.