Should you censor your emails?

Gagged

Photo by Meredith Farmer

I enjoyed reading the extracts from the S&P IMs and emails, especially the delightful image of cows arranging the debt structure. It's satisfying on a primal level to have some individuals to blame for the mortgage implosion. I'm worried though that the wrong lessons are being drawn. Here's a comment on that article:


1. Never email something you can say over the phone.

2. Never say something over the phone you can say in person.

3. Never say something in person that can be understood with a wink and a nod.

And never leave a voicemail that says anything but your name, number and asks the person to give you a call back.


That's probably sensible advice, but it's also very depressing. It's throwing away all the advances in speed, permanence, and searchability that we get from modern technologies like email or IM. If we all have to act like conspirators, it makes us a lot less productive. Even humor is a vital part of turning a bunch of individuals into a team, and Henry Blodget, who should know, comments:

It's the folks who are just chattering and venting to colleagues about
normal business tensions who are most at risk. The computer doesn't
capture the wink or head nod. It doesn't say "this is my first
reaction…when I have considered everything in detail, I'll give you
my final opinion." Etc.

I haven't read the S&P stuff, so I don't want to take a
position on the folks who wrote those specific emails. But I'd venture
to guess that, if you sat them down and asked "Was it your professional
opinion that the product you were rating was structured by cows," the
answer would be "Of course not. I was trying to make my colleague
laugh."


So what's the solution? Long-term, I'd really hope we could get away from being able to sway a jury or the media with a couple of juicy quotes taken out of context. Our unhealthy obsession with 'gaffes' in the presidential campaign is the same problem. As an audience we'd much rather focus on simple but superficial single sentences and find easy scapegoats, than actually spend time trying to understand the deeper issues.

Until then, I think the first comment is right. Be very careful about using humor in an email, it might come back to haunt you.

How to extract and categorize email addresses

Headfiling

Photo by SlightlyLessRandom

It’s possible to extract some interesting information from someone’s email address, such as which organization they represent, what type of organization it is, and whether it’s a work or personal account. This is very useful if you want to do automatic contact location in a Spoke-like way, eg who do I know at company X, and for the statistical analysis of large email stores in my own Mailana.

The key is the 80/20 rule. 80% of emails come from 20% of organizations. That makes it feasible to create a white-list that covers the most common US companies, colleges and ISPs, noting their type and giving the organization’s full name. With Liz’s help, I’ve put together an initial list of 2200. Here’s a demonstration of it in practice, or you can enter some addresses into the box below:

You can also download the source and list at http://mailana.com/labs/addresscategorizer.zip

It’s definitely not infallible, but it’s good enough to be useful for my purposes. The more organizations get added, the more accurate it gets, so to add your own edit the domaininformation.txt file. There’s a line for each organization, in this format:

organization domain|display name|type

Let me know if you do generate a larger list you’re willing to share, and I’ll update the example. Thanks to Christine DeMello for compiling her directory of colleges.

How to escape from a submarine

Submarine

Photo by Fuzzymucka

Bob Sutton is my favorite business writer, partly for his most recent The No Asshole Rule, but mostly for his older Hard Facts, Dangerous Half-Truths And Total Nonsense on evidence-based management. His argument is that we can be more successful by relying on real evidence to make our decisions. This sounds obvious, but he's great at pointing out how we're actually hard-wired to use all sorts of other criteria instead. As George Orwell said, "To see what is in front of your nose requires a constant struggle".

He recently reminded me of a great example: the history of submarine escape technology. The first people to escape from a sunken submarine let the water flood the vessel until the pressure equalized, opened the hatch and popped to the surface, exhaling as they went. The knowledge that this was feasible was never taught to subsequent submariners, and instead elaborate and hard-to-use pieces of escape technology were developed over decades. Eventually a British study of actual escapes in World War II showed that unassisted ascents had saved as many lives as those with equipment, and the technique was finally taught in basic training.

As technologists, we know that when you have a hammer, every problem looks like a nail. On a larger scale, when we have new technology and features, every problem looks like it needs it. For enterprise software, effective user adoption is considered the most critical factor by 70% of decision makers. Organization change and process alignment are next with 16% and 13%, while the actual functionality is down at 1%.

This backs up my personal experience that most new technology introduced into businesses fails because nobody wants to use it. The key to success is building something that people want to adopt. That's where some of the lessons from the consumer world are so useful, online services live or die by their usability. Keep your features minimal and do actual usability testing on your product, and you'll be ahead of 90% of business vendors! Don't keep building devices that will just sit on the shelf.

An online guide to hiking and biking trails near Los Angeles

Mishemokwasky

Photo by KnaPix

I was out doing trail work at the annual COSCA event on Saturday, and met up with another regular, Steve Clark. He runs a website that's a fantastic resource for anyone who likes to get out in the mountains west of LA, venturacountytrails.org. I've put up my own guides to a few of the local trails and campgrounds, but Steve's assembled a comprehensive set of maps and descriptions covering most routes in the area.

He's got GPS-based topo maps for all the places he covers, together with elevation charts and descriptions. I still always recommend having a good traditional map of any area you're exploring, but he's done a fantastic job of writing guides that make it very hard to get lost! Here's links to his coverage of some of my favorite areas:

Mount Pinos
Circle X
Rocky Peak
Wildwood
Cheeseboro

Great job Steve, you're really helping people discover the wonderful wilderness we've got on our doorstep.

How to access all that lovely Exchange data

Drillbit

Photo by Photobunny

Any company's Exchange server holds a wealth of information that could be used to build some very compelling tools, if only it was easily accessible. I've made it my mission to crack that silo and build some useful services, which has meant researching every way I can find of drilling in. Here's the approaches I've implemented or looked at:

Local MAPI

Microsoft has reused the acronym for Messaging API in multiple different projects. This version refers to the interface for accessing mail data held on the same machine. In use since 1992(!), it's supported by all configurations of Exchange, but it's deprecated and requires an optional component in 2007.

It offers fast access to all tasks, contacts, emails and calendars for every user. The biggest obstacle is that it requires server software installation, and most Exchange admins are deathly afraid of touching a working configuration. There's also other same-computer access APIs like ExOleDB that work very similarly. Mailana implements a server-side MAPI downloader as one of its entry points.

Exchange Web Services

EWS is the officially recommended replacement to local MAPI, but unfortunately it's only supported by Exchange 2007. Like MAPI, you can see all users' information as long as you have correctly setup the admin access account. It's a network interface, so there's no scary installation required. I've not implemented this yet.

MAPI/RPC

The other protocol named MAPI, this one is the network interface that Outlook uses to communicate with the Exchange server. It's not officially supported as an API, but third-parties like OpenMAPI have reverse-engineered it. The great promise of this approach is that you could implement a proxy server that sits in between Exchange and its Outlook clients, picking out all the information you want as it flows across the network with almost no change to the existing infrastructure. The downside is that you only see information as its sent back and forth, which means no access to historical data. You can see all the types of information supported by Outlook. This isn't implemented in Mailana, but it's definitely very attractive and I hope to work on it soon.

IMAP

IMAP is the standard internet protocal for sending mail between servers and clients. Many corporate networks have IMAP journaling enabled for Exchange to allow back-up services to pull down mail items for their archives. It gives you access all users' emails, but you can't see other items like contacts or meetings. This requires the admin to setup journaling on the server, but that's pretty low-impact. I've got IMAP support in Mailana, which as a bonus also lets me import Gmail accounts.

Outlook Add-in

From a client-side plugin to Outlook, all of a user's information is readable through the Outlook Object Model. You only have access to information that's been kept on the user's local machine. The really nasty bit is that this approach requires installation on every client machine connected to the server, and you have to jump through some hoops on older Outlook versions to avoid annoying security warnings. I've got this implemented in Mailana.

ActiveSync

Like MAPI/RPC, ActiveSync is designed to allow the transfer of tasks, emails and contacts between a device and the server. This means you only have access to a single user's information. It doesn't require any installation, and is enabled and supported on most servers. I've not implemented this.

How to implement video capture on the mac

Dogcam

Photo by pt

If you want to capture the data from an iSight (or any other video camera) on OS X, figuring out where to start is tough. Video input and output are both controlled by QuickTime, an amazingly successful framework, but as a long-lived interface to rapidly changing hardware it has accumulated an inpenetrable thicket of APIs. That means there's no obvious StartVideoCapture() function, instead you have to use some odd legacy calls.

Here's the official SGDataProcSample code demonstrating video capture to a data buffer. The actual source you want is in MiniMung.c, appropriately named after the joke acronym Mung Until No Good. Don't try to make too much sense of the actual functions, just accept that these are the magical incantations you need to mutter to get it working.

If you want an example of uploading the captured data to an OpenGL texture, you can download the source code to my Live Feed video plugin for Motion and look in LiveFeed.mm for the code. I have a separate thread running capturing the video and downloading it to a buffer, while the rendering thread constantly uploads a texture from it. There's a risk of tearing, but keeps the logic simple and doesn't require any blocking.

An engineer’s guide to demos

Butterflybullet

Photo by RazZiel

I met up with some friends last night and did an off-the-cuff show and tell. I left feeling I'd failed to get across what's so interesting about Mailana, reminding me that in my natural state I give terrible demos. Since they're a crucial part of selling an idea, I've had to work hard to fix that. I know I share that affliction with almost every engineer I know, so here's some tips that have helped me.

Accept that it's important

In most engineering situations, if I know something interesting and you don't, you're expected to make an effort to learn it. That's completely reversed when you're trying to sell your idea. You may be certain that it's the best thing since sliced bread, but you're the one who has to make the effort to communicate that to investors, customers or journalists. They have massive numbers of people trying to persuade them to take action, so they can only spend a small amount of time and thought on each proposal. That means you have to spend a lot of time and effort crafting your demo.

Rehearse relentlessly

Stop coding at least a couple of days before, turn on your web cam, start recording and practice what you're going to say. Watch it back every time, and then do it again. My rule of thumb is that I need to do it at least 25 times before I start sounding natural, ironically. This also comes in handy if you want to produce a web video of your presentation, the one I'm still proudest of is my pitch for SearchMash from a few years back. It sounded crazy to me at first to spend so much time on it, f you don't believe me, just read about the days of prep Steve Jobs puts in for his keynotes.

Show, don't tell

Jason Calcanis's demo guide is spot on. People don't want to hear about your life story, just show them your product within the first 30 seconds, preferably doing something awesome. My Achilles heel is going into all of the really interesting technical details of how it works. That's like having a car commercial with the hood popped just showing them the engine. They want to see what it does for them, not how it does it.

And if you want to know how this all works out in practice, come along to Defrag to see me in action!