Why services should offer marginal features (with apologies to 37signals)

I agree with the conclusion, but I don't think the argument is presented all that well:<p><i>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.</i><p>I don't think this is any less true in user-facing applications than it is in APIs. It seems to me that the main difference is that user-facing apps tend to be solving higher-level problems (eg. project management vs encoding video).<p><i>Our job is to provide powerful tools and let our users decide what options matter.</i><p>37signals also listens to users, but the total number of users per revenue dollar is higher, the scope of the usage is wider, and the cost profile (development, maintenance and cognitive overhead) tends to be different. In either case any new feature requires a cost-benefit analysis.<p><i>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.</i><p>This is certainly true for options that are simply wrapping command-line options of open source components. However if you're implementing code on the back-end, these options can easily add complexity to the whole system.<p>It's true that a checkbox in a GUI is a much higher burden on the user than an option in service API documentation, but then again a service already starts with an order of magnitude higher usability burden than a GUI. This is of course because APIs are designed to be coded against, so the amount of user effort expended is amortized over hundreds or thousands of compute hours.<p>I'm sure the author understands all this, but it just didn't quite come out of the article.

I'm not sure I agree that an API is that different from a UI. Try working with the Windows API in C#. Lack of default parameters means that for every API call I have to explicitly set about 30 options (29 of which I'm usually not using).<p>It sounds like the point you're making is that, if well-organized, marginal features can add value without encumbering users that aren't interfacing with them. That makes a lot of sense, and I agree with your approach over the 37signals approach. Marginal features <i>can</i> be core features to some users. It's just important that we keep the interface/API organized in a thoughtful manner, so that unused features don't distract people.

No need to apologize to 37signals. They wouldn't to you!

I think 37signals acknowledges that "what's marginal to one user could be core to another". Their point is, "who cares?" They're optimizing for minimal feature set, maximal user base, so they can refine the hell out of the features they do offer.<p>There are indeed other product strategies, but they're all fraught; as Apple's competitors discovered, you can even lose users who use your "marginal" features if the real core features in competitors offerings are better executed.

API complexity - just as much as UI complexity - represents a host of different code paths in your software that you need to manage.<p>You need to make sure all these code paths work; and you need to make sure they don't interact in unexpected ways. You need to test not only the well-used paths (which your users will test for you - you'll find out quickly enough if commonly-used functions fail!) but also all of your less-commonly used paths, which will bit-rot if you're not on top of them all the time.<p>The art of good API design is entirely different, but just as hard, as good UI design. Bolting on a bunch of new features does not a good API make - you need to ensure that you add features sensibly, orthogonally, and matching your user's expectations.<p>Expanding your API also means you need to make sure you have a good understanding of the load profile of all your API calls, both individually and in combination.<p>In short, I think the OP is underestimating the complexity involved in designing and managing an API - just because the problems arising aren't the same as those in UI design doesn't mean they're not there.

I'm not sure that API complexity is that different from UI complexity.<p>From the article: "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."<p>This is true, but how is this different from a UI that's done well? With a great UI you should also "be able to safely forget about features you aren’t using, and just use the features that matter to you." Isn't that just good information architecture combined with a design that prioritizes and encourages accomplishing the most common tasks?<p>A poorly designed API adds just as much complexity and frustration as a poorly designed UI. But I doubt that a UI "done right" still increases complexity by O(n) or O(n-squared).

Takeaways:<p>1) "what’s marginal to one user might be core to another"<p>2) APIs can afford to have more marginal features than UIs because the complexity is largely hidden. Done right, there's more API documentation but the main interactions aren't affected or made more complex.

APIs introduce a more long-term maintenance burden than GUIs. If you take away a checkbox that hardly anyone used, no big deal, a few people are momentarily confused. But if you take away an API call parameter that hardly anyone used, a few people still depended on it, and maybe the change broke their systems and caused them to lose business until they patched it. Then they complain online, cancel their agreements with you, scare away your potential customers... it can be a disaster.<p>Everything you put in your API documentation is a promise. Facebook gets away with frequent, breaking API changes because they have a monopoly. Until you can say the same, it might be a good idea to keep your API stable.

&#62; 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.<p>Those are just the default audio filters in mplayer. At least it can't have cost much to implement.

Aside: with application development becoming so much easier and faster, will it also become much more competitive (which is bad for developers), in comparison with systems/infrastructure development?

This is why PHP works well for getting going fast, you don't have to learn all the built-in functions, just the ones you need.<p>In this case the name-space is the API.