Usability versus composability

Conal Elliott gave a talk at Google a while back in which he points out the tension between usability and composability, between software that is user-friendly and software that is programmer-friendly. Consumers like software that’s easy to use. But programmers like software that’s easy to compose, i.e. to combine in unanticipated ways. Users want applications; programmers want libraries. Users like GUIs; programmers like APIs.

It’s not immediately obvious that usability and composability are in tension. Why can’t you make users and programmers happy? You may be able to make some initial improvements that please both communities, but at some point their interests diverge.

Vivek Haldar picks up this theme this morning in his latest blog post. He uses “operation versus expression” to express the same idea Elliott’s idea of usability versus composability.

Combining Elliott and Haldar’s presentations, we have these contrasts.

 Usability  Composability
 Operation  Expression
 Visual / GUI  Syntactic / CLI
 Bounded  Unbounded
 Externalize knowledge  Internalize knowledge

Neither column is necessarily better. Sometimes you want to be in the left column, sometimes in the right. Sometimes you want a stereo and sometimes you want a guitar.

When I file my taxes, I want the software to be as easy to use as possible right now. There’s no long-term use to consider since I’m not going to use it again for a year, so I’ll have forgotten anything peculiar about the software by the time I open it again. But when I’m writing software, I have a different set of values. I don’t mind internalizing some knowledge of how my tools work in exchange for long-term ease of use.

Related posts

3 thoughts on “Usability versus composability

  1. That’s a great way of thinking of this issue. At our little natural language company, we run into this issue all the time because we sell an API and do consulting to integrate it. One of the last potential customers we talked to downloaded our tarball and got confused because there was no executable anywhere.

    The API orientation allows us to build fairly low-cost custom solutions for customers, but it’s hard to sell in bulk. It also saves us from having to carry beepers and support applications outselves, which is neither what we like to do nor what we are good at. That’s why our founder, Breck Baldwin, calls us a “cabinet shop” rather than a startup.

    The attempts to split the difference lead to all the integration environments that try to wrap unix-style programs in drag-and-drop GUIs. This usually means a programmer has to write two bits of code — one to do the work, and one to integrate with the putatively time-saving “framework” (e.g., J2EE).

    As Yuval pointed out in the comments, this divide is most often invoked in comparing unix-style pipes with apps. Calling this a Unix/Windows divide is bogus — I can program unix-style on Windows (with Cygwin) and run apps on Unix such as are commonly found on the Linux or Mac desktops.

  2. I kind of don’t get the comparison with respect to users vs programmers, but I recognize an analogous tension in programming language styles going back to the 1950s. I see statement-based languages as being in the left column and expression-based languages in the right. The terms “visual, operation, bounded, usable” seem relevant for the rationale given for the preference given to these languages for certain kinds of users/programmers.

Comments are closed.