At Risk: An Online Service is Sometimes Neither Online Nor Serviceable

404 LOLCAT NOT FOUND by GirlieMac on Flickr, CC BY 2.0The down side of relying upon all these online services is that, well, they’re online services [1]. The sad truth of the internet is that these things disappear all the time, often with little or no notice. Some notable examples:

These are just a few of the innumerable internet services which have either seen their final sunset or been very close to it. Each of these companies had users who relied upon their services, users who were left high and dry when the last staff member leaves the building. And in the end this just didn’t matter. The lights went out and the service disappeared.

This is bad enough for your Average Joe User, but what if your own company relies upon someone else’s API? What if you were one of the companies whose offering depended upon the Google Maps API for Flash only to have it end-of-lifed? Or, say, the Amazon cloud is suddenly unreachable? How would your company fare?

In this interconnected world of ours we are all stronger through the cooperation afforded by public APIs and online services of this kind, however that does not mean we’re allowed to be blind to the risks which we take by doing so. As CTOs, architects, managers and programmers we all need to consider these scenarios and prepare for them in order to minimize the impact on our users. Downtime happens to everyone at some point and is excusable but failure to prepare is not. It’s just stupid.

500 LOLCAT INTERNAL SERVER ERROR by GirlieMac on Flickr, CC BY 2.0When designing your project or service, try to build in some failsafes to prevent a crisis in case an external API or online service becomes unavailable. Fail gracefully, don’t flame out. It could even be as simple as disabling certain pages (or even the entire service, if necessary) when an API can’t be reached. This is a far superior user experience to your users seeing a 404 or 500 status page…

When researching this article I came across the post API Half-lives by Gabriel Weinberg of DuckDuckGo. He has a great list of questions for a team to ask itself when considering APIs and services to use in their projects. Go give it a look then sit down with your team and consider whether you’ve put yourselves at risk and, if so, what you can do about it.

[1] I have taken precautions for each of these services to be sure I do not lose important data. All information is sync’d to multiple locations and, in the case of the photos, backed up in multiple locations as well. [back to reading!]
[2] ArchiveTeam’s raison d’être is swooping in to save at risk data. They do great work and could use your help preserving our fragile digital heritage. Check out their wiki or hop on their IRC channel and say howdy. They’re all rogues with hearts of gold who’ll welcome you with open arms. [back to reading!]

Online Services I Find Worth Paying For

While I appreciate getting something for free [1] as much as the next person, I’m also very willing to shell out cash for online services which I find both useful and valuable. Here are the ones for which I do (or am willing to) plunk down a few shekels on a monthly or yearly basis:

  • Dropbox: I adore Dropbox. This service has saved my ass more times than I care to remember. While the standard service is free for 2GB I pay to upgrade my account to 50GB. While it’s nice to get all that extra space I’ve found that Dropbox has become such an integral part of my workflow that I would pay anyway just to help guarantee it’s around for a good, long time.
  • Evernote: I spend a lot of time online and most of that is spent reading. Back in the day I would bookmarks articles I enjoyed. Back in the day I would also lose the bookmark file any time I switched computers. I also would never look at the site again. I’d remember, “Oh, I read something about $foo once…” but be unable to locate it in the morass of links. Enter Evernote. With one click of the browser plugin any site, any image, any PDF is slurped into my Evernote account, metatagged, indexed and sync’d to all of my devices. Data is no longer lost and I’m a happy camper who’s able to search and locate whatever I need. The basic service is free and more than adequate for most people but, yet again, this is a service which important to my day to day work and therefore worth it to me to support financially.
  • Netflix: Really, does this one even need an explanation? Probably not but it’ll get one anyway. I haven’t had cable for about twelve years now. I’ve been without a TV for two or three years. My entertainment needs are met via the internet, primarily by Netflix (of which I’ve been a subscriber since 1999). Netflix allows me to indulge my desire for cheesy science fiction programming without having to spend money on DVDs which are just going to take up space in my apartment.
  • Github: Github has rapidly established itself as the go-to distributed version control hub on the internet, particularly among open source advocates. Any repository which is open sourced may be hosted for free and includes a project tracker, issue tracker, etc. It’s a brilliant piece of work for which the Githubbers should receive a great many gold stars. I, however, don’t have any open sourced repositories there quite yet. Instead, I pay a small amount every month for the peace of mind which comes from maintaining important files in my own private version-controlled repositories.
  • Remember The Milk: The most important tip I took away from GTD was, “write it down in a trusted location and get it off your mind so you can focus.” Remember The Milk (aka ‘RTM’) is that trusted location for me. Any time I think of something I want to or should do I immediately grab one of my devices, type in a quick to-do item and sync it up. Since I started doing this over a year ago my productivity and organization has increased greatly while my stress level has mostly dropped. When something doesn’t get done it’s invariably because I failed to use the system correctly (like not looking at it; hrm). For a while RTM syncing from iPhone and iPad required paying for a Pro account (I do not believe this is the case now), which is necessary for me to capture items on the fly. However even if that weren’t the case I still would pay for this service simply for all the good things it has done for my quality of life.
  • Flickr: I used to host my own photo albums. That got to be a drag. Not only that, there were new online services which were doing the same thing but better. At the time I joined Flickr was the hot thing and had yet to be acquired by Yahoo!. The user interface was clean and useful, the features were exactly what I needed. Subscribing for a Pro account got me the organizational features I required. Now my account hosts 1,646 of my photos and am well content to stay with them for the next 1,646 and beyond.
  • Spool: This one’s a newcomer to the online service game, so much so that it’s still in private invitation beta. It’s also the only one on the list which currently does not have a fee option for its service and is entirely free. That said, this service has very rapidly become a vital part of my online workflow. While Instapaper enables users to save articles for offline reading, Spool enables its users to save both articles and videos. These are then synced to my iPad and iPhone. I read/watch them on the Muni, in the pub, while waiting in line… The best part is that I no longer have a browser window crowded with “Aspirational Tabs” for things I’d like to get to some day. Click, add to my Spool, close the tab and get around to reading it later. If Spool adds ‘Send to Evernote’ as an option (‘Send to Twitter’ and ‘Send to Google+’ would be nice as well) then I’m a user for life and will pay for the privilege. As they’re still in beta I have great hopes for these features.
[1] Hellooooo, Google Mail, Google Docs, Google Voice, Skype, Twitter… [back to reading!]

It’s Called Marketing for a Reason

Let’s do a little experiment. The next time you’re in a room full of techies, say something along the lines of, “Hey, how about that marketing department, eh?” Now count the number of people in the room who roll their eyes, snort derisively or start otherwise grumbling about how marketing is evil and clueless and a few other unflattering adjectives.

I used to be in that camp. I used to believe that marketing was nothing but advertising and manipulation, getting gullible people to buy stuff they neither want nor need. Then I worked at an online marketing company for six years and took the time learn what this wacky “Marketing” thing is all about.

While advertising is a large (and the most public) facet of marketing I believe it’s one of the least important. Which isn’t to say it’s not important, just that I personally rank it near the bottom of marketing operations.

A hint to the most important marketing operation is right there in the name: Marketing. Before a marketer can do anything else he needs to determine his market. I offer that this is the single most important operation not only in the marketing department but also in the entire organization. Why?

Your market is composed of your users. It’s the people with whom the sales team closes deals, for whom you put code to editor, for whom the customer service reps pick up the phone. These are, as far as your organization is concerned, The Most Interesting People in the World. Before it lifts a finger it must know not only who these people are but also what they need and how to communicate with them.

Do you know your market? Have you ever thought to ask? If not then I strongly suggest the next thing you do after you read this post is schedule a lunch or coffee outing with someone from your Marketing team to do a little learnin’. An understanding of the people for whom you’re writing software will lead to better decisions about design and features, more successful services, better roll-outs… In short, it will make for a more successful project. Not knowing your market means you’re not in sync with the rest of the organization. You’ll waste time adding features which no one will use. You’ll design interfaces which will confuse and frustrate. Sales won’t sell, customer service will be overwhelmed with requests and you’ll have to go back and fix it. No one wants that.

It’s possible that you may already have a pretty decent idea of who the users of your software are and for that I heartily applaud you. However I still recommend you take an hour to have that lunch with someone from Marketing to discuss it. As much as you know you can always learn more. Getting a different perspective on your market can only do good for you, your product and your organization. Furthermore you’ll gain a deeper understanding of the operation of the organization and where you fit in it. And let’s not forget that there are two people sitting at that lunch table. Forging a relationship with Marketing helps expand the horizons of both teams and enables the entire organization to be more successful.

Or, to put it into Marketing Speak, embracing a best practice of increasing interdepartmental face-time to leverage a holistic and synergistic approach to market knowledge can increase the core competency of the enterprise for greater return on investment, mindshare and thought leadership.

OK, so maybe sometimes marketing can be a little bit evil.

Rethinking Education Requirements in Tech Job Postings

A few days ago I posted this tweet:

My tweet was prompted by seeing a constant stream of job postings containing lines such as the following (taken from actual postings on craigslist:

  • BSCS or equivalent industry experience
  • Hold a BS or higher degree (or equivalent) in Computer Science/Engineering or related field
  • BS degree in Computer Science, Engineering or equivalent
  • Degree in computer science or similar
  • Four-year degree or Masters in an analytical or technical field (e.g. Economics, Computer Science, Mathematics, Statistics, or Finance)

Between my experiences as a tech manager and participating in open source communities I’ve met a lot of incredibly talented programmers. A few have CS degrees; most have degrees which have nothing whatsoever to do with computer science; some have no college degree to their name at all. Of the most talented and skilled programmers I know the majority are in this last group: they hold no degree and yet *gasp* they are absolutely brilliant. Unfortunately I’ve seen some very good people be discounted (and typically therefore not hired) because they lacked what some on the hiring committees deemed “a proper education.” This inevitably meant that the candidate did not have a degree in computer science or—even more unforgivable—did not have a degree at all.

Since I do know so many excellent and self-educated programmers I found myself becoming exceedingly annoyed on their behalf at these requirements. When the annoyance reached a head I blew off steam by way of the tweet, crying “elitism”.[1]

In the time since the tweet was posted I’ve simmered down a bit and started to think things through a bit more clearly. I came up with a question:

What, really, is the purpose of an education requirement for a tech job posting?

Photo by Flickr user mag3737, Creative Commons BY-NC-SAFrom what I can tell, an education requirement is shorthand for a minimum level of knowledge. “You must be this high to ride this ride.” The expectation is that if a programmer has a degree in computer science she knows data structures and recursion and how to solve the Tower of Hanoi in Java. However I see this as redundant data, at best. The same information is going to be readily apparent from skimming the applicant’s resume and code sample. Seeing a degree listed on an applicant’s resume does not excuse me, as a hiring manager, from reading the remainder of the document.

In addition there is an entire raft of vital skills which aren’t taught in most computer science degree programs. Using source control. Writing tests. Working on a team.[2] I’m sorry to say, but if I see a resume from a new compsci grad I assume he does not know how to do these things. Unless he has experience coding outside of the classroom I’m likely to set his resume aside in preference to the applicant with no degree but with open source experience, who has worked on a team and contributed code which has seen the light of day. I don’t care much for towers—Hanoi, ivory or otherwise; I care about results and that’s not something you can determine from the one line in a resume stating, “Bachelors of Science, Computer Science, Wossamotta University (2003).” It’s all those other lines which matter.

There are definitely times when having a degree requirement makes sense. I don’t mean to imply that they should be entirely banished from tech job postings. However I do believe that we, as an industry, need to put as much thought and care into our job postings as our code design. We would never stand for bullshit requirements for our code. We should not stand for them in our job postings either.

[1]: I admit “bigotry” was a close second but wasn’t chosen due to its intensely negative baggage. “Elitism” is only slightly negative in comparison.[Back to reading!]

[2]: Andy Lester has a great presentation discussing what schools are missing in their CS curricula. [Back to reading!]

Email Overload? Reclaim Your Inbox, Don’t Banish It

I recently read two articles while riding the bus[1]. The first one was in Forbes Magazine. Thierry Breton, the CEO of Atos Global, has decreed that since he “believes that only 20 out of every 200 emails received by his staff every day turn out to be important,” within eighteen months the use of email will be eradicated company wide, replacing it with social media, phone calls and in person meetings.

Contrast this with the second article I read, Don’t blame the information for your bad habits, an interview with Clay Johnson by Mac Slocum in the O’Reilly Radar. Clay states that “[w]e don’t need to manage the information. We need to manage the consumption of it.” According to his new book The Information Diet, just as a binge eater cannot blame the food he eats a person suffering from the poorly-named “Information Overload” cannot blame the information.

To some extent I agree with both of these men. Excessive information (including email) is a danger to productivity. It diverts attention, derails trains of thought and increases stress. However, considering Mr. Breton’s concern over the reported high level of distraction caused by reading unnecessary email messages, I’m rather surprised at the alternatives being proposed. While unnecessary emails are distracting, I find it difficult to believe they are more so than social networking, phone calls or meetings (which we all know I believe can be improved). These routes of communication all tend to be highly impromptu and interuptive. Rather than improve the signal to noise ratio of the emails sent within Atos Global (or the email handling of the employees), he instead blames the email itself and chooses to cut off the service. I dunno… I just feel this may be one of those “Farewell bathwater! Baby? What baby?” sort of situations.

I agree with Clay Johnson: email is not to blame here. Rather than taking the somewhat drastic move of banning email, perhaps Atos Global would first consider applying these suggestions:

  1. Eliminate or filter most automated messages. We all get them. Output reports from cron, record update notifications from the CRM software, escalation warnings for issues on projects we haven’t worked on for months. These emails either need to stop or should be filtered out of inboxes.
  2. Refactor internal aliases and/or mailing lists. I mean refactor in its most technical sense here. Like code, so often the contents of these things evolve over the years. Cruft accumulates and is never cleaned up, leading to a lot of unnecessary emails. Each internal alias and mailing list membership should be examined. What is the purpose of the list? Remove any recipient who does not contribute to that purpose. Don’t forget to run some tests to be sure you haven’t broken anything (removed someone you shouldn’t have, for example).
  3. Suggest new internal email handling policies. Request that each staff member change his or her email client settings, downloading email only twice a day and disabling any desktop/taskbar/etc. notifications. This is a tough one as people get very attached to their personal workflows, but these relatively small changes can lead to a lot more undisturbed contiguous moments in everyone’s day. You can always find some technology which enforces it but, really, that’s a bit too Big Brother-y for my tastes. My preference would be some form of firm but gentle social engineering, starting with telling everyone precisely why they are being asked to make the changes requested. The people with whom you work are incredibly intelligent and they’re adults. Treat them that way and most of them will see the good sense in the suggested changes.
  4. Selectively change communication media. Thierry Breton is correct: email is not always the right tool for the job. What sort of information is being exchanged via email at your organization? Do an email survey and try to categorize the communication that’s happening. Would any categories be better suited to a different medium? Could those long emails explaining the database architecture perhaps be written into the wiki instead? That “anyone for lunch?” message to the team would undoubtedly be better on the IRC channel, wouldn’t it? Perhaps the company could roll out Google Docs rather than emailing around a Word file for document collaboration.

You’d be surprised just how far you can get with these changes. I keep my own inbox at or hovering just above zero thanks to some of these suggestions. I got 99 problems but an inbox ain’t one.

If anyone has tried any of them at their company or on their project I’d love to hear about it in the comments. I’d be particularly interested if you have any metrics you could share.

[1] Using Spool, a new online app which is changing my online reading habits for the better. Think Instapaper but better (for instance: offline viewing of videos). No, they didn’t ask me to say this. I honestly do love and use the service. 🙂 [Back to Reading!]