malvasia bianca

At Agile Open California this year, I didn’t spend all my time thinking about Christopher Alexander (and I owe y’all still more blog posts about that): I also convened a session on Refactoring Writ Large. I put my notes up on the AOC wiki, but here are the examples that motivated it:

Consider the following phenomena:

• Don’t Repeat Yourself in Rails: the structure of your database automatically (and dynamically) generates appropriate methods in your classes. Basically, just create a class that inherits from ActiveRecord and that is named after a table in your database, and all sorts of wonderful things will happen without your having to lift a finger!
• Some recent experiences that I’d had at work with code generation tools (we should have been using them years ago, and they’re most appropriately written in a scripting language, no matter what language you’re generating), coupled with my reading the book Code Generation in Action.
• The current popularity of Domain-Specific Languages.
• Tools that are created for non-developers to use, that end up speeding up the work of professional developers.

That last example was prompted by this discussion of how the user-generated content creation tools allowed the LittleBigPlanet level designers to work in a more agile fashion:

Are there any other advantages to building LBP around user-generated content besides the sheer volume of content that players will create? Do you have any plans for this content outside of the core game?

There were unexpected benefits, and obstacles, to the actual process of in-house development. The games industry consists of professionals trained effectively to ‘cheat’—to make it look like much more is going on than there really is, given the technical constraints of the game platform. The mark of a good artist, for example, is to make the minimum number of polygons convincingly convey a character’s face, or a building’s detailed architecture.

With user-generated content, our mantra had to be ‘don’t cheat’—in other words, we can only build things that users could also build. Although this is a surprisingly hard constraint to stick to, it has the huge benefit that our internal toolchain—tools being the make-or-break ingredient as far as game development goes, and the reason for the flourishing middleware market—were necessarily very simple and fast to iterate.

In fact, we treat all of ‘our’ content as user-generated content—with all the attendant benefits. We can edit everything in-game, live, with no expensive pre-lighting or visibility computation or ‘compile’ steps that would typically take hours in a traditional pipeline. So we actually ended up being a more agile team, better able to deliver lots of content even with a very small team. In terms of plans outside of the game, well, we will have to wait and see. I think Sackboy as a character, for example, has been fantastically well received and I would love for him/her to become an iconic character on the PS3. That certainly would help us find interesting ways of expanding the LBP universe and the content within it.

What all of this suggests to me is that I need to expand my notion of where refactoring would be appropriate. The Refactoring book talks about refactoring within the context of a single language; some of the most powerful refactorings, however, involve minimizing duplication by changing languages entirely! Something to keep my mental feelers out for in the future.