Loving IRCCloud

I tend to use pretty basic (and preferably cross-platform) software so I can be comfortable on systems that aren’t highly configured to my specific taste. I don’t change the software I use on a daily basis very often. However, I recently switched away from the IRC client that I’d used heavily for many years, and started using IRCCloud instead. I’m so happy with it that I thought I’d write about it.

I used Colloquy, and I was pretty happy with it. It’s about as good as a native application IRC client can be. It has two major down-sides though, both of which are consequences of its being a native application.

First of all, when my computer was off or asleep, or I forgot to start the application for some reason, I was offline. I frequently missed interesting public conversations and private pings.

The second problem is that Colloquy only works on OS X, and if I’m using different machines I have to configure an IRC client on each one. I’m frequently using a couple of machines at the same time, like an Apple laptop with a bunch of OS X-specific applications open (e.g. iTunes, Word) and a Linux machine that I’m writing code on. If I want to copy/paste something to IRC from the machine that isn’t running Colloquy, I can’t unless I quit Colloquy on OS X and start some other IRC client on the other machine. Not being able to easily be on IRC with the same nick from multiple machines was annoying.

About six weeks ago I signed up for IRCCloud, based on a blog post I had read. Once you create an account, you can configure it just like any other IRC client and connect. The connection is persistent, so you’re online on IRC even when you’re not on the site. When you log on again, you can see what you missed in public rooms, as well as any private pings you might have missed. Fantastic. Because it’s a web application, it works on all platforms. You can even be logged in from multiple machines at the same time!

Switching to IRCCloud has improved my IRC experience immensely. I highly recommend it if you’re a regular IRC user.

Simple Code Review Checklists

What if, when giving a patch r+ on Mozilla’s bugzilla, you were presented with the following checklist:

You could not actually submit an r+ unless you had checked an HTML check box next to each item. For patches where any of this is irrelevant, just check the box(es) – you considered it.

Checklists like this are commonly used in industries that value safety, quality, and consistency (e.g. medicine, construction, aviation). I don’t see them as often as I’d expect in software development, despite our commitments to these values.

The idea here is to get people to think about the most common and/or serious classes of errors that can be introduced with nearly all patches. Reviewers tend to focus on whatever issue a patch addresses and pay less attention to the other myriad issues any patch might introduce. Example: a patch adds a null check, the reviewer focuses on pointer validity, and misses a leak being introduced.

Catching mistakes in code review is much, much more efficient than dealing with them after they make it into our code base. Once they’re in, fixing them requires a report, a regression range, debugging, a patch, another patch review, and another opportunity for further regressions. If a checklist like this spurred people to do some extra thinking and eliminated even one in twenty (5%) of preventable regressions in code review, we’d become a significantly more efficient organization.

For this to work, the checklist must be kept short. In fact, there is an art to creating effective checklists, involving more than just brevity, but I won’t get into anything else here. My list here has only four items. Are there items you would add or remove?

General thoughts on this or variations as a way to reduce regressions?