Watching Merlin Mann’s Inbox Zero video and reading the preceeding articles was the impetus for the final push to zero. It’s not that there’s anything I didn’t know in there. But there was the sense that it was not only possible but achievable.

So I immediately did what Mann suggested not to do and spent, oh, a full day changing email clients from mutt to sup. It sounds like an awesome amount of time-wasting, but I read the sup philosophical statement a while ago and it resonated:

The problem with traditional clients like Mutt is that they deal with individual pieces of email. This places a high mental cost on the user for each incoming email, by forcing them to ask: Should I keep this email, or delete it? If I keep it, where should I file it? I’ve spent the last 10 years of my life laboriously hand-filing every email message I received and feeling a mild sense of panic every time an email was both “from Mom” and “about school”.

The flip side of this is that once if you’ve set up automatic filters you have to remember to go check those folders, which is a habit I’ve never been able to form. And once I’ve ignored a folder for two weeks, hell, I’ll leave it another day or two, why hurry to find out if I missed out on something interesting or if I let someone down? Or three days. Or…

And so I’ve poured all of my email into sup’s index and started mercilessly hacking away at that last couple hundred messages I hadn’t yet dealt with. Read and delete, or archive, or note on my to-do list, or suck it up and start another email with “I’m sorry it took so long to get back to you…” And now it’s cleaned out, to my pleasant amazement.

There is, of course, the terrible chance I’ve missed something important, but I couldn’t let that risk of something getting lost in the upheavel continue to paralyze me. Perfect is the enemy of good. If you’ve been waiting on a reply from me about anything and didn’t get it in the last few minutes, I’m sorry, please let me know. And if you’ve thought about contacting me but haven’t because I did so poorly with the last few emails, I’m sorry, I’m going to keep trying to do better.

I violated CQS in part of the design of ListLibrary.net (mentioned here). It was both beneficial and harmful (especially in debugging).

Emails are threaded together to show the flow of responses. In this example Chris, Mike, and Jon all responded directly to Tiago and there was a series of responses to Mike. It’s difficult to put these threads together well because email clients often don’t (accurately) include the metadata to specify the message an email is responding to. You sometimes just have to guess what goes where, and it’s further complicated by messages that are lost or (in date-organized archives) split off into other directories.

I started with the threading heuristic by JWZ. It’s a well-described, often-implemented bit of code. I implemented in two steps: first, as messages are added, their references are examined to do some basic relatinships between them (JWZ’s step 1). The rest of the steps require more computation and are more likely to be invalidated as messages are added, so I do them lazily: the threading is calculated (and cached) when it’s requested… violating CQS. The query to list the threads in a message also acts as a command to generate them.

This is both a performance win (yes, I tested) and leads to better-threaded messages, using all available messages are in reduces the amount of ambiguous situations it has to guess at, which can persist even after adding other messages that would have resolved it. But it’s also a great way to make my life difficult in testing: when I insert debugging queries they can trigger commands that change the way messages are threaded. It creates heisenbugs, bugs that appear, disappear, or change when they are being debugged.

I was really frustrated by heisenbugs for a while: I need to violate CQS for performance, but I’m creating all this extra work for myself in the most complex piece of the codebase. The solution is to create referentially transparent query commands specifically for debugging. They’ll introspect on the internal data structures and present them in their raw forms without triggering threading (making them useless for non-debugging work, but that’s OK), and their tests can confirm this.

I find the CQS principle to be a really useful tool. Its application leads to better-designed and easier-test code, and its violation can indicate bad code (a Code Smell).