The More Important Half of Great API Boundaries

Designing good tools depends on much more than the features you include. Like the best margherita pizzas in Italy, or the best ambient music, the most well-crafted things tend to be invented on the premise of what they don’t include.

The tendency to stuff in feature after feature is a natural one. As a cook, your first instinct is often to throw in every spice and topping in the pantry; I’ve got them here and might as well use them, right?

The best software, and the most satisfying APIs, are the ones that know what they are capable of, and what they’re not.

To the contrary, the most difficult software to wrangle is of the variety that can’t quite figure out what it is meant to do.

To me, a spec, philosophy, or doctrine exudes the spirit of a good API.

What do I do? And perhaps even more important, what don’t I do?