Good Things

If you only started reading my blog in the last year or so, you might get the impression that I’m pretty down on the tech industry. In that time, most of my popular posts have been complaints or criticisms on one topic or another: lousy tech journalism, the lack of reason in technical discussions on the Internet, issues with living and working in San Francisco, and most recently, questioning the politics of the iPad.

While friends probably wouldn’t describe my personality as “sunny” or “effervescent”, I’m actually not as doom-and-gloom as one might think given my posts here. I attribute this somewhat to the Yelp effect: you’re most inclined to write a few impassioned paragraphs when you’re pissed off. Everyone loves a good rant, after all, so those critical, argumentative posts tend to get linked to and passed around more than my usual output.

Though it’s nice to have a readership, I worry about being known as a curmudgeon. So, over the next two months, I’m only going to be writing about good techie things. Things I like. Things I’m excited about. Because honestly, there’s so much more in this industry that I’m excited about than not, and I don’t spend enough time sharing those things with an audience larger than my friends and coworkers. It’s time to fix that.

This series of positive posts will start this week, when I talk about some good things I came across while looking outside of the Apple computing landscape.

C’mon, get happy, nerds.

—Feb 08, 2010

On the iPad

For years, me and thousands of other techies have been wondering what comes after the Personal Computer as we’ve known it. Yesterday, in Apple’s iPad, we caught a glimpse. If I had to pick one predominant emotion in reaction, it would be “disturbed”.

The iPad is an attractive, thoughtfully designed, deeply cynical thing. It is a digital consumption machine. As Tim Bray and Peter Kirn have pointed out, it’s a device that does little to enable creativity. As just one component of several in a person’s digital life, perhaps that’s acceptable. It seems clear, though, that the ambitions for the iPad are far greater than being a full-color Kindle.

The tragedy of the iPad is that it truly seems to offer a better model of computing for many people – perhaps the majority of people. Gone are the confusing concepts and metaphors of the last thirty years of computing. Gone is the ability to endlessly tweak and twiddle towards no particular gain. The iPad is simple, straightforward, maintenance-free; everything that’s been proven with the success of the iPhone, but more so.

From iPhone to iPad

The iPhone can, to some extent, be forgiven its closed nature. The mobile industry has not historically been comfortable with openness, and Apple didn’t rock that boat when it released the iPhone. The iPhone was no more or less open than devices that preceded it, devices like those from Danger that required jumping similar bureaucratic hurdles to develop for.

That the iPad is a closed system is harder to forgive. One of the foremost complaints about the iPhone has been Apple’s iron fist when it comes to applications and the development direction of the platform. The iPad demonstrates that if Apple is listening to these complaints, they simply don’t care. This is why I say that the iPad is a cynical thing: Apple can’t – or won’t – conceive of a future for personal computing that is both elegant and open, usable and free.

The iPad was pitched by Steve Jobs yesterday as a response to netbooks. It is not a mobile device, per se. Rather, the iPad is competing with full-fledged (if small and ugly) computers capable of running arbitrary programs and operating systems. Play all the category games you want, but the iPad is a personal computer. Apple has decided that openness is not a quality that’s necessary in a personal computer. That’s disturbing.

Tinkerer’s Sunset

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

Perhaps the iPad signals an end to the “hacker era” of digital history. Now that consumers and traditional media understand the digital world, maybe there’s proportionally less need for freewheeling technological experimentation and platforms that allow for the same. Maybe the hypothetical mom doesn’t need a real computer. As long as real computers stick around for people who do need them, maybe there’s no harm in that.

Wherever we stand in digital history, the iPad leaves me with the feeling that Apple’s interests and values going forward are deeply divergent from my own. There’s nothing wrong with that; people make consumer decisions every day based on their values. If I don’t like the product that the iPad turns out to be once released, I’m free to simply not buy it. These things have a way of evolving, and I won’t preclude the possibility that Apple eventually addresses concerns about the openness of the device.

For now, though, I remain disturbed. The future of personal computing that the iPad shows us is both seductive and dystopian. It’s not a future I want to bring into my home.

Postscript, January 29

Having had a day to think this post over and receive some very thoughtful feedback, there are several things I’d like to add while it’s still relevant.

First off, my remark about not learning to program if I had an iPad wasn’t intended to be a blanket statement about any child not learning to program on the device. There are plenty of kids out there who are way smarter and more motivated than I was in my formative years, and I’m sure they’ll tinker no matter what obstacles are put in their way. The iPad could actually be a great platform for teaching kids to program if Apple decides to remove the artificial restrictions on running interpreted code on the iPad/iPhone OS.

Which brings me to the point I was really trying to make: Apple’s decision to make the iPad a closed device is an artificial one. It’s been several years since I worked in security, but as best I understand, there’s no practical technical reason why the iPad must be its particular flavor of closed in order to be usable and reliable. It’s still possible to enforce sandboxing and resource limitations in an open system; it simply requires a different approach. As Christian Neukirchen said on Twitter:

“There is no reason why Apple couldn’t allow enabling unapproved apps with a flag somewhere… except for their greed and will to power.”

Or, as Adam Pash of Lifehacker put it yesterday:

“To say that ‘either a device is user friendly or it’s open’ is a false dichotomy.”

Honestly, as simple a step as Apple making iPhone/iPad SDK access free – along with its ability to install apps on the Apple devices you paid for – would be an acceptable first step towards openness. Let’s do some clumsy math on this point. According to Wikipedia, there are currently around 140,000 apps in the App Store. Let’s round up and say that each app is made by a different developer. So, at $99 per year per developer, that’s $13,860,000 per year that Apple is making selling SDK access. For a company that just posted a net quarterly profit of $3.38 billion, I think it’s safe to call the SDK money a drop in the bucket.

Further, the argument that Apple has invested in the “Open Web” as an alternative free platform for their devices simply doesn’t ring true to me. Talk to any non-geek iPhone user and you’ll quickly realize that they have no idea that web apps can, for example, be saved to the home screen like regular apps. The general attitude, once they get used to the phone, is that if there isn’t an app for it, it’s not worth doing on the device. And why wouldn’t they have this impression? Apple’s ad campaign isn’t “there’s an app for that, and also the entire open web”. For now, the web is an afterthought on these devices.

I’ll close with this: if I didn’t think the iPad was an important device, I wouldn’t be bothering to criticize its politics. Like Steven Frank, I think this a new world, a new era, and I’m not interested in hanging on to the past. Like Joe Hewitt, I’m excited to develop for the iPad, and to use what others develop for it as well.

As I said at the top of this post, I’ve been waiting for years for what comes after the PC, and I truly believe that Apple has shown it to us. That’s why it matters so crucially that this next leg of the computer revolution gets off on the right path, one that embraces openness rather than abhors it. We have the technology and the incentive to build the future of computing in an open way. The only reason not to is greed, laziness, and hubris.

—Jan 28, 2010

Upcoming Talks, Early 2010

An update on my public speaking in the new year.

FOWA Miami

In February I’ll be in Miami for the Future of Web Apps conference. The sessions are all quite short and packed into one intense single-track day. I’ve basically got twenty minutes to convince the audience that a functional programming language (any functional programming language!) is going to be beneficial in their work. It should be fun.

Philly Emerging Tech

In April I’ll be in Philadelphia for Emerging Technologies for the Enterprise, a two-day conference that actually goes a bit outside its stated domain. The speaker lineup is nicely diverse, bringing together folks from all over the industry to share their experience about technology at scale. Some of the content is certainly a bit “enterprisey”, but for East Coast folks with an interest in scaling, JVM languages, web app development, and more, I think it’s worth shelling out for.

I’m going to be talking about building distributed systems in Scala. I’ve already given talks about the more general benefits of working in Scala, both for developers in general and web app developers in particular. This talk is going to get into more specific case study material drawn from the past six months or so of infrastructure work at Twitter. At this point, we’ve got some best practices, some worst practices, some design patterns, some open source components, a whole bunch of opinions to share.

Hope to see you at one (or both!) of the above events. Don’t be shy.

—Jan 12, 2010

Sold, For Just Me

A while back, I noticed friends on an online community repeatedly asking “is some site down for everyone, or just me?” This odd scenario, in which users of the same global Internet have an inconsistent view of the network, is often caused by local ISPs having outdated DNS caches. Being able to check with a third-party often lead to the conclusion that, no, some major site was not down, your Internet connection just sucked.

One morning, I was inspired enough by seeing this plaintive inquiry for the umpteenth time to throw together the absolute bare minimum web service to check to see if a given site was up or down. I got it working, picked out a cheekily literal domain name, tweeted about it, and left it at that. Over the course of the following weeks, the site was linked to from a number of popular blogs and link aggregators. Before long, it was climbing the Alexa rankings.

I had numerous feature requests after the site launched, but turning it into a robust, multi-homed uptime checker was never my goal. All I’ve ever done with the site is:

1. Ported it from a simple Ruby implementation to App Engine.
2. Put some ads on it; first Google AdWords, then later individual campaigns that I negotiated by email. I made about USD $300/month from the site, on average.
3. Wired up a Twitter account that would tweet out sites that were frequently seen by the service as “down” within a short time period. (This functionality has been inactive since November, 2008.)

Given the site’s popularity, it’s sort of silly to let it lie so fallow. I have no inclination towards improving the site, and it deserves an owner with an active interest in its improvement.

Over the weekend, I sold Downfor to Bweeb, Inc.. One of their related ventures, Site5 Web Hosting, have been the primary advertiser on Downfor for the past few months, and they’ve been pleasant to work with. I don’t know quite what their plans for the site are. I also don’t have their permission to disclose the amount of the sale, but suffice to say that it was proportional to the amount of time and effort I’ve put into it (that is, not much).

And that, friends, is the story of an odd little single-purpose website with a silly domain name that, for some reason, thousands of people keep coming back to every day.

PS The source for the site is open once again.

—Jan 12, 2010

Don’t Be A Hero

My last work-related post, regarding the difference between criticism and negativity in the workplace, was well-received. I don’t plan on this turning into Yet Another Business Advice Blog, but I figured I’d share one of the scant few other things I’ve figured out so far in my time working in tech.

The Hero

Every team I’ve ever worked on has had a hero. You’ve probably worked with one too: the guy or gal eager and willing to pull all-nighters, work weekends, and take over on-call duty when nobody else wants to.

Of course, everyone appreciates the hero. Her efforts are more tangible than the rest of the team’s. Everyone else is writing code, sure, but the hero is writing code at the office at four in the morning. That’s real, real in a way that a bunch of commits from the rest of the team aren’t, real in a way that’s particularly visible to managers. The hero is celebrated. The hero is a role model.

Here’s the thing: the hero is the most damaging person on a team, particularly on a team that’s supposed to be writing high-availability or otherwise mission-critical software.

Why The Hero Undermines Everyone Else

If you’ve built a system that’s supposed to be reliable, you shouldn’t be up fixing it at four in the morning. You shouldn’t be getting paged at all hours. Sure, you might need to do some occasional planned after-hours maintenance, or some very occasional unplanned-but-process-driven disaster recovery, but you shouldn’t need a hero.

Heroes are damaging to a team because they become a crutch. As soon as you have someone who’s always willing to work at all hours, the motivation from the rest of the team to produce reliable, trouble-free software drops. The hero is a human patch. Sure, you might sit around talking about how reliability is a priority, but in the back of your mind you know that the hero will be there to fix what doesn’t work.

Relying on the hero to make up for poor software reliability might be a reasonably cost-effective (if cynical) strategy if it weren’t for heroism being utterly unsustainable. Nobody can pull heroic hours for long. Heroes get sick. They get burnt out. Eventually, the hero resents the rest of the team for not pulling their weight, and rightly so: if your team is relying on a hero, they’re not doing their jobs.

Why You Shouldn’t Be A Hero

I’m willing to bet that everyone reading this has probably been the hero at one time or another. If you love what you do, it’s inevitable that you’ll want to pull late hours and help out. In moderation, there’s nothing wrong with that.

If you’re carrying the rest of your team through heroism, though, it’s time for a change. Ultimately, by playing the hero, you’re shortchanging yourself, your coworkers, and your customers:

• By playing the hero, you shortchange yourself by maintaining an unhealthy work-life balance. You may love your work, but you can’t do nothing but work and expect to stay happy and healthy. What happens when your job starts being less fulfilling? You’ve put all your eggs in one basket.
• By playing the hero, you shortchange your coworkers by enabling mediocrity. When a team can rely on a hero, they don’t need to grow and learn collectively. They don’t need to get better. They can coast along, which serves no one in the end.
• By playing the hero, you shortchange your customers by allowing a lower-quality product to ship. Heroism is only valuable when things are going wrong, and if things are going wrong, your customers are feeling the pain.

If the above is happening in your work, it’s time to make a change. But what to do?

What To Do About Heroes

By all means, love what you do. Work hard. Get involved. But recognize when your level of involvement is actually doing harm. If you’re playing the hero, or if you have a hero on your team, it’s probably time for a serious talk with your coworkers and manager.

Talk about numbers; people can agree more readily on numbers because they’re aren’t (or shouldn’t be) subjective. What are your metrics for reliability and how can you improve them? Get everyone to agree on operational requirements, then iterate towards a stable, trouble-free system that meets those requirements. Make everyone on the team a stakeholder in the system’s reliability. Artificial divisions between “reliability work” and “feature work” need to come down; it’s all connected.

Managers: stop rewarding people for pulling long hours. Don’t punish them, of course, but rephrase the conversation within your company. If someone is working at four in the morning, something is deeply wrong. Figure out what’s broken and delegate the work out evenly across your team such that it doesn’t happen again. Don’t pat your hero on the back for “pulling another late-nighter”. You’re clearly managing someone highly motivated, but you need to shape that motivation into something more constructive. That energy needs to go into design, architecture, planning, and testing, not late night patch sessions.

If you make the above changes, you’ll probably find that you, your coworkers, and your customers are happier. If you have a conversation like the above and nothing changes, you’ve got some hard choices to make about where you work, who you work with, and how you’re approaching your job.

Good luck, heroes.

—Jan 09, 2010