malvasia bianca

Reading Christopher Alexander reminded me of Jane Jacobs, so, since I had a copy of her latest, Dark Age Ahead, on the to-read shelf, I decided to read it next.

She’s quite an author. She’s most famous for her first book, The Death and Life of Great American Cities, but she’s hardly a one-trick pony. After that, she moved on to economics, preaching the powers of import replacement as the key mechanism to economic growth. This is when a region becomes able to manufacture items that it had been previously forced to import; this is, obviously, good for that region, since it can get the same level of goods while sending less money (or goods) out of the region in return. (And it may well be able to export the item in question, too.) The interesting thing is that it’s not necessarily bad for the rest of the world, either: while the external region that had previously been supplying that item isn’t likely to be thrilled, the import replacing region will still have money to spend, so it may start importing something else instead, bolstering the growth of some other region.

But she’s not even a two-trick pony: she also wrote Systems of Survival, which is a dialogue on morality, a form and topic that are both decidedly out of fashion. Gave me things to think about; I should reread it at some point.

Her latest book is, as you might suspect, a bit on the dire side. She thinks that there’s a serious possibility that the US and Canada (and possibly more of the world) are about to enter a phase of serious cultural decline. The five problems that most concern her are: “Families Rigged to Fail”, “Credentialing Versus Educating”, “Science Abandoned”, “Dumbed-Down Taxes”, and “Self-Policing Subverted”. Some familiar themes: the first talks about how communities have been destroyed over the course of the century, which we’ve seen both in her first book and in the aforementioned Alexander book. Education’s increasing focus on credentialing is one of my pet peeves, too; it was one of the things I most disliked about teaching, and I wish I knew how to best mute its deleterious effects on Miranda.

The taxes section is interesting. In her books on economics, she says that it’s harmful for regions’ economies to be too closely linked: what is good for one region may not be good for another. (And, as evidence, she claims that nations tend to have one dominant economic region: Paris for France, London for England, etc.) One reason for this is that the natural effects of inflation and deflation are a good form of feedback: for example, economically weakening regions will tend to have their currency drop in value compared to their neighbors, which means that they can export goods at lower prices, which helps them. (And it means that it’s more expensive for them to import goods, which encourages import replacement.) So she doesn’t like shared currencies. (Just what are the arguments in favor of shared currencies, anyways?)

She generalizes this to a feeling that, whenever possible, regions should have control over their own destinies: the closer a government is, the more likely it is to be able to spend money effectively. She also feels that, in general, local governments should be able to keep their own taxes: she’s not a big fan of regions artificially propping up other regions.

Here, my feelings are more mixed. In general, I support the haves sharing with the have nots, so I wouldn’t want to go too far with local control. (For example, I think it’s an awful idea to use property taxes as the primary funding mechanisms for schools.) But I don’t think Jacobs is that heartless, either: I’m fairly sure that she supports, for example, subsidizing cultural programs that can’t always pay for themselves. And, to be sure, I would also tend to support assistance that leads to self-sustaining groups wherever possible. (Though I emphatically do not support assistance programs that declaring by fiat that their recipients’ becoming self-sustaining without supporting evidence, or programs that are actively harmful to their recipients.) I suspect that she has well-thought out positions on these matters that I would end up agreeing with; I just don’t quite understand what it is yet.

Worth reading, as are all of her books. I also recently ran across a good interview with her. She must be a lot of fun to talk to.

We recently watched The Cat Returns. One of only two non-Miyazaki Studio Ghibli movies that I’ve watched, the other being Grave of the Fireflies. And the two couldn’t be more different: the latter is very good, but very, very depressing; I honestly have no idea when I’ll be up for watching it again.

Anyways, The Cat Returns was fun, but hardly a masterpiece. Rather slight, which can be fine, but the word “cool” is way overused in the movie. I quite liked the designs of the city and castle; Miyazaki’s locations are wonderful, and you can see some of that in this movie, too.

Miranda’s watched it several times; it’s pleasant enough to have on in the house, so I’m not complaining.

E3 is over now. The PS3 looks good; presumably somewhat more powerful than the Xbox 360, but it’s hard to say for sure, and some of the ways in which Sony is promoting its graphical superiority seem, honestly, kind of silly. It can connect to two TV’s? It can do 1080p, not just 1080i and 720p? Big whoop; when I have two 1080p TV’s around, then I’ll care about that, but not before.

Nintendo is disappointing, though. They always downplay the power of their technology (and I don’t understand why: Gamecube games really do look better than PS2 games, but you’d never know it listening to them), but now they seem to be giving up completely on that front. Innovation is all well and good, but I just don’t see them as coming up with any great ideas that are so strong as to offset plain old processing and graphics power. Maybe their new console will end up more powerful than they’re currently claiming, but I’m not optimistic.

It is cool that they’ll enable you to play games from all their previous consoles on it. (And it’s great that the PS3 will be backward compatible all the way back to the PS1.) But games these days are a lot better than games from a couple of generations ago, and I’ve already played most of the famous NES and SNES games in remakes, so I don’t see that making a big practical difference.

Not too much in the way of interesting game announcements. The new Zelda looks great, but we already knew that. I continue to look forward to Okami. Really, it was all about technology this time; and I’ll be the first to admit that I’m looking forward to the next generation of consoles, even if I don’t quite know what I’ll be playing while waiting for them to come out…

Last night I was planning to go to a talk, but I decided at the last minute to stay at home instead. Which meant that we didn’t have any dinner planned, and neither Liesl or I was up for anything elaborate anyways.

The solution was the excellent Pasta Rouille avec Thon. It has the virtues that:

• It’s quite yummy.
• It’s quite easy: the sauce doesn’t require any cooking, and there’s next to no chopping.
• All of the ingredients are non-perishable (except for garlic, but who doesn’t have garlic lying around?), so you can pull them out of the pantry whenever the urge strikes.

I got the recipe from Jordan (who will be happy to extol its virtues as well), who clipped it from the Washington Post; I don’t know what the original source was. Here it is, for the sake of harried cooks everywhere.

Pasta Rouille avec Thon

7 oz. roasted peppers
2 flat anchovies
2 large cloves garlic, coarsely chopped
2 tsp oregano
1/4 tsp salt
1/2 tsp pepper
1 tsp sugar
1/4 cup olive oil
7 oz can tuna, drained and flaked
1 Tbsp drained capers
red pepper flakes, to taste
1 lb short pasta

In blender, blend peppers, anchovies, garlic, oregano, salt, pepper, sugar until smooth. Add olive oil, blend some more. Put in bowl, mix with tuna, capers, red pepper flakes. Cook pasta, drain, toss with sauce.

E3 has crept up on me, but press conferences would seem to be going on as I type this. I followed the Xbox 360 unveiling last week; looks pretty cool. There were rumors that the console was going to be a bit underpowered, but Microsoft has apparently changed its mind: three cores each of which can run two threads (multithreaded world, here we come), plus a GPU that can do a trillion floating point operations a second, sounds pretty good to me. Maybe Sony’s super-spiffy-magic cell processor will beat that, but I have a hard time imagining that there will be a big performance gap between the two.

It’s interesting to see console designers finally converge on what functionality a controller should have; I agree with their answers. Two joysticks, one D-pad, four face buttons (plus a glorified pause button), four triggers. And an agreement that rumble is nice, but not at the expense of wireless. I like the designs where one trigger on each side is deeper and has analog functionality (much better for driving games than overloading the second joystick for accelerate/brake), and I don’t want analog functionality anywhere else other than, of course the joysticks. And I like the somewhat asymmetrical and colorful layouts that make the key controls easiest to reach, and that make it clear which face buttons are the most important ones (for games that don’t use them all equally); hopefully Sony will learn from Nintendo and Microsoft in this regard.

Of course, for all I know, Nintendo will introduce some completely bizarre controller tomorrow; they seem to like doing stuff like that. Still, I doubt it can be too weird, because their new console will be backwards compatible. I suppose they could just require you to buy Gamecube controllers to play Gamecube games, though.

One thing that I’d been wondering about: will the new Xbox be backwards-compatible with the old one? Last week’s press announcements didn’t say anything one way or another, which makes me think it’s still up in the air. Which is a little frustrating, because the recent release of Jade Empire, combined with the dearth of games for other consoles, makes me want to buy an Xbox now, so I’m trying to figure out whether or not I should give in or hold off half a year and just pick up an Xbox 360. That’s kind of silly, though – the current console is cheap enough now (and you have to think they’ll drop the price again any day now), and the new one will probably be hard enough to get right after launch, and packaged with tons of crap that I have no desire to get, that there isn’t much financial reason to hold off. So probably the best thing to do is, once I get tired of Gran Turismo 4, to just go out and buy an Xbox, spend the rest of the summer and fall playing Shenmue II and Jade Empire, and buy the next generation of consoles whenever the games force me to do so.

I never would have guessed when Microsoft bought Rare that they would have exactly one game to show for it at this point. (Plus another game to be released in a month that’s a remake of an N64 game.) I mean, Kameo showed for a couple of E3’s as an N64 game, but it not only didn’t release for the N64, it missed the entire next generation of consoles! Despite that, Perfect Dark Zero may be enough by itself to convince me to get an Xbox 360. I’m not a big FPS fan, but I really liked Perfect Dark: in particular, the cooperative scripted deathmatch missions are by far my favorite way of enjoying an FPS.

Even there, though, I’m probably in a minority: everybody else is waiting for Halo 3 for their FPS fix. I don’t know if I’ll buy the first two games in that series: on the one hand, I feel pretty uncultured because I haven’t played them, and I’m sure their multiplayer play is excellent. On the other hand, I’ve heard some bad things about their single-player modes, and I don’t have enough friends around to play it with. So I’m torn; it will probably depend on the lulls between new game releases. The best solution would be for me to have more friends around to play video games with, of course…

I just finished A Pattern Language, by that favorite architect and urban planner of programmers everywhere, Christopher Alexander. (Actually, while Alexander gets the lion’s share of the credit in subsequent references, the front cover lists “Christopher Alexander, Sara Ishikawa, Murray Silverstein, with Max Jacobson, Ingrid Fiksdahl-King, Shlomo Angel” as authors.) My main reaction was “this book was published almost thirty years ago; why haven’t we learned anything from it since then?” Not that I’m really surprised by that: lots of the same lessons were in The Death and Life of Great American Cities almost two decades earlier, in particular the importance of vibrant sidewalks, and how mixing stores with housing is key to that.

Alexander’s book, however, differs from Jacobs’ in being 1100 pages of concrete recommendations. (Only a third of it is urban planning: the rest is on smaller-scale matters.) Some of it I’m dubious about (e.g. City Country Fingers – in general, I’m not as convinced of the wonders of countryside as he is), some seems nice but idealistic (Self-Governing Workshops and Offices), but some of it is wonderful, often in surprising ways. Green Streets is an example: one of the book’s strengths is that it acknowledges the current importance of automobiles, while presenting methods for minimizing their impacts, and this pattern suggests that, if you have a pathway that cars have to occasionally pass through, you should create it by inserting paving stones into grass (with gaps between, so grass grows everywhere), instead of by paving the pathway completely. That way, it makes it clear that the cars are only there by sufferance: the conceptual change is huge, and as a practical effect cars also drive a lot slower and more carfully in such areas. I don’t know for sure if it would work or not, but it sure sounds like it’s worth trying.

When the patterns get smaller in scale, I start looking around our house (and the townhouse complex), seeing which patterns we follow, which we don’t, and how well they work. I love the house outlines that he creates motivated by Light on Two Sides of Every Room (with the help of other patterns, such as Wings of Light and Cascade of Roofs); a pity we’re missing that so completely. (But then where would our bookshelves go?) At first, I thought that the balconies in our complex are completely unused (except by one cat) because of Six-Foot Balcony, but now that I’ve actually measured our balcony’s depth, that’s not the answer: it’s not quite six feet deep, but it’s very close. Probably a better answer is that the balconies aren’t taking into effect the public-private dynamic: they’re off of the master bedrooms, and I suspect that balconies are more effective when they’re off of public areas. Also, most of the balconies don’t get much light. (In general, we do a lousy job of South Facing Outdoors.)

Given that we can’t change many things about our house, how can we bring out more of these patterns? Our piano is placed where it is as an attempt to hint at an Entrance Room, and to improve the Intimacy Gradient (which I read about in The Timeless Way of Building); I think it’s been reasonably successful at that. We don’t have a lot of windows, but perhaps we could make a better use of the ones we have: could we create a Window Place or two? Is there anywhere we could hint at Alcoves? Could we reclaim the master bedroom as semi-public space somehow (leaving the Marriage Bed at one end, of course), and as a result use the balcony better? Something to think about…

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.