How cloud computing changes thingsOne of the biggest shifts in technology today is the proliferation of API-driven services. Five years ago, if you wanted to store files (S3), host a web application (Heroku), send email (Sendgrid), process video (Zencoder), or interface with telephony (Twilio) or geolocation (SimpleGeo), you bought expensive hardware or spent months building software. Today, you sign up for an inexpensive service, and you're up and running in an afternoon. This is exciting. It parallels the proliferation of open-source software after the first dot-com boom; in 1996, a startup needed expensive software and hardware (Oracle and Solaris), but by 2006, you had comparable (better) tooling for free with MySQL and Linux. This changes the rules for startups. Cloud Computing, Software/Platform/Infrastructure/Application-As-A-Service - also known as XaaS - is just the next step in this process. This is like Moore's Law for functionality. Every 18 months, you can do twice as much at half the cost. This trend lets us build and deploy a powerful, full-featured application in, say, two days, and we'll be able to do more in a few years. We can do things now in an afternoon that would have taken months in the past.
In praise of marginal featuresConventional wisdom, 37signals style, is that you should do as little as possible. Not just as a way of getting out the door quickly, but as a benefit. Less is more. Better to do 20 core features than to do 20 core features + 20 marginal features. This advice might be good for user-facing web applications. But if you're building XaaS, marginal features are awesome. That's because when you're a service, what's marginal to one user might be core to another. We built Zencoder initially with a minimal feature set: encode anything to high-quality MP4, and do it quickly. Today, MP4 is still the majority of our encoding (85%). But we've gone well beyond this initial core; we've added support for Ogg, WebM, WMV, VP6, and 3GP; powerful options for thumbnailing and watermarking; and advanced video processing options. This week, we're releasing a bunch of advanced audio processing features. These features let you normalize audio levels, fade in/out, control gain, apply a highpass/lowpass filter, apply a expand/compress effect, and apply basic equalization. We're even adding a karaoke effect option. We don't have a dozen customers demanding that we add control over audio gain. Audio EQ options might not matter at all to 99% of our customers. No one may ever use the lowpass filter. But we don't know, and it's not up to us to know. The lowpass filter was trivial to add (about 15 minutes of marginal time, all things considered). Our job is to provide powerful tools and let our users decide what options matter.
An API is not a UIThis is where an API is different from a UI. Adding extra features to a UI increases complexity linearly - O(n), let's say. Double the features and you double the complexity. If features in a UI interact with each other, this might actually be O(n-squared) - double the features, and get exponentially increasing complexity. It's much harder to deal with 60 options in a web-based form than 20 options. But APIs are different. An API with 60 options makes for longer documentation, certainly. But if the options are well-chosen and well-documented, an API with 60 options is barely more complex than an API with 20 options. You should be able to safely forget about features you aren't using, and just use the features that matter to you. Done well, incremental features in an API only increase complexity by O(log-n) or even O(1) - virtually no complexity increase at all. Of course, not every marginal feature is a good feature. Avoid marginal features that are confusing. Generally, this involves features that interact with other features, or that users have to manage even if they don't want to. If a marginal feature makes it harder to use core features, it might not be worth having. But if you can successfully ignore a feature that you don't need - if you can happily use Zencoder for years without ever looking at
audio_compression_ratio- then the feature probably isn't confusing. Avoid marginal features with no benefit. This is obvious, but is worth stating. If there is both a high-quality and a low-quality version of a feature, and there is no advantage to the low-quality version (e.g. speed, price, or compatibility), stick with the high-quality version only. Avoid marginal features that are expensive to develop. Don't spend months of time working on something no one is going to use. Build marginal features when they're easy to implement, or you think they'll be especially beneficial to some of your users. Someone out there will be able to do something really amazing with our advanced audio processing features - something that I would never guess. I'm amazed by the wide range of creative things people use Zencoder for, and I'm sure the same is true of any API-based service. Running a XaaS business, it would be a disaster if we tried to anticipate - or control - how our users use us. We can make recommendations, of course; we can tell our users when they're making an obvious error. But at the end of the day, if we can power creative and unexpected uses of our platform, everyone wins. So please, build an awesome app using karaoke mode, and come tell us about it.