September 22nd, 2007

damned if I won't try

(no subject)

Everquest. World of Warcraft. Dark Age of Camelot. Guild Wars. Their predecessors like DikuMUD, CircleMUD, ROM, Merc. Collectively, MUD designers call them "MMORPGs" -- it's a pretty unwieldy acronym for Massively Multiplayer Online Role Playing Games. Some people have shortened it to MMO, representing the first three words of that. I'm gonna use that in this entry.

MMOs are really addictive, and mainly because of the achievement grind. You fight monster after monster, or player after player, and get a little "ding!" of achievement. In-game money, experience, equipment. A chance at that latest, greatest new thing that will make your in-game character marginally better. As the game continues, the payoffs get smaller and less predictable, which actually makes it *more* addictive, as it goes from continuous advancement to being a really involved slot machine.

There's a dark side to the advancement grind (well, okay, *another* dark side). Some games, like World of Warcraft, barely penalize you for dying in-game. In extreme cases you may have to spend hours setting up a really involved quest again after you fail it, but that's about the worst it gets. But a lot of the older games would really whomp you for screwing up. In a lot of DikuMUDs it was standard that if your character died, you'd lose a level. When you first start, that's maybe an hour of work. In some MUDs, that could be the loss of a day, a week or even more until you recovered that last ounce of power you just lost. It was also sometimes possible to lose really good equipment, which could take hours or days (or occasionally longer) to regain. This is the most common time for players to get demoralized and quit a game.

Ever wonder why programmers and techies seem so likely to succumb to the temptation of these games? I've got a theory. It's related to the advancement grind.

I'm a computer programmer. I do it for a living, I have for around ten years, and I hope to get at least another ten out of the profession before I have to get a real job. If I'm really lucky I can keep doing it until I'm sixty, where "lucky" means "able to stand up to the strain." But some guys manage. I also program pretty seriously in my spare time, and I've done that for even longer. What I'm getting at here is that I really like being a computer programmer, and I think I'm a good example of a basically successful one.

Techies, you know that little thrill you get when something works? When your new feature works in software, when your script does something cool, when you can suddenly read an RSS feed or install your new game or whatever you were up to. Think of that as being like the thrill of gaining a level or a cool new item in an MMO for a minute. If you're an MMO player, that should be a pretty easy thought exercise :-)

One thing about writing software, and about assembling software, and about really almost everything on the computer is that it gets much, much harder as the job gets bigger. Assembling ten different computer widgets and making them work together isn't just twice as hard as assembling five different widgets and making them work together. It's more like four or five or ten times as hard.

So think of getting a widget working as a "ding!"... which gets harder and harder as you go on, because the bigger, more complicated project makes adding "one little thing" that much more difficult and error prone. Now imagine serious failure ("okay, this approach isn't working, back to the drawing board") as the equivalent of an in-game death. Doing that thing, in that way, didn't work. You just screwed up and you take whatever the penalty for "dying" is...

Interestingly, the old penalty for dying in software engineering was pretty bad. You had a half-done feature hanging around, adding bulk and screwing up your later attempts. You could go back and get rid of those bits, but it meant there was a chance you'd destroy stuff that *was* working... Which meant a serious, possibly permanent penalty for "dying".

If you look at recent advancements in software engineering (for the initiated: I'm thinking of stuff like unit testing, continuous integration, source control management and agile methodologies), it's a lot like the differences between DikuMUD (the old standby MMO of the 80s) and World of Warcraft (the big popular newcomer MMO of the 00s). Source control is a way to roll things back and get to where you were when you started writing that feature. So you still lose all the progress since then, but at least you're no farther back then where you started. Unit testing is a way not to lose progress while you're not looking at something. Agile methodologies are ways to break the features up into smaller pieces so that stop-and-roll-back loses you less. Continuous integration probably doesn't have an equivalent -- it's more about multiple programmers working together, but guild advancement in World of Warcraft doesn't work in a way that parallels programming well :-)

It's easy to say, "yes, all this reduces the penalty for writing bugs. We knew this was the goal. Equating it with World of Warcraft is perhaps interesting mental masturbation, but, like, ew. Go away, freak." But there's a point we're not taking into account, and I think it's worth mentioning...

Morale. Work ethic. When I'm cynical, I think that pair programming gets good gains mostly because people feel worse about slacking off when there are two of them watching each other. We ignore effects like this when theorizing about how to train good programmers. That's silly. We should be paying attention.

When an MMO loses users they wander off, lose interest, maybe delete their character and move on to a game they like (or chores they neglect). But when you lose a programmer's interest, you lose a lot of productivity in a mostly-invisible way. It's hard, hard, hard to measure programmer productivity, and similarly hard to measure productivity in most other creative techie disciplines (hello, sysadmins!). We don't talk about programmer's block, but it happens every bit as much as writer's block, judging by me and my coworkers. We just have an easier time screwing around in ways that hide it.

I don't have the Next Big Thing figured out for programming or anything. But I do think it's worth looking at the "retention features" of the better MMOs and try to see what that says about motivating programmers. Because the more compelling this discipline is for us, the better the widgets will be that the rest of you get to use :-)
creepy men / suggestive manner

(no subject)

There are, like, four different related topics in my head. I'm gonna pick one and write about it. I'm in a programming mood, so this take will be about programmery stuff. So: this is slightly technical, and wanders a bit. You have been warned :-)

There's a principle in programming (and elsewhere) that's often called DRY, for "Don't Repeat Yourself". The idea is that you should specify everything exactly once, because then you only have to change it in one place. Most programming languages, and most human languages, make this challenging.

Certain programming languages make this easier by allowing you to do all sorts of evil high-level mathematical tricks (I'm looking at you, Haskell and SML/NJ). And it's, y'know, cute. But I notice one thing in particular about the results of actually doing this.

It's dense. Absolutely every line is full of meaning. Looking at a page of the stuff is exhausting. There's a reason we don't write newspapers that way.

Books and newspaper articles are meant to be readable. So they go over facts in slightly different ways, add some fluff, make sure there's plenty of whitespace... They add a bunch of simple repetition, so it's not too awful to read.

What interests me most about this is that the dense, short, DRY-style text is much, much better to work out ideas in, at least as a programmer. Things change in one place only, you can see a much larger chunk of the total program, you can keep more in your head, once you've (slowly) absorbed it...

But almost nobody writes like that. At least for programmers, a lot of the problem is that it looks like a lot less work because it's so short. And in a discipline where it's very, very hard to measure actual ability or performance, people use a lot of bad metrics. The simplest is, "look how many lines I wrote!"

So you see people bragging, "I wrote a 15,000-line program!", but only rarely, "I wrote an 800-line program that does the same thing as his 15,000-line program!" And if there weren't a huge program to compare to, you wouldn't hear it at all. Rarely, in a few specific scripting languages, you'll see boasts that go, "look how much I got done in fifteen lines!" or something like that. But usually it's Perl, it looks like line noise, and nobody will ever be able to read it or modify it again :-)

The closest equivalent I know is math -- optics books, for instance, are full of one-line differential equations that you could spend months figuring out all the applications of. The Fundamental Theorem of Calculus turns out to be way more complicated (and useful) than it looks. Multivariate Calculus is full of concepts that require either a large chapter of text or three short equations to explain.

And few people work densely in that, come to think of it. The only examples I can think of are extensive proofs. I wonder if mathematicians would be more or less productive if they worked more purely in such things.

Something I'm curious about, after reading too much Paul Graham... Do software startups write much denser code? I know Paul Graham himself did -- the stuff he prefers with procedural macros is very similar to a lot of the dense, code-passing-heavy ruby code that I'm writing. But do startups, where impressing people matters less, do more of that?