The other thing I discovered today: if you want to zoom when taking pictures on your iPhone, you have to buy a third-party application. It’s only digital zoom, of course, but it’s still convenient to be able to do that right on the phone so you can read pictures of the slides easily right there.

Today’s notes:

10am: How Friends Change Everything, by Gareth Davis

He’s Facebook’s platform manager; mostly Facebook boosterism and stuff that’s not too surprising to those in the social games business, but pleasant enough. As he notes, Facebook is interesting because it puts front and center the possibility of game interaction with people who aren’t essentially anonymous / pseudonymous (as is the place when playing strangers on XBLA); the idea of games being social in that sense goes back thousands of years, so in that light maybe Facebook games should be considered normal, while video games’ relatively brief history is the exception?

To that end, he thinks that the iconic Facebook game is still ahead of us, and that we should expect to have multiple games with over 100 million players; both of which I quite agree with (there’s certainly no reason to think that FarmVille isn’t going to be surpassed multiple times over. And, of course, he thinks that Facebook will be at the center of social gaming; hard to argue with him, for the time being.

11:15 am: The State of Social Gaming: Industry Overview and Update, by Justin Smith

He’s from Inside Network, which publishes web sites like Inside Social Games and Inside Facebook. The talk was what the title suggests; so, for better or for worse, nothing here that I noticed that I wasn’t already basically familiar with.

11:45 am: Open Source Secrets: The Software Architecture Behind a Successful Virtual Goods Business, by Timothy Fitz.

He’s the technical lead at IMVU, and I found this talk hugely refreshing: an ode to continuous deployment and the testing and refactoring that makes this possible. They have a thick client that they push new versions of once or twice a day, and they update their website 35-50 times a day (though only pushing changes out to ten percent of users); so their cycle is “commit, go green, push, repeat”.

They learned this lesson the hard way; they once worked on a release for two and a half months. Fortunately, they did A/B testing when they did finally release it, which revealed a serious problem in chat functionality; it took them an additional 6 weeks to figure out what went wrong, because two or three minor changes interacted in unexpected ways to produce a bad effect. Oops. So they don’t want to have to go through that again.

Their heavy emphasis on automated testing doesn’t mean that they don’t like manual QA: instead, they want the QA people to use their brains, instead of acting as robots. So QA people think about how to test features (which engineers then automate), and they work to understand the impact of planned changes in interfaces; automated tests work to catch unplanned interface changes.

The title comes from the way they build their client: they realized that they have a lot of good UI experience on the web, so they build on that by embedding Firefox in their client, with custom C++ code only in one narrowly defined area. They have significant amounts of code in each of C++, Python, and JavaScript, and they find this works better for them than a single-language strategy.

1:45 pm: Why Are Gaming Veterans Flocking to Social Gaming?

This was a panel discussion between Steve Meretzky, Brenda Brathwaite, Brian Reynolds, and Noah Falstein. Quite pleasant to listen to; two themes that repeated themselves were: 1) they all missed times when games could be developed quickly by small teams, and see social games as recapturing some of that, and 2) if you’ve been in the industry for more than two decades, you’ve gone through a lot of changes, and this is another one of those; so having veterans around is valuable for that reason alone.

They didn’t have any crystal balls or anything, just a pleasant chat. One of the more amusing lines: Brenda Brathwaite saying that, now, with the emergence of metrics, game design has finally become a game for game designers!

3 pm: What Social Games Can Learn From Virtual Worlds, by Mike Goslin.

He’s the VP of product development at Hangout, and also has Disney theme park experience. His first claim is that retention is key: it increases lifetime value in obvious ways (lifetime increases) and slightly less obvious ways (people get drawn to status items and subscriptions), and decreases cost of acquisition (virality works better over time, better to invite fewer people over a longer time than to spam everybody you know at once). He thinks that concurrency leading to a sense of community is important; it certainly seems to be something that Hangout is betting on, and something that Facebook games so far have generally stayed away of. (Wild Ones being an exception here.) They actually use Unity instead of Flash, another exception, and they have games that are gateways to a chat / community area.

As to the title: social games have the advantage that player registration is very easy (because Facebook handles that), but getting players to monetize is harder than in virtual worlds. To that end, he made a push for subscriptions: not as requirements for players (the way World of Warcraft does it), but as an additional layer on top of virtual goods to increase core players’ commitment and to give them a way to get VIP accessories. (Hangout has a fashion show theme, so the latter probably works well there.)

4:15 pm: Increasing Our Reach: Designing To Grab and Retain Players, by Randy Smith.

I really enjoyed the talk he gave last year on “helping your players feel smart”, so I figured I’d see what he had to say this year. And it was my favorite talk of the day, though I certainly won’t be able to do it justice here: basically, making the point that games have to work at immediacy (make the first 10 minutes awesome to draw players in) as well as depth (to keep players satisfied over time). And he went through a bunch of games (which I want to play now) showing how they did well or badly on one or both of these.

For immediacy: provide a “game-toy” as a player’s initial experience. This should package up the game’s core ideas in a way that’s as fun to play as possible: have simple, intuitive controls; have strong, juicy affordances; and make it hard to fail, lowering the pressure. For depth: provide it on demand, so players can go into games as deeply as they wish but don’t have it forced on them; provide hints to players for depth that they might not otherwise notice (e.g. completion stats on a level, achievements suggesting things to try out); and have both low-level tactical gameplay loops and mid-level strategic loops.

He talks fast. I hope he’ll put his slides up somewhere?

5:15 pm: AI Developers Rant!

Insufficiently ranty; a bit of completely gratuitous guy culture, and a Bourdieu reference that might lead to something interesting. I napped through parts of it.

So I dutifully arranged my gameplay schedule so that I could get a copy of Mass Effect 2 on launch (which is rare for me, I only do that a couple of times a year); and again: great game. Possibly with a bit more to think about this time; we’ll see whether or not my brain returns to the game much over the coming months.

My first question: what effects of the aforementioned talk can we see in the final product? On a basic level, they seem to have executed solidly: the performance problems from the first game are gone (there are twisting corridors in some of the levels that exist only to allow upcoming areas to stream in, but they’re never long enough to be annoying), and the sequel was released two years and two months after the original, which suggests that they only had a slight slip in their schedule. In fact, they may not have slipped at all—BioWare released Dragon Age in the fall 2009 release slot, and they certainly wouldn’t have wanted to release two games right at the same time, so for all I know both games were in a releasable state and they just went with Dragon Age. I certainly never believed originally that all three games were going to appear on the same console, but now it seems quite likely that I was mistaken: this console generation is in no hurry to end, the Mass Effect team is getting a lot of mileage out of having your character’s decisions persist from one game to the next, and they’ve shown that they can produce a game in the series in a couple of years. So: chalk up one success for lean!

I also suspect that the iterative process that they use affected this game at a fairly basic plot level. If I wanted to make sure to hit a schedule in a video game, I would put in levels with the most important plot points that my best guess was that I could implement in half of my time budget; and then I’d add smaller (but still substantial!) chunks of additional material to fill up whatever time was left after I actually got done with the key parts. They didn’t do this with the original game, with the result that the game didn’t run smoothly and they had to make a substantial cut to their original vision in the world where you find Liara. In the sequel, in contrast, much of the game involves picking up a sequence of new characters, any of which could have been cut without leaving a noticeable gap; indeed, the presence of areas on the Normandy that should contain rooms but that are instead sealed off strongly suggests that they’ve plotted out further characters, though I don’t know whether they were part of the original vision or were always planned as DLC.

Furthermore, each of the characters contributes two missions to the plot: the mission where you originally recruit them and their loyalty mission; so, if they ran short on time, they could have jettisoned one of those missions without leaving a huge hole. Which is, I assume, what happened with Zaeed: he only has a loyalty mission, but no recruitment mission (and he also doesn’t have a full dialogue tree on ship), so my guess is that there’s a document somewhere describing a planned recruitment mission, but they simply didn’t have time to finish that for the launch date. So they put in the loyalty mission and packaged him as free-for-new-game-buyers DLC to serve as a way to get money from used game buyers. (I wouldn’t be at all surprised if one further character shows up as DLC, filling in a hole in the ship’s map.)

And, happily, the resulting plot worked well for the middle game of a trilogy. My guess is that they’ll resolve this iterative implementation tension in a different manner in the third game, because they can’t very well do another game that’s quite as heavily focused on recruitment. But manage it they will; and with two years of information about their rate of progress under their current system, maybe they’ll feel confident going back to slightly larger chunks.

Which I would be grateful for. The rhythm of Mass Effect 2, while pleasant enough, got to be a bit monotonous for me. I’m not sure that I wish that individual missions were longer (and, incidentally, I thought that they showed admirable restraint in the length of the final Omega Relay mission), but I wish that multiple missions had combined a bit better better into larger arcs. (To use a Nature of Order lens, they had Alternating Repetition down pat, but weren’t so hot with Levels of Scale.) They did, of course, group the missions into chunks (e.g. the initial recruitment missions versus the latter ones versus the loyalty missions), and there were several hub worlds which contained multiple missions, but neither of those forms of grouping really cohered for me: they felt more like loose aggregations than wholes that were greater than the sum of their parts.

What I most wished for along one those lines was for one of the city worlds to be larger (in the way that the Citadel was in the original, if my memories of it aren’t excessively rose-tinted): like the missions, I wished there’d been more levels of scale in the cities. Here, I am a bit nervous that, if I got what I wanted, I might not entirely like the result—certainly some of my desire for larger-scale city exploration stems from wanting anything good I’ve seen in any video game to be in any video game where that makes any sense at all, and with my recent appreciation of focus, I realize that that’s a dangerous path to follow. (And Mass Effect 2 is a great data point in that thesis: they cut out a large number of tradition RPG trappings and traditional shooter trappings, to very good effect!) In particular, the Mass Effect series has its focus, as I see it, to be a sort of homage to the space opera tradition in written and film science fiction; the best works in those traditions always make you feel that there’s a rich wonderful world to be explored if you could just stop and look around, but they don’t stop and look around, they continue on with the plot!

But, games aren’t books, games aren’t movies; and in games, I have control over where my character is going, so I’d like to be able to stop and look around a bit more. At least if doing so is feasible without pushing too much of a strain on development: if the team had decided to, say, make one of the cities four times as large, how many of the characters would they have had to cut out? If it’s a couple, and if they could find a way to work missions into that expanded city in a fashion that worked well with the plot, I would say go for it. Who knows, maybe that’s one of the ways that they’ll slice the third game into chunks that they can include or exclude depending on development time: get the core plot lines finished, and then spend half of their remaining time just making the Citadel be as awesome a place as it can be.

So: that’s some speculations about the game’s structure and development process, let’s move on to the characters. I recently talked about juvenile and adolescent games, ending by complaining about games that are childish in the stereotypical sense of the word, that are steeped in guy culture. And there’s certainly a fair amount of that in Mass Effect 2—Shepard is so badass that even getting killed barely puts a dent in her, and large explosions remain one of her key problem-solving strategies.

But there’s also a fair amount in the game that moves beyond that. As others have noted, there’s an awful lot of family going on in the loyalty missions, and there’s a fair amount of nuance there. Adolescence in particular, is a big theme, but adolescence treated respectfully and maturely: Jacob and Tali both realize that their fathers aren’t everything that they thought (or at least hoped) they were; Grunt was created fully-formed but still needs to experience adolescence; Jack’s childhood is horribly ripped from her, and she has to rebuild herself. Most poignantly for this parent, in Thane’s loyalty story we see this adolescent conflict from the opposite point of view; returning to the game development process theme from earlier in this post, I don’t think it’s too much of a stretch to see Thane’s absorption in work while his son is growing up as a parable for the human consequences of a traditional game development process.

And then there’s the game’s meditations on race, even going so far as to visit the concept of genocide from multiple angles. I don’t feel particularly comfortable with my understanding of what the game is doing here, so I’ll mostly leave it to others to talk about the matter, but I will say that the series seems to be making a better effort than most to problematize the notion that killing aliens is okay if they look like the bad guys, and that the second game works to add perspectives.

The Paragon / Renegade distinction continues to work reasonably well, as far as binary morality systems go; while I still maxed out my Paragon score, I found myself making more Renegade choices in the sequel than I remember making in the original, which fits the sequel’s darker tone. But there’s certainly more to be done along these lines; I’d like to see somebody take a cue from Jane Jacobs and instead present a conflict between two positive moralities. (The game’s treatment of facial scarring in this context is bullshit, though.)

So: the first game in at least a year that I’ve finished within (approximately) a month after release, and I’m quite happy with that choice; and Mordin’s Gilbert and Sullivan parody is awesome and pleasantly unexpected. (His assistance in your romance is pretty great, too.) Now I just have to wait until the third game comes out! Maybe I’ll just pretend that Dragon Age didn’t come out last year, and treat it as BioWare’s Fall 2010 release?

A by no means comprehensive list of other posts on the game:

• Jorge Albor on its handling of Paragon / Renegade decisions and on its sentimentality.
• Justin Keverne on Living with your mistakes.
• Chris Dahlen on family and on moving beyond simple morality.
• Tea Leaves compares it to other BioWare games.
• Denis Farr on the game’s lack of gay male romance options.
• Michael Abbott puts it in a broader RPG development context.
• Trent Polack on character.
• Evan Narcisse on the Negro/Injun/Krogan Problem and on the Asari.
• Tom Francis just goes through it point by point.
• Matt Allmer does a design analysis.

We launched a couple of games last week: Wild Ones is a social networking take on Worms, while Tiki Farm is our latest entry into the farm genre. And they’re both a lot of fun, go play them! (And send me lots of goo gun ammo…) I want to talk about Tiki Farm in particular for a while, because it’s managed to work its way into my brain in ways that I didn’t expect. (Aside from its theme song, which I find myself whistling at random moments…)

In typical competing farm games, the main constraint (assuming your goal is to level up and accumulate in-game cash) is the player’s time: you can plow or plant all you want, so as long as you’re willing to put in the time to return to your farm to harvest the crops, you can make quite a bit of in-game money. Actually, that’s not quite true: FarmVille puts a limit on the size of your farm unless which you can only expand by having many friends playing the game or by paying its publisher real money (not in-game money); that’s a pretty clever idea from a virality / profit point of view, but it’s still a fairly coarse-grained cap. (Though, I should add, one which emphasizes that the main constraint is the player’s time: do you really want to spend the time to regularly plow and harvest 60 plots? And of course withering crops are another way in which the player’s time is emphasized as a constraint.)

In contrast, the primary constraint in Tiki Farm is the number of plots available: you start off with only ten or so plots available, and you only get access to two more plots each level. Which left me a bit nonplussed at first—that’s kind of a lame artificial constraint, no?—but as I made it through the initial levels, my opinion of that feature changed. For one thing, I found that not having to worry about picking the size (in terms of plots) of my farm relaxed me: a whole set of conscious and subconscious worries went away. (It’s similar, perhaps to the way I relaxed and started enjoying Deus Ex a lot more once I hit the ammo caps.)

But, for another thing, having such a clear constraint focused my game play in a way that it’s not always focused in other similar games. As the Theory of Constraints teaches us, having a constraint isn’t a bad thing: assuming that your constraint is a sensible one, you can use it to focus your actions, by subordinating the rest of your system to that constraint. What that means in Tiki Farm is that you want to use your other resources in such a way that your primary constraint is being used at its maximum capacity. In other words: you always want to be growing something in those plots.

Which is easy enough to accomplish: the in-game currency (shells) is plentiful enough that you shouldn’t be in serious danger of not being able to buy seeds. In particular, you can sell any crop for more than you paid for it, so as long as you make the habit of replanting as soon as you harvest, you’ll be fine. At which point the question becomes: how frequently do you want to return to the game? Once you’ve made that choice, it’s pretty obvious which crop to choose (yams during my initial burst of power-leveling in the game), and you can get a nice little economy going, periodically earning enough excess profit to let you buy other items to decorate your island.

Or so I thought, until the first time when I wanted to do a purchase that would last me overnight. I’d been planting yams (a 15 minute crop); I wanted to shift to a longer timespan crop, and the obvious candidate was taro root (an 8-hour crop). The problem is that yams sell for 23 shells each, while taro root costs 45 shells; I’d get enough higher profit for taro root to be a better choice overnight, but I couldn’t afford to fill my plots with taro root based on the sales I’d just made! (It didn’t help that I’d recently sunk some of my profits into a very stylish cocktail chair.)

So, basically, working strictly on a throughput basis wasn’t good enough: a changing time investment mix led to a changing crop mix led to a changing fixed cost investment mix. In lean terms: I’d been concentrating on muda (waste, in the form of excess inventory of shells), but all of a sudden I needed to worry about mura (unevenness) instead! To be concrete, it’s a lot easier to plan a straightforward Tiki Farm economy if I’m going to play once a day at the same time (just pick a good 1-day crop and stick to it) than if I’m going to play multiple times during the day and (of course) not play at all while I’m sleeping.

An interesting lean lesson there; I still want to spend some time analyzing the economy to figure out the tradeoffs between inventory, throughput, and time. But without such a clear constraint, I’m not sure these issues would have arisen in a fashion that grabbed me so much.

Though, of course, the constraint isn’t as clear as I’m painting it. For one thing, you use plots to grow crops that you plant from seed; you can also buy trees, however, which bear fruit indefinitely after you plant them. So, in effect, a tree is a plot that you can purchase and that’s particularly inflexible; if you want to grow your economy as quickly as possible, you should siphon off your profits towards trees.

And that’s only if you’re playing solo. If you’re playing with friends, you can give each other gifts; a basic question there is, are trees better gifts or seeds? If somebody gives you a seed, it’s pure profit when it grows, so if you have enough friends giving you seeds, the amount of shells you can make increases vastly. But trees give you shells in perpetuity, so they’re probably still a win in the long-term; then again, you have a fixed island size as a hard constraint, so it’s conceivable that the time scales in question are long enough that trees aren’t as big a win as I think they are. (I certainly won’t turn up my nose at either sort of gift from my friends!)

And, while plot size is a major constraint, it’s not fixed: the number of plots does increase as you level up. This suggests another potential win for seeds: they give you opportunities to get experience points more quickly, earning you more plots. I should actually take the time to understand experience point opportunities better: in particular, do all seeds give you the same XP, or does it vary with the seeds? And, again, the social nature of the game increases the complexity here: for a while, a significant component of my leveling up was spending time clearing bugs off of my friends’ farms.

Speaking of which just what are the implications of helping others’ farms? As far as I can tell, opportunities to help others’ farms in FarmVille are largely artificial (I never see raccoons on my own farm); is that true for Tiki Farm, too, or does clearing bugs off of a friends’ farm have a real effect? If it does, it’s a double-edged one: on the one hand, I’m helping their crops grow faster; but, on the other hand, I’m depriving them of the opportunity to earn XP from clearing their own bugs. I kind of hope that clearing bugs is a real effect; if so, we have a much gentler version of the crop-stealing mechanics that are apparently present in Chinese farming games.

Fun stuff; I hope the game does well, there’s more there than meets the eye. Incidentally, if you’re not already my friend on Facebook, please send me a friends request; just identify yourself as a blog reader if you’re not sure that I know who you are. Or, alternatively, don’t send me a friends request: the only items I post on Facebook are stuff forwarded from my Twitter feed plus Facebook-game-related stuff. So if you want to see the Facebook game items or if you don’t use Twitter, then Facebook is the place to go; otherwise, you’re better off just sticking with following me on Twitter. (If you want my microblogging at all!)

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.

The relevant models are a User model and an Item model. A user has_many :items; part of the Item class definition was the following:

class Item < ActiveRecord::Base
  ...
  def self.next
    find(:first,
         :order => "next_review_time",
         :conditions => pending_item_condition)
  end

  def self.pending_review_count
    count :conditions => pending_item_condition
  end

  def self.pending_item_condition
    ["next_review_time <= ?", Time.now.utc]
  end
  ...
end

As written, those would, for example, add up the total count of all users’ pending items; I wanted instead to be able to ask those questions on a per-user basis.

The has_many declaration gives me a collection user.items for each user. And if I pass a block to has_many, I can add methods to that collection; that seemed more stylish than, for example, adding a user parameter to the above methods. So I modified my User unit tests to make sure that there were items owned by multiple users, and copied over the Item unit tests for the above methods, replacing, e.g. calls to Item.next with calls to user.items.next.

Which I expected to fail, complaining about an undefined method “next”. But not only did the tests not fail for that reason, they in fact passed, ignoring the items for other users! At first, I assumed I’d made a mistake in my tests, but no: when I replaced the calls to user.items.next with calls to Item.next, they failed as expected. So the functionality I wanted really did seem to be working without my having to lift a finger.

But how? I could imagine some sort of method_missing implementation that forwarded functions on the collection to functions on Item. But if it were doing that, how was the functionality getting restricted to items owned by the user in question? I would hope that it wasn’t doing a broader search in SQL and then subsequently ditching inappropriate items in Ruby; sure enough, a look at the logs shows that the SQL queries that are issued do include the user_id restriction.

I haven’t verified it yet, but the only hypothesis that I’ve come up with so far is that the collection objects that are returned by user.items start off life as clones of Item; so they have all of the class methods on Item. And then some key method (find, say) is overridden so that the user restriction always gets applied, and all other lookup methods are implemented in terms of that key method, so they get the restriction in question for free.

Which, once I thought about it, makes sense. Consider Item, not as a class but as an object: you can think of it as a collection object, namely the collection of all items. With that in mind, it makes sense for other objects that are also collections of items to be closely related to it, and if we can express that tight linkage in terms of the implementation, by thinking of Item as the primordial collection of items, so much the better!

An interesting journey. At first, I thought I must be writing bad tests; then I thought I was seeing magic; and eventually I came around to a realization that what I was seeing made a lot of sense conceptually, so I was happy that I was working with a language and a framework where I could get such sensible behavior for free. And, no matter what, it was a useful reminder that there’s a reason why the TDD cycle is red, green, refactor, not just green (with simultaneous test+implementation changes), refactor: if I’d done the latter, I would have missed a useful learning opportunity.

Though there’s a postscript to the story. I’d learned that my original implementation idea was unnecessary; the question remains, though, whether the original implementation idea was a good one or not. And, after giving it some thought, I decided that I preferred having these methods in the User model rather than in the Item model. If I left them in Item, it would be easy to write code representing concepts like “what’s the next item that any user will be asked?” or “what’s the total pending item count across all users?” Which aren’t natural questions to ask, so I was setting myself up for bugs by leaving those methods in Item.

So, with my tests in place, I moved them to User:

class User < ActiveRecord::Base
  ...
  has_many :items do
    def next
      find(:first,
           :order => "next_review_time",
           :conditions => pending_item_condition)
    end

    def pending_review_count
      count :conditions => pending_item_condition
    end

    def pending_item_condition
      ["next_review_time <= ?", Time.now.utc]
    end
  end
  ...
end

Leaving me where I expected to end up when I began, but having taken a much more interesting route.

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.

Star and Griesemer’s first type of boundary objects are Repositories:

These are ordered ‘piles’ of objects which are indexed in a standardized fashion. Repositories are built to deal with problems of heterogeneity caused by differences in unit of analysis. An example of a repository is a library or museum. It has the advantage of modularity. People from different worlds can use or borrow from the ‘pile’ for their own purposes without having directly to negotiate differences in purpose.

At first, I thought this type was kind of banal, corresponding perhaps to collection objects in software, but now I think it’s more interesting than that. Reading their description more closely, I don’t get a collection object vibe: collections in the programs that I write usually contain a quite uniform group of objects, and those objects are used for one or two specific purposes; the above, however, emphasizes heterogeneity and differences in purpose.

That last sentence, in particular, reminds me of mashups; if you combine that with standardized indexing, I’m getting a very strong RESTful vibe from this. In a RESTful application, names are key but internal structure can vary from location to location, and outsiders can use standard tools to access the data that the application exposes and borrow it for their ends.

Next in their taxonomy is the Ideal Type:

This is an object such as a diagram, atlas or other description which in fact does not accurately describe the details of any one locality or thing. It is abstracted from all domains, and may be fairly vague. However, it is adaptable to a local site precisely because it is fairly vague; it serves as a means of communicating and cooperating symbolically—a ‘good enough’ road map for all parties. An example of an ideal type is the species. This is a concept which in fact described no specimen, which incorporated both concrete and theoretical data and which served as a means of communicating across both worlds. Ideal types arise with differences in degree of abstraction. They result in the deletion of local contingencies from the common object and have the advantage of adaptability.

My first reaction here was to try to make an analogy with abstract types; indeed, they use the word “abstracted” in their second sentence, and I can easily see their species example being used as an example in an OO textbook. The only thing that gives me some amount of pause when proposing this analogy is their use of it as a talisman communication tool between multiple parties, many of which may turn out to want to know more about the details of the objects in question.

In contrast, in my programming experience, if I have a concrete subclass of an abstract class, it’s more typical for almost all users to only care about the abstraction, while perhaps only one user cares about the concrete class. Though, rereading what they say, maybe their species example suggests that the correct analogy to the Ideal Type is to (any sort of) class, with the non-ideal objects being instances, rather than subclasses? Either way, though, I get the feel that I’m missing something in the way that I was missing something with my earlier analogy between a Repository and a collection: is there another analogy waiting to be found here that’s a bit grubbier in the way that the RESTful example is?

Third up are Coincident Boundaries:

These are common objects which have the same boundaries but different internal contents. They arise in the presence of different means of aggregating data and when work is distributed over a large-scale geographic area. The result is that work in different sites and with different perspectives can be conducted autonomously while cooperating parties share a common referent. The advantage is the resolution of different goals. An example of coincident boundaries is the creation of the state of California itself as a boundary object for workers at the museum. The maps of California created by the amateur collectors and the conservationists resembled traditional roadmaps familiar to us all, and emphasized campsites, trails and places to collect. The maps created by the professional biologists, however, shared the same outline of the state (with the same geo-political boundaries), but were filled in with a highly abstract, ecologically-based series of shaded areas representing ‘life zones’, an ecological concept.

This one was hard for me to grapple with. (And I’m not the only one; that link, incidentally, gives references to extensions of this taxonomy.) Even in the physical world, it’s a bit hard for me to tell examples of this: is the concept really restricted to large-scale geographic areas? That seems a bit limiting.

The paper in question discusses the Museum of Vertebrate Zoology at the University of California, Berkeley; is it a boundary object? I tend to think so: quoting from the definition on page 393,

This is an analytic concept of those scientific objects which both inhabit several intersecting social worlds (see the list of examples in the previous section) and satisfy the informational requirements of each of them. Boundary objects are objects which are both plastic enough to adapt to local needs and the constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. These objects may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable, a means of translation.

And certainly the MVZ is robust enough to maintain a common identity, but it means something different to a postdoc working there, to somebody who has spent her career there, to a visiting researcher, to a university administrator, to an outside funder, to a janitor. (Indeed, much of the paper is devoted to showing such differences in meanings.) Given that, I would treat the MVZ as a Coincident Boundary: though not spread over a large-scale geographic area, it’s still a place which means different but related things to different people.

Which, to be honest, doesn’t help me directly with finding programming analogies; maybe a function body in the input to a compiler that means different things to the lexer, the parser, the optimizers, the code generator, the debug info generator? Actually, I think maybe the more important analogy is a bit more conceptual and not internal to programming: maybe we could think of a domain object as an example of a Coincident Boundary that means one thing to a programmer, another thing to a database administrator, a third thing to an system architect, a fourth thing to an XP Customer, a fifth thing to a marketer, a sixth thing to an end user. I’m not completely sold on that, but I do think that domain objects are boundary objects of some sort, and they’re a better fit to Coincident Boundaries than anything else in Star and Griesemer’s taxonomy.

The last entry in their taxonomy is Standardized Forms:

These are boundary objects devised as methods of common communication across dispersed work groups. Because the natural history work took place at highly distributed sites by a number of different people, standardized methods were essential, as discussed above. In the case of the amateur collectors, they were provided with a form to fill out when they obtained an animal, standardized in the information it collected. The results of this type of boundary object are standardized indexes and what Latour would call ‘immutable mobiles’ (objects which can be transported over a long distance and convey unchanging information). The advantages of such objects are that local uncertainties (for instance, in the collecting of animal species) are deleted.

Class interfaces (whether concrete or abstract) are examples here, as are generalizations such as duck types or the sorts of dependencies that C++ templates impose on their parameter types. For example, templates don’t care about the details of an iterator as long as it exposes its increment operator under the name ++, its equality operator under the name ==, and so forth.

Network protocols are another example: indeed, what is better than TCP/IP at ensuring that data “can be transported over a long distance and convey unchanging information”? Stick it on the wire in a Standardized Form, and it will come back out the other end. We can use our RESTful example from above in this context as well: if you want disparate clients to all be able to talk to each other, it helps a lot if everybody speaks in terms of GET, POST, PUT, and DELETE.

And, as we did with the last example of the taxonomy, we can step away from the code a bit. An acceptance test is a Standardized Form: if the Customer and the engineers want to agree on what it means to complete that task, it sure helps if they can point to a Standardized Form for specifying that completion, and an acceptance test that both sides can read (and run!) is an excellent form for that agreement to take, for deleting uncertainties.

Interesting stuff. I’m curious what other classes of boundary objects people have come up with, and I should probably spend more time thinking about examples outside of the strict domain of code. And I really like the lens it gives on the messiness, the grunge, the lack of sterility of the RESTful approach: if you pin down enough so that people can talk to each other while leaving enough of the details undetermined so that different groups can use the entity in question for significantly different ends, unexpected synergies can flourish.

Being a good GTD devotee (or a good lean/agile devotee), this means that something has to go. Fortunately, I’m actually pretty well on top of things right now—in particular, my Next Action list is about as short as I can ever remember its being—so I shouldn’t have to prune too much; but I have to prune something. And I’m certainly not going to take a break from learning Japanese—in fact, one of the unintended consequences of the memory project has been to make there be pretty serious consequences if I take even a couple of days off from my study. (One could make a sensible case that I am being a total idiot in subscribing to ChineseClass101 right now, however. Though I certainly don’t intend to treat that as seriously as I’m treating learning Japanese.)

So I think my only choice is to cut down on my video game playing for the time being. Don’t get me wrong: I’m not going to stop completely, you’ll still find me every Thursday evening at the VGHVI play nights, and I’ll keep up with VGC activities. I imagine I’ll do some playing and blogging outside of that, too, but for those of you who read this blog for game-related content, don’t be surprised if there are relatively slim pickings here for a while.

But don’t unsubscribe, either! In particular, my conference activities won’t continue forever, so by the fall I should be back to normal. Heck, I might even be back to normal after Agile 2009—I certainly want to find time in early September to play a certain game.

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?

Summary

Ever heard a programmer say “I think the code’s trying to tell us something”? A joke, right? A metaphor. There’s a social world, where people tell people things, and there’s a world of objects that, at most, exert passive pressure.

But what if we deny that the two worlds are separate? What if we treat everything as a moving mashup of objects, ideas, individuals, and groups? This workshop will present some recent perspectives from sociology on that question, and will ask participants the following: if you believed in one of those perspectives, what would you do differently on your project?

Process/Mechanics

We will repeat the following N times:

• We will summarize a theory from sociology. During the summary, the two moderators will talk to each other as a way to encourage the audience to ask clarifying questions.
• The introduction to the next section is: “OK. Lay aside your skepticism. Assume the theory is true. What should you do differently on your project? Shout out ideas.”
• Like a brainstorming session, our goal is not to criticize ideas but to generate them. Unlike a brainstorming session, we’ll allow discussion of an idea with the aim of understanding it better or building upon it. We’ll also allow clarifying questions about the theory itself.
• The discussion will continue until it begins to die down. The moderators will try to cut it short a little before people are fully ready to move on. (“Always leave them wanting more.”)

The exact workshop mechanics will depend on the crowd. If the crowd is small enough and lively enough, we’ll work as a single group. If that appears infeasible or doesn’t seem to be generating enough ideas, we’ll move into small group discussions with the moderators circulating through the groups answering or asking questions and helping people generate ideas. (Because of the latter possibility, we’ll want seating in the rounds.)

It’s entirely likely we won’t exhaust our fund of theories. That’s OK. (“Always leave them wanting more…”)

Learning outcomes

• Callon & Latour’s actor-network theory
• Star & Greisemer’s boundary objects
• Galison’s trading zones
• Fujimura’s packages

A lot of it was based upon my experience getting a black belt in karate. … One of the things you need to learn is the strategic value of clear space. Trust me, when four people jump you in a dark alley, you do not want to have your brain wrapped around 3000 e-mails sitting in your in basket. That’s why, when I’m not doing anything else, folks, I’m cleaning up e-mail to zero: if I’m not exactly sure there’s something mission-critical I need to be doing right now, I am cleaning up.

Why? Because there is a surprise coming toward me I can’t see, and when that sucker hits, tonight, it might be landing while I’m speaking, … when that surprise hits, do you want to have still a lot of unconsciously accepted but not clarified agreements with yourself that you don’t know exactly what it means but it might be important and then suddenly having more stuff come in on you? That’s why interruption and surprise is becoming such a stresser these days, simply because most people have such a backlog of stuff that those surprises are hitting on huge backlogs so you have a subliminal sense of angst, you’re going to have a level there that is not clear to engage with that appropriately.

Which is a great argument for paying down your technical debt, too. If there’s one thing you can be sure about when working on legacy code, it’s that surprises are going to hit you when you don’t expect them. And, when that happens, you’ll be so much better off if you have a relatively small backlog of technical debt to work with. Whereas, if your code has “a lot of unconsciously accepted but not clarified agreements with [itself]” (where “not clarified” can mean untested, it can mean tested but badly structured, it can mean code that only one person knows how to work with), then your sense of angst will be far from subliminal, and you won’t be able to engage with the code appropriately to solve your problem.

Incidentally, about 50 minutes into the talk, he mentioned that he’s started generating a tentative daily plan. He’d previously recommended against that, since one unexpected event can and probably will change the course of your entire day, but now he’s finding it useful to structure his day by picking up a few candidate high-priority items, while accepting that events may cause that plan to change. Which I was glad to hear, because I’ve been doing that at work for a few months, and am quite happy with the results. Though he also says that he didn’t need to do that until a year ago; I’m quite sure that I’m less busy now than he was a year ago, which suggests that I’m having problems with managing my commitments and next actions.