Reducing friction

Great libraries don’t just package useful functionality in a re-usable package, they do so while reducing friction. Low friction means that the answer to “hey, wouldn’t it be great if you could just do X?”, is “yes, it would, and you can.” Doing something simple is never complicated, and the way to do it is easily found, if not plainly obvious. Using such libraries is a joy, never a struggle. Of course, getting results like those is far from being easy, and requires smart designs and clean implementations. Most of all, it requires the library author to put himself in the shoes of his users.

jQuery, for example, reduced the friction in the unimaginative API that browsers were providing over the DOM, and made it possible to work over sets of nodes as if they were one, and to chain calls to perform complex tasks in a fluent manner. jQuery was lubricant for the DOM.

Rails removed friction from building data-driven web applications by providing easy scaffolding and good conventions for common and repetitive tasks.

C# is full of features that reduce friction… Its dynamic feature was designed to make interoperability simple and fluid. The “yield” keyword makes the building of enumerable types frictionless, saving developers from the bore of writing the same state machine over and over again. The “async/await” pair makes it possible to write asynchronous code that doesn’t look like a fallen Christmas tree, and that isn’t callbacks within callbacks within callbacks.

Dynamic languages remove the ceremony of writing interfaces and classes, and let you build and augment objects as needed.

Document databases shatter the requirement to model your data in rigid tables and relationships.

Next time you build an API, a library, or a product, don’t just implement features, do it so that your users encounter the least resistance while using them.