malvasia bianca

I see that I’ve forgotten to mention Kalpa Imperial, by Angelica Gorodischer, which I read a few months ago. I ran into it because it’s translated by Ursula K. Le Guin; I approve of her books, and her taste in general, so I figured I’d give it a shot.

And it’s delightful. It’s a collection of stories about a fictional empire, through its twists and turns over thousands (?) of years. The stories aren’t particularly connected: they dip into the history of the empire at different times, in different places, from different viewpoints. Most (all? I can’t remember) of the stories follow the rulers of the empire, but they take quite different approaches to their lives, starting from a quite human and specific approach, so they never feel repetitive. The cities themselves are also typically major players (and it’s a long-lived empire in which the rulers moved around a bit); in a way, it feels like Invisible Cities, though it has a much more traditional narrative (and much more realistic cities) than the latter.

The author is actually Argentinian (which I would not have guessed form her name, I confess). And I don’t think that’s the only reason why she reminds me of Borges: something about the way in which they write about fictional worlds, the ties that those world have with the ones around us. (Though Borges is a good deal more eccentric.) Shades of magical realism, I suppose, but not so explicitly magical as what I associate with that term.

Too bad nothing else of hers has been translated into English…

As I mentioned recently, my group has been experimenting with some XP-inspired agile planning. Now that that’s stabilized, the question is: where next? It’s still my plan for the group to end up at full XP, if possible. (Asuming our experiments with it continue to turn out well, of course.) It’s also still my plan to do this in steps, despite the recommendations of others to do things whole-hog. I say this for three reasons (the latter two of which are largely informed by those Weinberg books I was reading):

• I think I would get significant push-back if I wanted to make the transition whole-hog: less significant than I would have a few months ago, but enough to be a potential problem.
• Making changes is hard, and risks falling into chaos. Given that making changes is necessary, however, you want to develop a skill at making changes. So get good at making small changes with clear goals, at observing how well those goals were actually met, at figuring out whether or not people go along with the changes, at addressing the reasons why people don’t go along with those changes. And make sure that you know when changes are causing initial chaos, when they’re starting to stabilize, when they’re fully integrated into the culture.
• I don’t support XP because it’s a nifty acronym: I support it because I think it will have certain concrete benefits. Similarly, I think the individual practices will have certain concrete benefits (though many additional benefits come from interactions from practices). Even if you do XP all at once, you need to develop a good sense for whether you’re getting the desired benefits and, if not, why not. (For example, you may not be doing XP right, it may not be the best fit for your situation, or it may all be a bunch of malarkey that only gullible fools like me could possibly believe in.)

To me, developing the sense of whether or not you’re getting the expected benefits is at least as important as the actual benefits of XP’s practices. But once you’re working on developing that sense, it becomes quite reasonable to adopt XP incrementally: you should still see enough benefits at each stage to keep you going, and if not, stopping and figuring out what’s going on is at least as sensible a response as trusting in the powers of the combined XP practices.

With this in mind, given that my group’s use of planning cards has stabilized nicely, the question is: what aspect of XP should we integrate into our work? There are, I think, three things left to do:

• Pair programming.
• A Customer.
• Everything else. (Reexamining our unit testing and constant refactoring to make sure we’re doing it as well as can be; making our coding standards stricter; seeing if we can come up with a metaphor, though I’m not optimistic.)

My preference would be to carry out those steps in the order listed, in two- to three-month increments. I’m not sure who would serve as the Customer role, so I’d rather put off the work of getting that set up. But I think that pair programming would help reinforce a lot of the progress that we’ve made recently: increase our refactoring, increase our testing, decrease pigeonholing.

The only worry I have with pair programming was that we flirted with it last December, with unimpressive results. I think that I have an idea of some things that we did wrong: we were spending too much time working on areas that only one person knew about, we were spending too much time on hygiene tasks, we weren’t being strict enough about it (in particular, I didn’t step in when I saw two people programming alone), and we just weren’t as used to working together or working on different things as we now are. So I think we can get it right if we try again now.

Talking it over with my group and my manager, they agree that it’s a reasonable next step, so we’ll begin on Friday. (It’s hard for me to figure out the power dynamics within my group: I don’t think I’m running roughshod over my underlings, but I can never tell.) I found a pleasant book on the subject (Pair Programming Illuminated, by Williams and Kessler), which I hope will help guide me past some of the pitfalls. We’ll see how it goes; I’ll report back in a month or two.

A coworker of mind just pointed me at the Self-Referential Aptitude Test.

The baseball season is a month old, yet I don’t seem to have commented on it yet. I guess I’ve been thinking about other stuff, or maybe it’s because of all the Food Network stuff that we have on the DVR. Admittedly, being able to pause games is nice, except that it’s really depressing to watch the rest of the game after dinner because the A’s can’t hit worth crap.

I’m sorry, am I shouting? For the first few weeks, I just kept on saying to myself “small sample size”, “small sample size”. And then the A’s managed to get back over .500. And then, well, they dropped a couple of series, and got shut out for a couple of games in a row. They’ve already gotten shut out more times this year than all of last year, and they were certainly no offensive powerhouse last year.

I was cautiously optimistic going into the season. Their bullpen was really depressing last year, and they seemed to have done a lot of work to improve there. I thought the offense would probably get a slight boost; signing Jason Kendall sounded like a nice move. I wasn’t thrilled about their starting pitching after the trades, but if Baseball Prospectus claimed that the trades wouldn’t hurt their starting pitching, who was I to quibble?

And, indeed, the pitching has been respectable; some of the starters have been pretty iffy, but Joe Blanton and, especially, Rich Harden have been awesome. And their relief pitching has been quite respectable. But the offense has finally slipped past Kansas City to the very bottom of the AL. (With my other favorite team, the Native Americans, keeping them company.) What is going on here? Each year, I think that this is the year where Eric Chavez will turn from one of the better third basemen in the league into a real star; each year, I am wrong. And it’s not just him: nobody, nobody is hitting on the A’s: the team leader in OPS is Mark Kotsay; while .753 is decent for a center fielder, it’s abysmal for your best player. (Fun stat: Mike Hampton is third on the Braves in OPS, at .900.)

Ah well; let me repeat again: small sample size. Plus, the Yankees suck, too. Speaking of which, one article on the Yankees (at a time when they were 11-18) mentioned that, in 2001, the A’s started off 11-18; the rest of the season, they won more than two-thirds of their games, including 20 in a row. Let’s hope the A’s pick it up like that again this year…

For a while, I’ve been thinking of changing my use of a couple of pieces of software: Galeon, the web browser that I use, and XEmacs, which I basically use for everything other than web browsing. (It has a web browser, too, but it’s less than optimal.)

These are, of course, two rather different situations. Galeon is a much younger program; it uses the Mozilla rendering engine, and appeared at a time when it was the only good lightweight alternative to Mozilla. Since then, other options have cropped up, one of which (Firefox) is dominant, and it’s not included in Fedora Core distributions. (Why, I’m not sure.) So it’s a bit of a hassle to keep on updating it; there are a couple of things that it does that I don’t know how to do with Firefox (customizable search boxes, Gnome integration), but those aren’t show-stoppers. At least at home: at work, I get a lot of mileage out of customizable search boxes. (I suspect that Firefox has a mechanism to provide similar functionality, I’ll just have to figure out how to do it.)

And Firefox does have one clear advantage over Galeon: it can read RSS feeds. As I mentioned before, I’m reading RSS with Gnus in XEmacs these days. Which is better than not having an RSS reader, but it feels a little silly, because when a new article appears in a feed, I just click on the link to bring it up in Galeon. So why not eliminate the middle-man? Also, I’ve run into one annoying bug, and Gnus doesn’t handle new versions of RSS (Atom), which is occasionally an annoyance now and will, I suspect, be much more of one in the future.

Which brings me to XEmacs. I use it for a few different things:

• It (via Gnus) is my mail (and news) reader of choice. I don’t see this changing any time soon: I’m quite fond of Gnus, and I have yet to see any even vaguely compelling reason to switch mail readers. (At least until HTML e-mails start swamping plain text; I’ve been pleasantly surprised at how well text/plain is holding up, with the aid of multipart/alternative.)
• I use it as a development environment. Here, actually, I may switch away part of my work: the next time I get back to programming in Java, I plan to give Eclipse a serious look. I don’t like Emacs’s Java mode at all, and I would really like to try using an IDE with automated refactoring support. It’s not a threat for C++ work, though: Eclipse doesn’t have any (serious) refactoring support for C++, and without that, there’s no reason at all to change.
• Other text editing. Here, XEmacs does fine. I’m a little worried about its inadequate XML support; for now, though, I don’t have to edit XML files at all frequently, so it’s not an urgent problem.

Note that I’ve stayed blessedly free of need for, say, WYSIWIG editing (e.g. communal work on Microsoft Word documents). If I want a document to look good, I just use LaTeX.

So, unlike Galeon, I can’t imagine completely shifting away from XEmacs. (Incidentally, until I started working at Kealia, I had no idea that there were so many vi users around! And nobody uses a standalone IDE in our group.) It and GNU Emacs are starting to show their age, however. Unfortunately, I don’t think that either one has a really vibrant development community behind it any more; there’s still enough of a community there, and its existing functionality is extensive enough, to provide a very solid cushion, but I’m pretty sure that a permanent decline has begun. I’m afraid that there’s going to be some killer app requiring an editing format that I need to deal with, and that Emacs won’t support in time for it to be a viable alternative for me. If I were programming in Java, automated refactoring support might be that killer app: it sounds to me like it seriously changes your relationship with the code in ways that are very important for me. For the next few years, I’m probably safe, but the clock may be ticking.

Which brings us back to our last topic. As Jordan protested, TeX still has a strong user base behind it. And it’s interestingly different from Emacs: it basically hasn’t changed at all for more than 20 years, while Emacs has needed to change significantly in that time (supporting X Windows being the simplest example). Of course, I don’t program in plain TeX, and fortunately LaTeX has been improving; maybe TeX will live indefinitely as an underlying formatting engine with improved macro packages and tools on top of it. (For that matter, I actually wouldn’t mind if new Emacs releases were few and far between, as long as there were a vibrant elisp hacker community; one great virtue of XEmacs is that it’s much easier to install third-party packages for it.) After all, TeX was designed for computers of two and a half decades ago; on modern computers, it’s quite zippy, enough so to support a significant weight of layers accreting on top of it. Not quite zippy enough to, say, make it realistic to re-TeX your entire source file every time you type a character, but it’s not that far off from such a rate.

TeX does still have some challenges. I’m not sure that there are any standardized ways to, say, include hyperlinks in your documents, though I’m fairly sure there are nonstandard packages to do that, and it actually would fit in reasonably well with LaTeX. As the world moves away from editing plain text by hand, it might have to fight somewhat to survive; I can easily imagine, say, an XML DTD that would corresponding quite directly to LaTeX, but it would be a quite delicate juggling act to balance that with the ease with which you can write mathematical formulas by hand. I wouldn’t be surprised, though, if TeX lasted for another 20 years; it’s a pretty amazing piece of software. I’ve been using it for 15 years myself, and new users are born every day, or at least every few weeks, in math (and presumably CS?) graduate departments.

At work, I’ve recently been reading through a collection of papers on software development. Pretty boring, largely, until I got to the last article: “The Errors of TeX”, by Donald Knuth. Which was great! It turns out that Knuth kept a log of every single change he made to TeX from the beginning of debugging the first version to the present; he’s written a very engaging article about it. The article itself apparently isn’t available online (sigh), but at least the list of errata is; the current version is here. It’s an amazing view into the mind of one of the most important of computer scientists (and one of the most amazing programmers we’ve ever seen, as far as I can tell: I can only dream of writing and debugging code as quickly as he talks about here), into one of the most important pieces of software ever.

I mentioned this to a friend over lunch; his comment was “why don’t people talk about TeX more in discussions of open source software?” Which is a very good point; why don’t people? TeX is out of vogue right now, perhaps, but it was certainly prominent enough over time. And it’s unique in a very important way: it’s the only piece of software that I know of with essentially no remaining bugs. (Looking at the list, there are probably a few left, but he’s only made 4 fixes in the last decade.) Shouldn’t we spend more time studying this program, reading through the code, learning how Knuth wrote it, seeing if we can adapt those methods to our current work?

I’m in the mood to blog about managing, so I thought I should add a “Managing” category. But how to fit it into the hierarchy? I manage programmers, and I expect most or all of my managing posts to be about programming as well. But programming is already the only subcategory I have; to add a subsubcategory to it would be a bit ridiculous. Maybe I’ll just get rid of subcategories entirely, actually: have Programming be a top-level category, and reserve Computers for non-programming computer topics. (Which is tangential to the issue at hand: the Managing posts would still probably be a subset of the Programming posts, even if the relationship isn’t formalized in a hierarchy.)

Of course, I may start writing at some point about aspects of managing that don’t directly involve programming. I think that part of the issue here is my own ambiguous feelings on the matter: my group has all of five people (including myself), one of whom is currently on leave, so managing is hardly a full-time job (especially since they’re delightfully easy to work with). As a result, I spend around half or two-thirds of my time programming, and all of my managing thoughts are inevitably tainted thereby.

Which is the way I like it. Don’t get me wrong: managing is quite interesting, I’m learning a lot by doing it, and it gives me lots of things to think about. But at the time I started managing, I’d only been working as a professional programmer for a year; it’s been basically another year since then, but I still have a lot to learn about programming, and I don’t want to give that up. My official position is a “Staff Engineer” at Sun, which is on the technical track, not the managing track, and that was an intentional choice: I expect that, in my next job, I’ll look for a programming job.

The nice thing about managing while working as a programmer, though, is that it gives me quite a bit more control over my programming environment than I would otherwise have. I’m starting to get very strong hypotheses about how I think code is best produced, and how I think I would most enjoy producing code (the answers to both being the same); I would, frankly, rather not spend time in an environment that I feel is hindering my programming. And if I have to give away half of my time to managing in order to get that environment, that’s a reasonable trade-off.

I’ll definitely have my eyes open to management issues during my next job search. Which, fortunately, is not at all imminent: I quite enjoy my current job, and it’s getting more interesting rather than less interesting. If you’d asked me a few years ago, I probably would have speculated that I’d prefer greenfield development to what we’re doing now, getting code ready for production while adding a few features that we left out. And I’m sure I would enjoy greenfield development; but there’s something quite refreshing about working with actual, flawed code, being forced to confront its liabilities, and deciding what to do about them (while, of course, preserving the strengths of the code). I suspect that, when doing greenfield development, it’s easier to pretend that you’re writing good code, while the truth may be that your code just hasn’t been put to the test in enough ways. (Both in terms of extensive testing and in terms of successfully supporting further development.) So a bit of extra concreteness is nice.

Which is, in a funny way, where this post started: just as I like being confronted with concrete programming choices, the reason why I can’t separate managing and programming is because I can’t get away from the concrete managing choices that I have to make, and programming is always close enough to the surface in those choices that it inevitably bubbles up in any thoughts I have on the subject.

At the Sun Engineering Conference a couple of months ago, I went to a workshop by Ron Jeffries on agile planning. That inspired me to try out the (XP) technique that he was proposing: the idea is to plan all work in terms of “stories” that you estimate will take between 1 and 3 “points” each (where “points” is some linear measure of duration). You do your work in iterations; each iteration, you pick a bunch of stories, and try to implement them. The theory is that, as you get practice with this, two things happen:

• Your estimates get pretty accurate: most of the time, if you say a story will take 2 points, it actually does, and overestimates are as common as underestimates. (In contrast to traditional software estimates, where underestimates are much more common than accurate estimates, and overestimation is inconceivable.)
• Your “velocity”, the number of points that your team finishes in an iteration, settles on a value.

If you combine these two, then you’ll be able to accurately estimate how long it will take your team to carry out a project: break it up into stories, estimate the stories, add up the points, divide by your velocity, and there you have it! And if an unexpected surprise happens, or if externally-set priorities change, you can easily figure out the effect of throwing away no-longer-necessary stories or adding new ones.

So I decided to have my team try it out. We wrote down a bunch of stories on cards, and tried to estimate them. Our iterations are one week long; we decided a point would be an “ideal programmer-day” (i.e. the amount of work you’d get done in a day if you didn’t get interrupted at all); we figured that people would get no more than 3 ideal days worth of work done in a week.

After running our plan by Ron, it turned out that there was one main thing we were doing wrong: our cards were (frequently) focused on technical tasks instead of user stories. The latter is desirable so that the customer can easily direct and respond to what you’re doing; it also helps reduce the frequency of situations where priorities change and you’ve got a lot of stuff half-done that, while looking like natural steps from a technical point of view, has no business value whatsoever. In particular, we had too many “hygiene” tasks scheduled: tasks that were solely for the sake of cleaning up our (flawed but improving) code base, to improve its future reliability and maintainability.

If we were a pure XP team, we’d have somebody playing the “Customer” role (hopefully an actual customer!), and then we’d handle things differently. We’re not yet a pure XP team; given the lack of a Customer, I didn’t think this flaw was urgent to deal with right now: the story cards should have enough other benefits to be worthwhile.

We’ve been doing this for about two months; here’s the progress report.

• Our velocity has stabilized nicely: my group does 11 points of work per week.
• Our estimates aren’t always on target, but they’re not too bad, and are probably getting better.
• Given the above, I suspect that we could reasonably successfully estimate how long it will take us to accomplish larger projects (by breaking them up into small ones). We haven’t tried to do so, however.
• We’re getting better at breaking up projects into small steps. This helps me feel more in control; I’m not sure how much of this is a psychological benefit versus a practical benefit, but I like it.
• We’re doing a somewhat better job of not having people embedded in fixed roles. It’s still largely the case that we have an idea who will work on what card, but there have been some pleasant surprises recently. Also, if people are looking for something to do in the middle of the week, they’re now more likely to stray beyond their traditional domains than they had been.
• I’m pleased that we have knocked off many of the hygiene-related cards and haven’t added any new ones. So I hope that, soon, our source code will be in adequate shape where test-driven development and constant refactoring are enough to keep it well-maintained. (I do think we could stand to spend a little bit more effort on refactoring bad code whenever we’re in the neighborhood.)
• Several times in the last few months, my team’s priorities have been shifted significantly, in response to customer issues. I used to find that frustrating. Now I find that frustrating for about 10 seconds, then I say “wait a second, the customer is allowed to change her priorities, and it’s my job to make those changes as painless as possible, to not get us caught in the middle of long-term development that would have to get thrown away”. Then I notice that we’re getting more successful with the latter, and my frustration abates.
• My team members seem perfectly happy with using the cards, and it’s not introducing any significant overhead.

All in all, I’m happy with how things have gone. There’s nothing that I can point to that is a huge advance over the previous state of affairs; on the other hand, there are several small changes that I like, and I can’t think of a single negative aspect of using the cards. Which is pretty good, in my book.

One of my friends brough a PSP into work, and he let me play through a bit of Wipeout Pure. (Hmm: the official capitalization seems to be WipEout . Sigh.)

Nice screen; a big improvement over the GBA. Good to have an analog joystick. Great graphics; not as good as the current generation of (non-handhold) consoles, perhaps, but not so far off, and certainly better than the previous generation. And I quite enjoyed the game. It reminded me of Extreme G, the first game that I got for the N64. I only got that game because other, more prominent games (Super Mario 64, Goldeneye) were out of stock at the time (the woes of cartridges, sigh), but I had a lot of fun playing through it. And it’s been a while since I played through a nice techno-racer.

I’m not about to run out and buy a PSP right now, however, for the same reason that I’m not about to run out and buy a DS: there aren’t anygames that I see as must-haves, no games that I’d rather play instead of games I don’t have yet for consoles I already own, or even games that I’d want to spend time playing while somebody else was using the TV, instead of reading a book or blogging or something. It wouldn’t surprise me if I bought one eventually, just not right now. (Hard to say; it might also be the case that it will be almost exclusively populated with inferior versions of games on non-handheld consoles.)

It’s too bad that more people at work aren’t active video game players; while some people dabble in video games, most people don’t, and I seem to be by far the most devoted video game player there. If several people owned PSP’s, I’d be happy to get one myself, and then we could all play games together over the wireless network at lunch. Something to look for in my next job, I suppose… (That would go over really well in an interview: “Tell me whether or not people play video games at work.” If any future prospective employers are reading this years from now, I assure you, I’d only play games at lunch time!)

I just finished the new Zelda game for the GBA, and it’s quite good. A little while ago, I complained about how I don’t like 2D Zelda games as much as 3D Zelda games, but actually this game does a lot to alleviate my complaints. (Kind of spooky, actually.)

For one thing, the overworld isn’t divided up into tiles the same way as previous games are. It’s broken up into 12 or so regions, of different sizes, each of which is a coherent setting. You can wander around fairly freely, so you don’t feel like you’re in a hedge maze and you can easily enough avoid monsters if you’re in a non-fighting mood.

The one main city is reasonably large. It’s not large so much in size, but there are lots of building that you can go into, lots of people to talk to. And, as you gain abilities, you open up more and more things to do in the city. (There are also a few minor cities near dungeons, as is not uncommon in Zelda games; not much in them, but it’s a nice place to pause between the wilderness and the dungeon.)

It has one other quality that I appreciate more and more these days, as my time for playing games diminishes, and as the number of games I have to chose from increases: it’s very easy, while managing to provide some nice puzzles to figure out. Don’t get me wrong: I enjoy a good challenge, as long at it’s very well balanced. But the moment I start seeing a game as tediously difficult instead of interestingly difficult, I lose interest, and often put it down, never to return. With this game, I didn’t die until the fifth dungeon, and I was never in too much trouble.

Having said that, at the end, it did fall into one cliche that I will be more than happy to never see again: the final boss battle that is three times as long as any previous boss battle, with the sequence normal boss / “you think you’ve defeated me, but wait until you see my real form” / “actually, I have another secret real form that’s even worse!”. (With no save points in between forms, of course.) Ridiculous, tedious, insulting. At least in this game even the final forms weren’t too bad, so it didn’t take me too long to complete.

I don’t have much else to say. It has an optional collecting subgame, just like so many games in the post-Pokemon era, but it’s not too tedious: I actually ended up collecting all the figurines. Lots of optional things to do if you’re in the mood to scour the countryside again after your first trek through; I enjoyed the game enough to do most of it. The shrinking gimmick in the game was pleasant enough. All in all, a well done incremental improvement over previous 2D Zelda games; there are a lot worse things for a game to be.

I wonder what the next GBA I’ll buy will be? Will I ever buy a GBA game again, or is the platform dead? (Looking through a list of announced games, this probably is the end for me.) For that matter, I’m starting to wonder if I’ll ever buy a Nintendo DS; that system looks more like a tech demo every day…

WordPress, the blog software that I used, has gone through some changes recently, so I thought that I’d upgrade it yesterday. At first, I thought everything went well, so I started to write a post about how remarkably well designed the upgrade process was.

Unfortunately, when I went to edit that post in progress, it lost my changes. After more poking around yesterday and today, things got stranger and stranger. I thought I might have made a mistake, so I restored from backup and tried upgrading again, and it was even worse. The only guess that I have is that content was getting cached inappropriately somewhere, but I don’t understand why that would happen or how to fix it. And, while WordPress has some active support forums, nobody else seems to have had the same problems that I had.

So I restored from backup a second time and stuck with the old version; at least it seems to be working just fine.

Too bad I can’t use the new version, though, if for no other reason that it has some improved spam-handling measures that I could really use right now. Maybe I’ll just go and tinker with the spam-handling myself: I had been feeling guilty that my knowledge of web technologies ends with hand-written HTML pages, so it would be nice to have an excuse to learn about PHP…

I heard back from Alfie Kohn in response to my question about John Holt and homeschooling. His anwser was that he likes a lot of what Holt said, especially in his earlier works, but he wouldn’t go as far as Holt and recommend homeschooling for two reasons:

• Public schools are an important democratic institution, one worth preserving and working to support. (And improve.)
• Kids learn a lot from collective intellectual exploration and knowledge testing and construction.

Which makes sense; I can’t say either of those reasons are show-stoppers for me, but they’re both good ones nonetheless.

Fortunately, we have several years to figure all this out. (And perhaps to improve Mountain View’s post-fifth-grade programs.)

(This is a lightly edited version of a post on an internal Sun mailing list on extreme programming).

I just finished reading the Quality Software Management series, by Gerald Weinberg (which I learned about from the XP bibliography), and I heartily recommend it to anybody interested in XP, or for that matter other agile practices. Or at least anybody interested in XP, interested in software management, and with enough free time to read 1500 pages, which I suppose isn’t quite the same thing.

One concrete benefit: it’s gotten me to think a little more about what I like about XP. So if people ask me why I like XP (which I imagine will be the case as I try to move my group further in that direction), I will now have a relatively crisp answer:

1. It puts a lot of emphasis on measurement and feedback (and it measures in in multiple ways).
2. It puts a lot of emphasis on quality (and it strives for quality in multiple ways).
3. People who have used it report favorably on their experience, in ways that I find convincing.

If I were then asked to elaborate, I would say, in regards to the first point, how testing, time estimates, small releases, continuous integration, customer feedback, and pair programming all come into play. And, as regards to point 2, I would talk about how it strives for quality measured by code that does what it is claims to do (as measured by tests), that does what the customer wants (as measured by the customer’s choices in stories to implement), and that is easy to modify (as evidenced by the ease with which XP teams implement new features), and how testing, pair programming, customer feedback, constant refactoring, and the 40-hour week all come into play in the search for quality. (And about how a traditional effort towards quality, namely people with bulgy brains thinking at the start of the project about the perfect way to do things and then telling peons to implement their vision, after which everything will be working perfectly, doesn’t come into play.) I might also refer to books like Weinberg’s that talk about why focusing on quality is a great idea even if you’re largely interested on getting your product out the door fast.

Another concrete benefit: it’s helped me think about my group’s hoped for (by me, if nobody else) adoption of XP, how it’s going so far, and what the next few steps should be. I’ll post on that later.

Here are some things that I found interesting in the books, with links to XP as appropriate:

• He presents a systems thinking / cybernetics approach to software management. This involves writing down diagrams with bubbles representing (more or less) quantifiable things you’re interested in, and arrows between bubbles saying how changing one of the quantities increases or decreases another one of the quantities. (Sometimes always increases, sometimes always decreases, sometimes can increase or decrease depending on the choice of the manager.)

  So, for example, if somebody thinks that writing pervasive unit tests will increase development time, you can imagine them as having two bubbles: “Number of unit tests written while coding” and “Time spent in coding”. And there’s an arrow from the first to the second, showing that if you increase the number of unit tests, you increase the coding time.

  But you can embed that diagram in another, larger diagram by adding two more bubbles: “Time spent finding and fixing bugs” and “Total development time”. And then you draw more arrows, saying that an increase in “Time spent in coding” increases “Total development time”, that “Time spent finding and fixing bugs” also increases “Total Development Time”, and that “Number of unit tests written while coding” decreases “Time spent finding and fixing bugs”.

  At this point, you still have the old path where increasing “Number of unit tests written while coding” increases “Total development time”, but you have another path by which “Number of unit tests written while coding” decreases “Total development time”, so it starts to become conceivable that unit tests really do speed up development, depending on which arrow’s effect is more powerful. (And then, of course, an XP proponent will be tempted to modify the diagram further, showing how unit tests allow you to change code more quickly, etc.)

  The nice thing about this from the XP point of view is that it gives you a good way to show how XP practices that initially look like they might be ineffective or even actively counterproductive turn out to be a good thing. I’ve given an example above; in general, you take a simple diagram that seems to show that a practice is bad (increasing “Pair programming” decreases “Keyboards in use at any given moment” decreases “Code written”) and embed it in a larger diagram (say, including “Code written per hour of keyboard use” or “Quality of code written”) to show how there are subtler, potentially more powerful effects justifying the practices.

  It could probably also be used to discuss how XP practices interact synergistically, so using all of them is much more powerful than you’d think by measuring the effectiveness of each individual practice.

• A lot of the diagrams that he draws end up showing how increasing quality in some sense or other, while having a short-term cost, has a huge long-term (and even medium-term, probably) gain. Which makes me happy, because I like long-term gains, but I also like doing the best job at anything that I can, so it’s nice for the two of them to be reconciled!

• He spends quite a lot of time on psychological issues. One big theme that he returns to is the notion of “congruent action”, having your actions reflect the environment that you’re in and your desired goals. Obviously part of congruent action involves making the right technical and logistic choices, but a huge part of it is realizing when your and other people’s psychological tendencies may be getting in the way of congruent action, and figuring out what to do about it.

  He talks about several different psychological classifications which I found interesting. One particularly useful notion is that of blaming and placating stances. We all know about blaming stances, where, say, a manager blames a programmer for not getting a piece of software written in time for a deadline. But the flip side, the placating stance, is probably just as harmful but much less noticed, where, for example, somebody gives into outside pressure to accept a schedule that she knows is unreasonable. I think that being aware of these two stances (as well as some other stances that Weinberg discusses) will help me a lot.

• He helps me puts XP into a much broader context. He borrows on others’ work to classify software development cultures as “Oblivious”, “Variable”, “Routine”, “Steering”, “Anticipating”, or “Congruent”. (Where the latter cultures are more desirable, where Congruent cultures are currently mythical, and Anticipating cultures are currently extremely rare, and where almost all software shops are Variable or Routine.)

  If I wanted to lift a random software shop from Variable or Routine into Steering, XP is as good a way as I can think of to do it. It’s by no means the only way, but I think it’s a good way, in situations where XP is applicable.

  Also, we don’t support XP as an end to itself; we support XP because it helps us meet certain goals. And Weinberg’s notion of a Steering culture provides a good way to think about what goals might be desirable (hinted at in my list above of why I’m attracted to XP); so, if you find yourself in a situation where XP doesn’t seem to quite fit or there’s some resistance to XP, you can adopt the broader goal of changing your culture to a Steering culture, by taking some pieces of XP but by incorporating other ideas as better fits your culture.

  Once you’ve got all the XP practices, it can help you ask what to do next: think about turning your culture into an Anticipating culture. The truth is, if you’re really doing XP well, you’re probably a long way towards being an Anticipating culture, but there will be ways that you’ll want to improve your organization as a whole that are somewhat outside of the scope of XP. And, if you don’t adopt an actively Anticipating stance, you’re probably in danger of having XP rigidify, and of missing new ideas and ways in which you could improve your culture still further.

I went to a couple of talks by Alfie Kohn this week. I’ve been a big fan of his ever since I ran into an article of his in the Emacs distribution back when I was in college. His book No Contest was a big influence on my teaching when I was a grad student and postdoc. (I wish that Punished by Rewards could have been more of an influence, but it takes more bravery than I have to avoid giving grades at a school like Stanford, though I did at least spend time thinking about when I was doing so and what values I was demonstrating by the methods I used to assign grades.)

It’s been a little while since I’d read any of his books (though I had recently bought his next-to-last one, still sitting on my books-to-read stack): he’s mostly been concentrating on schools, while I’m out of teaching, and he’s saying things that, while quite sensible, aren’t opening up as much new mental ground for me as his earlier books did. But I was excited to see that he was giving a couple of talks locally, so of course I went to both.

He’s a very lively speaker, it turns out. Or perhaps I should say very lively: not gospel revival meeting lively, or anything, but he provides a quite entertaining theatrical experience. He makes just as much sense in person as he does in his books; takes a few more pot shots against people he disagrees with, but not so much as to be distasteful, especially since the evidence really is there in the footnotes in his books.

The first talk was on schooling (“Progressive Education”, I believe the title was); I didn’t see much there that I hadn’t seen in his books (though maybe that’s because I don’t think as intently about teaching now that I’ve been (quite happily) out of the teaching business for a couple of years), but it did get me thinking about ways in which Miranda’s classroom, while quite good, is less than ideal. (No disrespect intended towards Miranda’s classroom; if you know of an ideal classroom, good for you, and Miranda’s classroom does an awful lot of things right.) I sat next to one of the other parents from Miranda’s classroom; she’d recently discovered Alfie Kohn on her own, and I’d lent her my copy of Punished by Rewards; I think she’s planning to pass it on to Miranda’s teacher, with certain bits emphasized.

The second talk was on parenting; it turns out that he has a new book out on the subject, which I picked up a copy of. This talk struck closer to home: I may not be a teacher these days, but I’m certainly a parent! And it pointed out some areas where we could try to improve: we don’t use rewards a lot, for example, but we do use them a little. (And some things that are a bit borderline: from my point of view, the reason why we don’t let Miranda have dessert if she hasn’t eaten a reasonable amount for dinner is because we don’t want her to eat dessert food at the expense of a more balanced diet, but obviously one could analyze that as either a reward or a punishment as well.) Or there are areas where we tell Miranda she has to do things where we could certainly spend more time listening to Miranda and trying to find a solution where our desires (assuming they are reasonable) are met but where we do that in a way that meets her needs better as well. Good talk; I’m looking forward to reading his latest book.

I was hoping to be able to ask him what he thinks about homeschooling, especially the John Holt-inspired versions: it seems like he and John Holt would have agreed about a lot of things, but John Holt came to the conclusion that schools in general are harmful, while Alfie Kohn hasn’t come to that conclusion. Unfortunately, there was almost no time for questions at the end of his education talk, and he was too busy / jetlagged after the talk for me to feel comfortable asking him any questions. I’m e-mailing him the question, though; hopefully I’ll get a response.

I just posted the following to delany-list (and the last paragraph is a reference to another post there), but I figured it could do double-duty here as well. For those who don’t know, I’m a huge Delany fan.

I finished Phallos a couple of days ago. On the one hand, I quite enjoyed it. On the other hand, I’m rather disappointed by it, as well.

I first read part of it in a chapbook that came with, I think, 1984. From that, I got the idea that the book was about somebody searching for a copy of a book called Phallos. There was some summarizing and excerpting of the fictional Phallos (I’ll write Phallos when referring to Delany’s book, and just Phallos for the book referred to within Phallos), but I assumed that the chapbook largely consisted of that just because that was the easiest way to get a coherent extract of the full novel.

Unfortunately (as is fairly clear from the page count of the final novel), that summarizing and excerpting is pretty much all you get. It’s actually quite a lot of fun; I like the plot he’s made up for Phallos, I like the characters, and there’s typical Delany playfulness (intellectual and otherwise). But my first reaction upon finishing the book was “that was all well and good, but I wish he’d tried to write Phallos instead of a summary of it”. That would have been a book well worth reading. (Though I’m not sure he could have brought it off in the alleged 500-ish pages that Phallos is supposed to have taken up: just making the dirty bits explicit would probably have bumped up the page count most of the way to that level.)

Another possibility, suggested by my reading of the chapbook, would have been to add more of the outer story of the person searching for Phallos, as I’d initially assumed would have been the case. These days, my reading tastes don’t lean to quite that much layering, but I’m sure Delany would have done a great job with it.

Incidentally, as hinted at above, the explicit dirty bits have been almost entirely removed; there’s description of the dirty bits, but I wouldn’t call Phallos pornography at all. (Certainly not in comparison to Hogg or The Mad Man or Equinox.)

I probably would have had a different reaction if this had come out a year after The Mad Man. But we’ve been waiting a decade for another piece of Delany fiction; I expected something a little more substantial than this.

I’m pretty curious where he’s planning to go next, fiction-wise. And I’m glad that On Writing is almost done. Though, these days, I find the idea of anything by Delany being in its “last edits” almost risible…

Miranda’s cooking skills are continuing to advance: she’s working on presentation now. Last night’s dessert started with a meringue cookie, surrounded by 5 gummi bears (in a regular pentagon around it, one gummi bear of each color that we have). This represented a flower; on top of the flower, she put marshmallows, which she said was snow covering the flower. And then she put sprinkles on the marshmallows, which represented sunshine glittering on the snow.

She is fabulous.

I just finished Jak 3, for the PS2. I didn’t play either of the first two games in the series, despite their getting generally quite good reviews: the first one was a platformer, whose only apparent distinguishing feature (as far as I could tell from reviews) was that the main characters had more “attitude” than, say, Mario. Which I have nothing against, but I was (and am) pretty burned out on platformers, and I’m looking for game design advances that go beyond simply updating a genre to appeal to 14-year-olds instead of 8-year-olds.

The reviews for the second episode didn’t make much of an impression on me, either. But by the third one its gameplay style had apparently changed pretty seriously; its gameplay was much more GTA-style than platformer. At the time this game came out, I hadn’t played any of the GTA games, and felt uncultured because of that; Jak 3 seemed like a way to get exposed to the genre while still being allowed to play the game with Miranda watching.

And Jak 3 was a lot of fun! It’s one mission after another, constantly switching between genres, so you never get bored. The segmentation between missions is very subdued, so you’re constantly in the middle of action. (Impressively little in the way of load times, too.) And the action is very well balanced indeed: I frequently found myself dying, but my reaction to dying was almost never to get frustrated or to reach for an online guide, but to try that segment over and over again until I got it right. Which is pretty rare for me these days: I’ve lost my patience with games that have gameplay that I find gratuitously difficult, but gameplay where I feel like I’m getting better and am about to get past the trouble at hand is quite another matter.

So: you have my blessing to go out and buy the game; the fact that I’ve only written one paragraph about its virtues and am about to start kvetching about it doesn’t mean that it’s not quite good, it just means that its (relatively slight) flaws trigger more thoughts than its positive features do.

The cities in it are rather too linear for my tastes. In GTA, the cities have a big mesh of interconnecting roads, just like cities in the real world do. In Jak‘s cities, though, there’s basically only one path from any place to any other place. The game does use this design to its advantage – the more urban city (it’s not a good sign that I can’t remember the names of the cities, is it?) is segmented into parts that you open up after certain missions, for example, allowing the scope of your travels to gradually expand. And it keeps you busy enough with missions that you don’t have the linearness of the cities rubbed in your face. Nonetheless, it is a flaw: we’ve gotten trained to expect and enjoy wide-open maps.

As I said above, the game keeps you moving from mission to mission, but sometimes you’d like to spend time just exploring. And there is something for you to do at times like that: there are these kiosks all over the maps (for no apparent reason) that give you mini-challenges. If you complete them, you can upgrade your abilities a bit; it’s quite possible to do just fine in the game without completing them, but it’s a nice bonus if you do.

The flip side is that it’s a good thing that it’s quite possible to do well without completing the kiosks, because some of them (in particular, the ones that I happened to try first) are really tedious. They show you a spot on the map, and give you a 15-second timer to get there. Which might be fun if locations on maps had a bit more interesting visual differentiation between locations; as it is, though, all I knew was that I had to travel in a random direction for 15 seconds, and while the maps are linear, they aren’t quite linear enough to narrow the search space enough to make those challenges anything but tedious. Fortunately, not all the kiosk challenges were like that: some of them were fun platforming or racing challenges. But I got off on a bad foot with those challenges, and it took me a while before I gave them a second chance.

You have lots and lots of moves in the game: 12 different guns, a couple of different hand-to-hand attacks, 4 dark powers, 4 light powers. I can imagine a game that used that variety in order to give you a set of interesting tradeoffs at all times (though it would be hard to do); unfortunately, many of the moves I either almost never used or used only in one place (right after I acquired it) where it was essential. I would have prefered fewer choices, with more situations where you’d use each move, and where a higher percentage of your moves would be interestingly applicable in any situation.

Some of the gameplay elements were a bit much. I’m trained to accept wandering monsters as a staple of video games, but even so, having a desert that is chock full of cars which are swarming to attack you yet so weak that you can defeat dozens of them without breaking a sweat was a bit much. If the monsters had been a bit less realistic, I wouldn’t have minded (and, indeed, I didn’t mind the non-car wandering monsters elsewhere in the game that die in a similar profusion), but something about those desert cars just bugged me.

Decent plot; certainly not as intricate as, say, GTA: San Andreas, or a good RPG, but not bad for a series with platformer roots.

I’m not sure what I think about all of the race-like segments where you have to go from one ring to the next in a fixed number of seconds. It’s not a bad gameplay idea, but I wouldn’t have minded some more traditional races as well.

A good length: I’m quite happy to have played through the whole game, but I’m also happy that it didn’t drag the game out by overusing gameplay elements.

Anyways: good game, I’m glad I played it, and Miranda enjoyed watching me play it.

Series work differently in video games than they do in, say, books. In books, a sequel continues the story of the previous book in the series. And, to be sure, there are a lot of video game series that follow that same pattern: I just finished playing Jak 3, and it did continue the story from the previous two games in the series. At least I assume so: there’s a lot of what looks like backstory, though I haven’t actually played the first two games in the series. (Which, come to think of it, is another difference between series in books and series in video games: I almost never read a later book in a series without reading the earlier books first, whereas I feel fewer qualms about ignoring earlier video games in a series; more on that below.)

There are also many video game series that follow another pattern that is also familiar from books, though it shows up in nonfiction. Every year, EA Sports releases another football game, just like, every year, tax guide companies print a new edition of their tax guide.

But not all video game series follow these pattern. (Do most? I’m not sure.) Take Zelda, for example. The events of one game don’t follow the events of another game: you have a new Link saving the kingdom from a new Ganondorf, with Princess Zelda implicated somehow. Sometimes they make a pretense of tying the events in one game to those in another, but it’s clearly a sham. So instead of having events in one game follow events in another game, you have later games repeating archetypes from earlier games: there’s an archetypal Link, and archetypal Zelda, and so forth.

This repetition shows up in all sorts of ways: the species repeat themselves as well (Zoras, Gorons, etc.), settings frequently recur (e.g. the Lost Woods), the key items recur, etc. And sometimes this can be quite emotionally powerful. For me, the most surprising instance of the latter is the effects of repeating musical themes from one game to the next: I turned on the recent GBA Zelda game, heard a familiar theme, and immediately felt happy. (On a completely different note, I wonder if video games could take a lesson from Wagner and consciously use leitmotivs in their music? They could even have the music change in response to your actions: if you use some item, say, then the leitmotiv for that item could work its way into the background music. Hmm…)

To be sure, the Zelda games aren’t as similar as I’ve made them seem here: Link is in all of them, but Zelda and Ganon aren’t. Sometimes they’ll alternate more canonical games with less canonical games, for example. But in every game, you’ll see many concepts familiar from earlier games in the series.

At first, I wondered if maybe Zelda was unusual in this regard, but I think it’s a fairly general phenomenon. Take the Final Fantasy games, for example: there’s no pretense of continuing a plot from one game to the next. In fact, the differences between games are so extreme that it can be hard to say why the games deserve to all have the same name at all. To be honest, I’m not sure what they all do have in common: I’m aware of some repetitions (chocobos, the airship guy), but if you plunked me in front of a random Japanese RPG, I’m not sure if I could reliably tell whether or not it was a Final Fantasy game. I suspect that’s more my ignorance showing, though, and that real RPG fans would have no difficulty explaining what makes an FF game different from other Square RPGs or Japanese RPGs from other companies.

So why are video games different this way? One reason probably has a lot to do with the pace of technological change. The difference between different the capabilities of different generations of consoles are enough that I suspect that, if you continued the story of a game from one console onto another console 5 or 10 years later, the contrast would be quite jarring. Modern consoles, for example, allow much richer stories than earlier consoles, with much higher levels of detail in every aspect of the game. So that probably encourages reinforcing concepts at a certain level of abstraction, instead of continuing the details of a story.

We might also look into reasons why people jump into video game series in the middle, because that encourages a focus on archetypes rather than continuing stories. If you’re only now curious about, say, Harry Potter, it’s easy enough to buy the earlier volumes, or just borrow them from the library. If you’re curious about the latest Final Fantasy game, though, it may be next to impossible to get your hands on, say, Final Fantasy III. (At least legally.) Even games from earlier in this generation of consoles may be out of print; games from earlier generations are likely to be both long out print and for hardware you don’t even own. (Fortunately, console makers have started to make their hardware backward-compatible, an idea I whole-heartedly support. Admittedly, companies do reissue older games for newer consoles, which raises a whole host of questions, but not ones for this post.)

Also, if you want to read an earlier Harry Potter novel, it only takes a few hours. But if you want to replay an earlier video game, it will take up ten to forty hours of your life. I only have so much time to play video games; a series has to be pretty good to convince me to spend lots of that time on earlier games in that series. (Especially since I’m not one of the people who waxes nostalgic about earlier generations: I think there have been a lot of important advances in video game design over the years, and in general I far prefer games from recent generations to those from older generations.)

The age demographic may make a difference too, but maybe not; video game players are getting older on average, and it’s much more socially acceptable for people to continue to play video games as they age.

I wonder if books could profit from this same idea? Some books do play with this idea: for example, in Kim Stanley Robinson’s Three Californias trilogy, you see similar groups of characters in different settings in the different volumes. And, of course, mythology uses this idea all the time (e.g. the Coyote stories). Still, there’s probably more that could be done there.

I now have FC3 installed on my home and both work computers. So I spent the morning today upgrading packages on one of my work computers. It took forever, though, because the web proxy that I have to go through at work kept on corrupting data, as far as I can tell. Once I found a mirror site inside of Sun’s network, it went smoothly, but until then, it was like pulling teeth.

That was my desktop machine at work. I’d already finished upgrading my work laptop on Monday; it was in a somewhat iffy state, because I’d done a botched partial install last week (not believing that my CD’s could really all be bad), so it had a bad mixture of packages. I thought it was all sorted out, though.

Today, however, something else seems to have gone wrong with my work laptop: rpm (the package manager) seg faults whenever I try to invoke it. Which is a really unpleasant situation to have to recover from: I can’t just, say, install a new package for it, because I’d have to use it to do the installation! I have no idea what could have caused this (it was working fine yesterday, after all); maybe the hard drive in that machine is going bad? (It seems to be generally falling apart – last Thursday, its display was behaving very strangely, too.) The botched upgrade and the seg faults might convince me to just reinstall the OS from scratch: I almost never use that machine, so there’s none of my personal stuff on it.

And then, when I got home and tried to import some more music into my iPod, Windows complained about a corrupted file. After a bit of poking around, it turned out that the corrupted file was on the iPod itself. (Windows could have told me that in the error message…) Fortunately, the error message told me what to do about it, so I fixed it, and everything seems to be proceeding smoothly. I would chalk this up to the costs of jogging while carrying around a hard drive, except that I haven’t gone jogging since the last time I imported some stuff, and it worked fine then.

So I seem to be a computer disease carrier right now. Maybe I’m giving off really powerful magnetic fields, or something…

It turns out that, if you poke around enough at the boot: prompt, you get told about an option for where to find the images to upgrade from. So, a couple of hours of installation later and a couple of hours more of package upgrades later, here I am. Yay.

No big differences are yet obvious. Some different fonts in my browser, a second toolbar appeared on top of the screen (which I have summarily dismissed), but everything seems to have proceeded smoothly.

Next time I’ll probably not wait as long after the OS is released before upgrading. And I’ll know that I only have to burn one image to a CD, and it doesn’t even have to work very well: it just has to work well enough to get into the installer.