Code Review Bingo

Just about every working programmer learns to abhor code reviews. It’s not that we dislike them in the abstract, or deny that they’re necessary, but the actual process of sitting through a code review can often be excruciating. The only exceptions seem to be the people who seem to expect kudos for their “diligence” in reviewing everyone else’s work in excruciating detail even as their own paltry work product is somehow never presented for similar scrutiny. Every group has at least one of those, so reviews often tend to degenerate into a contest to “score points” at the expense of the person whose code is being reviewed. To make this at least a little bit fun for those who do not enjoy such sport, then, I’ve developed Code Review Bingo. Here’s a sample:


Yes, I know many of these belong in design reviews or other kinds of documents. That doesn’t stop them from popping up in just about every code review. Similarly, many of the comments directly contradict each other. Since most code reviews involve multiple reviewers, such conflicting demands are common. When one or more reviewers’ only goal is to show how smart they are – God forbid we spend that time finding actual bugs or improving code – it’s not even uncommon for the conflicting demands to be made by the same person, so don’t worry that your card can’t win.

Enjoy, and don’t be shy about suggesting your own additions based on your own experience. The items are stored in a simple text file, and I’ll gladly make the source available to anybody who wants it too. BTW, for those in the audience who might wonder: no, this is not a reaction to having my own code reviewed recently.

Back in Chicago

Yes, really. My luggage is probably in Boston by now. I originally had a 6am flight through Washington, but missed it – I got to the gate before it left but couldn’t board – due to absurd delays at both the United checkin and the Travesty of Security Appearances. Why book a dozen flights off one runway at the exact same time, creating a logjam at the insecurity checkpoint? They booked me on another flight through O’Hare, but that got canceled. Second try through O’Hare went through de-icing delays at both ends but did get met here. What’s the point of a twenty-five-minute de-icing on arrival, forcing dozens of passengers to miss their connections, when you’ll just have do de-ice again before the next departure (as had been done on our flight)? The United “customer service” area in concourse C had no United employees, and a two-hundred-yard line waiting for the self-serve kiosks. All of the Boston flights seemed to be from concourse B, so I headed over there to find a nearly empty similar area. The first kiosk asked me if I was going to Vancouver, then told me to pick up the phone when I said no. The phone gave me a wrong-number recording. Second kiosk went through the same routine, but this time – after a five-minute wait – I got to talk to a real person on the phone. She managed to get me on a new flight, but the kiosk gave me a printer error instead of a boarding pass. Finally, the third kiosk managed to choke out a boarding pass.

At the end of all that, here I sit at the gate waiting for a noon (central time) flight. After that I have to find my bags and then a way home. Whee.

New Year (almost), New Theme (almost)

As I’m sure reading this on the site itself and not in an RSS reader have noticed, the look here has changed. I like this new theme visually, but functionally there some things I’m not sure about – especially the fact that it only shows the contents of only the most recent post and just titles for the rest. Please let me know what you think; if others seem to share these reservations I’ll either fix it or revert to the old theme.

UPDATE: never mind. Other people commented on the same display-one-post issue, confirming my impression that it was a bad idea. That’s a pity, because I like other things about that theme (“sunset”). Instead I’ve switched to another theme (“fall colors”) that I also like, and tweaked it a bit. Let’s see how that works out.

Weather in Chicago

I lived in Michigan for ten years. I’ve always thought they actually did a bit better than Massachusetts in terms of clearing snow and ice off the roads promptly, and that Illinois would be more like Michigan. So, how is it that last night, during a not-particularly-huge snowstorm, I saw only one snowplow and that with its blades up? How is it that I saw no salt trucks whatsoever, nor any evidence that they exist in this state? The whole way back to my hotel, on an interstate, I was driving over inches of snow that had been churned by many cars’ tires but never disturbed by plow or salt. Has the budget for road safety been eliminated? Is everyone in government so consumed by the latest political crisis that they forgot to do their jobs? If the roads had been like that in either Michigan or Massachusetts, heads would be rolling.

Screen For Your Fingers

I got myself an iPod Touch for Christmas, and I bought it early because I’m leaving on an almost-a-week mostly-business trip (my longest since Amy was born) tonight. It rocks even more than I thought it would, but that’s another blog post. Amy found it quite interesting too, and this morning she asked where the “screen for your fingers” was. What a great way of describing it.

OOOOPS!

NPR says Obama Names Pulitzer Prize Winner To Energy Post and everybody repeats it. Problem is, as far as I can tell, Lawrence Berkeley National Laboratory director Steve Chu won a Nobel prize. His “About…” page prominently mentions that fact, but doesn’t mention a Pulitzer, even though having won both (has anyone?) would certainly seem rather noteworthy.

The Memory Wall

Last week, the geek community discovered the “memory wall” which occurs when adding more processing power to a chip (currently in the form of more processor cores) fails to improve performance because memory bandwidth becomes the limiting factor. This phenomenon has been known in some circles for ages, of course. Matt Reilly has been talking about this for years, and I think he has some graphs that show how memory bandwidth per core has actually gotten worse lately as the number of cores per chip has increased (but I’m too lazy to find them right now). In any case, now Ars Technica and Slashdot readers know about the memory wall too, thanks to a recent Sandia report that shows performance actually declining after ~8 cores per chip.

What it all comes down to, really, is that if you want systems to get faster you have to add more than one kind of capacity. Adding more CPU cycles doesn’t help if you don’t add more memory, and more bandwidth to that memory. Many would argue that you also need to add communications and I/O capacity as well, but I’ll leave that alone for a moment. One approach that the young ‘uns at Ars and /. pounced on was having chips share each others’ memory controllers in a NUMA system. The problem is, we’ve already been down that path. I was there, hardly the first, and I had lots of company. NUMA is great, but I don’t think it’s going to solve this particular kind of problem. For one thing, the problem is in the ratio between cores and memory controllers, and NUMA doesn’t change that. A system that’s already hitting the memory wall with four-core chips isn’t going to get any better if you add more four-core chips, and might even get worse due to thrashing.

The other problem is that NUMA systems never scaled that well beyond 32-64 nodes or so even when nodes were borrowing from each others’ caches, and I haven’t heard of any fundamental breakthroughs that would change that. What people are talking about nowadays is even harder, though – nodes borrowing each others memory controllers. I’m no chip designer, but my impression is consuming resources on both sides of the transaction for that long (this is a long path in CPU terms), and all the logic to coordinate between them through all possible sequences of events, is likely to make life for those chip designers rather difficult.

Last time around, most people who actually worked on this stuff eventually reached the conclusion that – for performance reasons, for reliability reasons, and for cost reasons – explicit communication between processors was preferable to the implicit kind that occurs by putting all processors into one cache/memory address space. Think Beowulf. Think MPI. Think shmem and UPC and GASnet and all those. It means that programmers have to re-think some of the ways they write code, but this model is already de rigueur on all of the truly big systems solving the world’s hardest computational problems. If we really want to crack the memory wall, we shouldn’t repeat the mistake of trying to build hideously expensive memory systems to support a programming model that will fail anyway. That killed plenty of companies already. Instead, we should try to build components and systems to support the more mature programming model(s) that professional parallel programmers are already using.

Hey, Red Hat!

Somebody at Red Hat is linking to my site, but the two referrers I see are both internal so I can’t see why. One of the links is a search page; the other seems to be a post to a mailing list. Could someone at Red Hat please look at the post and tell me what it’s about? Thanks.

Liveblogging My Company Meeting

Q: Are day-care expenses covered?
A: Yes.

Q: But private schools are not?
A: Correct.

Q: So it’s OK as long as we don’t educate them?

Rock-Paper-Scissors Chess

In my never-ending quest to be geeky in more ways than anyone else on the internet, I’ve invented a chess variant that incorporates the RPS dynamic while still (I hope) remaining playable. RPS is not only a game in its own right, and apparently one that some people take rather seriously (there’s also a 25-gesture version), but it’s a dynamic that appears in many other games. In wargames it’s often a range/mobility/defense triangle. For example, in a medieval wargame, long-range archers might be devastating against low-mobility infantry but vulnerable to high-mobility cavalry, while those cavalry in turn can’t get past the strong defense of massed infantry with pikes. Here’s how you apply the same idea to chess.

  • Paper = pawns. Rock = rooks and queens. Scissors = knights, bishops, and kings.
  • Members of every class can take other members of their own class, plus the next one in the circle. For example, a pawn can take another pawn, a rook or a queen, but not any of the “scissors” pieces.

What this does is make a lot of capture/recapture scenarios asymmetric. A pawn attacked by a knight and defended by a pawn is still vulnerable, because the pawn won’t be able to recapture the knight. This has some less obvious effects on strategy.

  • Some openings become much less effective. For example, Philidor doesn’t work because it’s an instance of the example above. On the other hand, Ruy Lopez still works because the pawn is defended by a knight, and Petroff still works because it’s more of a counterattack.
  • Bringing the queen out to b3 to attack b7 (one of my favorite motifs) is no longer as effective because the queen can’t take the pawn at b7. On the other hand, bringing the queen out to the king-side might be more effective because it can’t be harried by a knight. This also makes the fianchetto more risky, since the bishop won’t be able to defend a knight at c3/c6/f3/f6 that’s threatened by a queen.
  • A lone king is no longer helpless against two united passed pawns, because it can approach or capture the frontmost without being in check.

The last point I think is particularly important with respect to changing how endgames work, and how players maneuver to get a favorable one. At first I wasn’t wild about kings being so totally helpless against rooks and queens, but then I realized that such endings are generally a foregone conclusion anyway. They’re only tedious, not difficult, most of the time. Making them less tedious doesn’t seem like such a bad thing after all.

Some day when I have some spare time, I might take an existing chess program and modify its move generator to eliminate certain captures according to these rules. The position evaluator will be a bit askew, so the program won’t play strategy well, but most programs can beat me easily on tactics anyway so that’s unlikely to be an issue.