A Thought on Business Size and Happiness

We take for granted that startups tend to be small, productive, and fun, and that behemoth companies are usually bureaucratic, dreary, and slow to produce. What's frequently left unexplored is the growth stage between these polar opposites. The small-to-mid-sized company transition process is something I've been thinking about a lot lately.

In some sense, the middle stage between startup and established business is the hardest in an organization's growth. Startups may be just barely scraping by, but they can have fun doing it. Big businesses may not have fun, but they have security and stability and process and usually enough money to sort most anything out. Mid-sized businesses, though, seemingly have the potential to be both animals: fun and stable, profitable and agile, and so forth. But clearly, given the culture of most large businesses that were once mid-sized businesses, having your cake and eating it too is a clearance shelf management book pipe dream.

Consensus seems to be that any business larger than about five people won't be a "fun" place to work in the purest sense. That doesn't mean it won't be successful, profitable, exciting, etc. But the shared sense of goals, culture, aesthetics, and velocity that makes an infant business exciting seems to cap out at around five bodies. Bigger than that and you'll never again be without the sort of communication problems that eat away at employee happiness and overall productivity.

This is clearly an unfinished thought. What I'd like to figure out is how to achieve that balance in a growing company. What I'll more likely end up figuring out is how to mitigate the uncomfortable transition from small to big on a person-by-person basis.

Recent Heros

Steve Albini


John Rawls


Alan Kay

Mulling On Google App Engine

Google provided all the facts. Everything else is opinion, preference, and hearsay. Here's mine:

The thing I'm most likely to use App Engine for in the short term is to whip together those tiny site ideas I've had floating around; stuff that's probably not going to make me any money and therefore doesn't make sense to spend money on hosting for. EC2 can't compete here, as even a tiny site means at least $70/month, and even that doesn't automatically scale. A cheap VPS also can't offer me easy scaling if a small project blows up. This is the first visible deploy-and-forget offering out there.

I like that the way to give your App Engine app a custom domain is via Google Apps (nee For Your Domain). It's too bad Google Apps accounts accounts are still second-class citizens in Google-land. You actually can't get an App Engine account with a Google Apps account. Or use Google Groups with an Apps account. Or sign up for AdSense with an Apps account. Etc. etc. etc. ad nauseam.

Python. Is anybody surprised? Python is easy to learn, clean, clear, and fast enough. Google employs Python's author, so cooking up a sandboxed version of the language probably wasn't so bad. Python web frameworks still lag a year behind Rails in features, but it doesn't matter. Python is a better fit, and people will learn it just to play in the big leagues.

Clever developers will build service-oriented architectures around App Engine. Many applications won't fit Google's constraints, and it's bad business to be completely dependent on an inaccessible vendor. But people will want some Google magic, and they'll build REST services as App Engine apps to backend sites hosted elsewhere.

My Side-Projects: Let Me Show You Them

I wrote about the value of side-projects back in February, in part because I had a total lack of them at the time. Shortly thereafter, that changed. Rather than picking up the side-projects I mentioned in that post, I've ended up spending a few spare hours on other things entirely

git-wiki

git-wiki is a web-based wiki whose data store is a Git repository of plain text files. I found the original implementation by Simon Rozet while browsing recent commits on GitHub and got inspired.

I kicked some patches around with Jesse Andrews, and pretty soon our version was a good ways beyond where Simon started. I've gotten permission from Simon to fork the project under a new (ideally, sexier) name, but nothing has come to me just yet. Others are creating their own forks of git-wiki and contributing improvements, expect it to be a pretty solid wiki for personal use or small teams fairly soon. If nothing else, it's got a simple, clean design courtesy of Timoni.

Down for everyone or just me?

The other day a friend Twittered "is LiveJournal down for everyone, or just me?" It was about the billionth time I've seen someone on a forum, IRC, IM, or Twitter ask if a site was down. See, sometimes bad things happen to good internet connections, and there's no telling if someone upstream from you biffed the DNS server or if your destination is actually unreachable. downforeveryoneorjustme.com is one trivial answer to this perennial question.

Here's how it works: you type in a domain, we transform what you typed in to something sane, and then we do a HEAD request against "/" for that domain. If the site responds in 4 seconds, it's up. If it doesn't, we report that it "looks down from here". This is, of course, totally cheesy. But it also tells you what you need to know 90% of the time.

Obviously, this is not a pro-grade monitoring solution. This is for quick, simple checks against popular domains. It gives you a quick answer and lets you go on your way, only encumbering you with some tasteful AdWords (not that I see them with my ad-blocker on). If it's not the level of detail you're looking for, there are a ton of tools that do geographically multi-homed monitoring, historical reports, etc.

I've done nothing to promote the site other than Twitter about it and put it on my del.icio.us since bringing it online this past Thursday evening. In that time it's had over 85,000 visits and over 232,000 pageviews according to Google Analytics, which is pretty much insane. It's running off of a tiny Gandi VPS and the code is a couple hundred lines (including templates) of Ruby, powered by the Sinatra micro web framework. I'm running four instances of the application behind Nginx, and save for the occasional slow request it's been standing up pretty well (low load on the box, response times are usually fast). I'll probably switch from serving via Mongrel to Thin fairly soon, once traffic has calmed down a bit.

Where Is Britt?

The future of geolocation is here.

What I've Learned

While downforeveryoneorjustme.com has quickly become popular, it's more responsibility than I really wanted out of a quick hack. If it gives someone a wrong answer, that sucks, but I don't have the time or resources or desire to build the ideal solution. I hope that some big ISP or networking outfit takes the simple design and puts it in front of a proper setup. In the meantime, it's novel to be making a few bucks off of AdWords, which I've never tried before.

Working on git-wiki is, like most developer-oriented projects I've spent time on, much more rewarding. Other developers are the best customers. But I'm actually spending more time hacking on it than, say, putting stuff in my personal wiki. I have the feeling that the quote-management application I've been dreaming of would be the same sort of affair: put hours into building it, use it for mere minutes.

Honestly, what I've learned is that I need a hobby that isn't coding. I haven't understood why so many programmers get involved with gaming when coding is, for me, really enjoyable. But it's hard to code something worthwhile and exciting that doesn't leave you beholden to supporting that code and its users. Really good personal projects quickly become jobs. Sometimes that's what you want, but one job is enough for me at this point in time.

Ultimately, I've ended up with a quandry: how do you keep side-projects manageable?

al3x at Web 2.0

When rounding up my schedule for the next couple of months, I forgot to mention that I'll be speaking at O'Reilly's Web 2.0 Expo right here in San Francisco in late April.

On Wednesday, April 23rd, Michal Migurski (of Stamen) and I will be presenting a talk called Design Your API: Learnings from Twitter and Stamen. It's kind of a cool session, we think: Mike talks about consuming APIs from a developer/design perspective, and I talk about creating and maintaining APIs from a provider perspective. There's going to be war stories and pretty graphs. I'm excited.

Funnily enough, there's a panel at SXSW called Building Developer-Friendly Web Service APIs that's on the same tip. With APIs continuing to crop up left and right, it's no surprise that people want to nosh on some best practices. Michal and I intend to deliver, so join us in San Francisco!

Defeated By Upgrades

I've waited and waited and then waited some more for a new MacBook Pro. I've not just been waiting for an upgrade but for a whole new machine, something as refreshingly different as the MacBook Air while retaining serious performance under the hood.

My current MacBook Pro is two years old. While it's worked well, the fact that it's not 64-bit has started to be an issue (ex: sharing virtual machines with coworkers). So when Apple announced upgraded (but not new) MacBook Pros today, I bit the bullet. My new decked-out 15" MacBook Pro (with a glossy screen, after much debate on Twitter) should arrive next week.

While I'm sure the new MacBook Pro will be superb, it's still a bit disappointing to wait for ages and still be purchasing a machine that's an incremental variation on a seven year old design. But then, if I cared more about design than performance, I would've gone for an Air.

On Side-Projects

Side-projects are important to every programmer I admire. Google's much-publicized 20% time is a corporate codification of the importance of side-projects; even a company that's worth billions knows that you can't keep good people working on the same thing all the time.

Side-Projects and You

There are lots of good reasons to always have some side-projects going:

• Projects keep you learning. New programming languages, new technologies, new ideas.
• Projects are mentally refreshing. Taking a step away from the problems you normally deal with is relaxing, and can lend a new perspective on how you work.
• Projects can be fun. Fun is fun.
• Projects can be profitable. Little ideas can turn into products and services that people want to pay for (or at least click ads on). Unusual ideas can forge new markets.
• Projects make you friends. Getting involved with a community is rewarding personally and professionally.

All that may seem obvious if you've made a habit of having side-projects, but I'm always surprised by how many people don't bother. But then, you don't hear about those people because they don't blog, attend meetups and conferences, or generally do things that would make them visible. Side-projects are a sign that you care. They're something we ask about when interviewing at Twitter.

Side-Projects and Me

I've had two side-projects on my to-do list for ages. The first and oldest is Peeramour, which is more or less a dating site for bloggers that emphasizes one's existing online presence rather than requiring yet another half-baked profile. I've been wanting to build this for about the last three years. Peeramour was conceived to scratch a personal itch, but I think there's a business opportunity there too. It's also something that I think would make people happy, and I feel an obligation to give something back to the web community that's been so good to me. Peeramour isn't hard to build, but I want to build it right, both aesthetically and technically.

The second project I've wanted to work on is Quotidian, a Mac OS X (Cocoa) application with which you can store, tag, and organize your favorite quotations. I've also considered building a web compliment to Quotidian that would allow you to share your favorite quotes with friends and interested strangers, but Trsly pretty much gets this job done to my satisfaction. My goal for Quotidian is mostly educational: I use a Mac every day, but I have a relatively limited sense of how I'd build a native Mac tool for myself to use. I'm also concerned that too many of my eggs are in the web-programming basket. Web apps may be vogue, but desktop application programming isn't going to disappear any time soon. It's tough to be a skilled generalist, though, and while I've learned a bunch of theory about how to write Mac software, I haven't had time to get into the nitty-gritty with this project. Once again, the difference is between doing it and doing it right, and the latter requires a ton of knowledge about a development platform with a nearly 20-year heritage.

One of my old side-projects, acts_as_sanitized, has been forked and surpassed (with my hearty blessing) by xss_terminate, written by Luke Francl, who's blogged about it here. acts_as_sanitized was released just before I got swamped by work on Twitter, and I owe Luke for making it something useful again. It's a lesson in the value of open-sourcing, and it leads me to what follows.

Side-Projects and Twitter

Working at Twitter is more than a full-time job. As I mentioned in a previous post, we're still a very small technical team (presently five people writing code and two looking after servers). There's always something work-related I could/should be working on, which means that there's basically no room in my life for guilt-free side-projects. No surprise, right? We're a startup.

One of my goals is that Twitter gets big enough that we have room for side-projects. Right now it just doesn't make business sense. We barely have time to open-source projects like Starling that can benefit from the community's support, much less to code up our own off-the-wall ideas. Compared to our peers in the Bay Area Ruby community we open-source a pathetic amount of code, and I'm eager for that to change. Part of making that happen is approaching our internal goals with the idea that the solutions need to be generic enough that they can be readily opened-up to outside contribution.

The people I'm really excited about working with are all big open-source contributors, and I don't think I'm alone in that. As part of scouting for talent becomes evaluating open-source work, it's going to become a standard part of every good company's growth to standardize policies around open-source contribution and side-projects. After all, Twitter started out as a side-project, which pretty much says it all.