Mitch's Blog

(If you just want to read why Sanebox rocks, scroll down.)

Remember Xobni? Originally they were a plug-in for Outlook that did a few things–when a message was viewed in the normal Outlook interface, the Xobni plug-in would show other emails you had exchanged with the sender and it would show files that had been shared with the other person via attachments. The Xobni plug-in showed social information about the other person–profile pictures from LinkedIn, number of connections, and so on. And finally, the Xobni plug-in enabled better search for email than Outlook had.

Adam Smith, the founding CEO, gave a talk at MIT and for years, one of the things he said has been stuck in my head: “If you can improve email just a little bit, then you can create a lot of value.”

Mr. Smith was absolutely right. Email is incredibly bad for how it is used in most workflows today. In 2010, Mr. Smith left day-to-day activities with Xobni, and I’m afraid the company lost their way, becoming a contact tool rather than an email tool somewhere along the way. That didn’t work out well for Plaxo and I am not convinced it will work for Xobni. For a few years now, there hasn’t been any innovation in email that was interesting to me.

But in the last few months a few things came to light:

Mailbox, recently acquired by Dropbox. Mailbox built an incredible amount of hype, had a great video that looked interesting, got accused of some pump and dump action with TechCrunch, and ran up to over a million users quite rapidly. I lost interest in the app within minutes of using it. It was clear it was not going to scale to the amount of email I had in my inbox. One feature I did particularly like about Mailbox was the concept of putting an alarm on an email (e.g., a reminder to re-triage this message in a day).

Then there is Mailstrom. I am not really sure what Mailstrom does, but it sends me weekly reports of what’s going on in my inbox. There’s a tool you can use if you remember to go to their site and want to tediously triage stuff. I don’t want to do that. The web site talks about getting to Inbox zero, but I will never pull it off with what they offer. The report is kind of cool though:

Finally, there’s Sanebox. Sanebox analyzes the patterns of to/from in your inbox and sent mail and automatically moves emails to a folder called @SaneLater if it doesn’t believe you will be replying to it. So all bulk email ends up in @SaneLater. This has made dealing with email a ton easier. Sanebox also puts emails older than about 8 or 9 months into a folder called @SaneArchive. I went from 30,000 emails in my personal Inbox to just 1,700 in my Inbox and 1,800 in @SaneLater. It is now much easier to see which emails require replies.

Sanebox offers a free trial that runs about 2 weeks. Towards the end, they convert customers with a genius piece of messaging (paraphrased): “Hey, if you don’t pay us, we’ll move all your email back the way it was!” Brilliant–I bought it.

Email still sucks. But Sanebox has made it suck a bit less. And the best part is that there is no additional user interface to use.

Do you find yourself saying things that are so absurd you’d not believe it if you hadn’t lived through it? I’ve had a few of those experiences.

I once worked at a software company that had a strong unit test culture. There were specifications for everything and tests for everything. Sounds great, right? Unfortunately, despite extensive review meetings, the specifications never survived the few first days of coding. The unit tests were detailed and thorough–fantastic! But no one ever ran the whole product in-house. QA didn’t. Developers didn’t. The company didn’t use its own product because “it is too complicated.” After I left the company, I had a problem that the company’s product was designed to solve. As a shareholder, I was interested in the company having customers, and happy to be one. I downloaded the product and installed it. When I fired it up, the product crashed about 3 lines into main(). No one had ever used the product. It’s great to prove that the pieces work individually, but your customers will be using them when they are all bolted together. You have to make sure the holes line up.

I also once worked at a company with the exact opposite approach. There were no unit tests of any kind. No libraries, no modules, nothing. The only way to test anything was to run the product. This meant there were very few crashes on the third line of main(), but it also made it impossible to know whether or not any of the pieces of the code work independently. If you can determine whether pieces work independently, you can track those results, tie them to check-ins, and suddenly understand a heck of a lot about what changes in your source control impacted what areas of the product. You can track down not only data corruption but also which modules hit performance issues, whether within a unit test context or within an integration context within a customer environment.

The first company had a hard time getting customers to be successful with the product. The second company had difficulty predicting when a release would be ready. The former is easier to fix–start using the product internally and also fix the QA organization to include system tests. The latter likely entails an expensive refactor and reflects deeper cultural issues of a hacking organization rather than an engineering organization. Neither extreme is healthy.

Over the last 25 weeks, I’ve been trying hard to do very little beyond sleep and goof off. Even though I don’t have a job and have been considering myself on vacation, looking back at my calendar, I still managed to do over 100 business-related meetings and spent 4 weeks on the road. Nevertheless, I’ve been relaxing–I bought a Playstation Vita last March and didn’t start playing it until January.

I’m starting to get going on a few projects and as I fiddle around with possible next directions, and come to realize that I don’t have enough desk space to juggle completely different activities that hit creative road blocks. I was at a stand-still most of last week because my desk was covered with a project that wasn’t going anywhere. I needed another desk to dump it on so I can still look at it, but engage on another project while it percolates. Since I’m doing some other remodeling this year, I started looking at reclaiming my closet (which is just a junk room) to pick up an extra 35 sq ft of “spreading out” surface area.

I’m also finding that I have too little in the way of filing space–despite moving most “archive” files into banker boxes and shredding about 60 gallons of files, I still lack sufficient filing space. So this configuration adds a second linear file cabinet.

Some other remodel considerations for the office:

1. Build a large built-in bookcase at the front of the office. In this configuration, it will hold most of my office-related books. Barely–which would be a big improvement over the current situation. Below is a rendering that my architect created of the bookcase. I also plan to reclaim space under the eave to put the stereo without it taking up floor space in the room where it currently resides.

2. Remove the chimney. I should have done this 5 years ago but felt like I had feature-creeped on the first remodel too much as it was. To finish a software release, you have to stop adding crap to the release and get things fixed. The same applies to a remodel.
3. Finally install a split AC system. I got a quote for this years ago, but could never get the fellow to come out and do the work.

Sadly, remodeling in real life isn’t as fast as a few hours of monkeying around in SketchUp… so until then, piles of stuff it is!

If you came to this post hoping to read about what I’m working on and you weren’t happy to hear about goofing off, come back in 25 weeks!