1. 14

  2. 11

    When designing tools, it is important to consider both of these attributes, and it helps to keep the intended audience in mind. I think that many programmers today are overly concerned with usability, and insufficiently concerned with utility. Some programmers (although this sort prefers “developer”) go so far as to fetishize usability at the expense of utility.

    If anything, I’d say that not enough programmers focus on usability. Most software systems are hard to use, inconsistent, and have regular arbitrary changes to the user interface. It doesn’t matter what your system is capable of if no one can use it. The history of computing is filled with extinct systems that were hard to use in comparison to a competitor.

    I argue that most programmers are professionals who are going to invest several years into learning the craft. This is the audience for whom I design my tools. What trouble is it to spend an extra hour learning a somewhat less intuitive code review tool when the programming language whose code you’re reviewing required months to learn and years to master?

    The pay-off for learning a new programming language is often quite clear, e.g. I need it for work, the market prospects are good, or there are compelling use cases. The pay-off for learning a code review tool is smaller and potentially negative - I may not end up using it.

    I write tools to maximize the productivity of professional programmers. Ideally, we can achieve both usability and utility, and often we do just that. But, sometimes, these tools require a steeper learning curve. If they are more useful in spite of that, they will usually save heaps of time in the long run.

    It’s often unclear as a potential user why the complexity is present.

    • The model is genuinely different, e.g. APL, Forth, Haskell, Prolog.
    • The domain is inherently complex.
    • The complexity is required for some rare use cases that I’ll never run into.
    • The complexity exists for historical reasons, e.g. termios, POSIX, and Sendmail.
    • The user interface was an afterthought; the designer focused their attention on the implementation.
    • The system evolved arbitrarily without an overall design.
    • The design was done under a severe time crunch, e.g. JavaScript.
    • The designer tried but was unsuccessful in creating an easy to use system.

    The first two reasons are rare; if your design is complex it’s probably for one of the other reasons.

    1. 2

      The pay-off for learning a new programming language is often quite clear, e.g. I need it for work, the market prospects are good, or there are compelling use cases. The pay-off for learning a code review tool is smaller and potentially negative - I may not end up using it.

      There are two tools I am willing to put up with a steep learning curve: an editor and a programming language. Those two tend to transcend working environments, less so the language (although language pedigree or paradigm does). To some degree, the system on which these things run (*nix, Windows, and so forth).

      Code review systems, emulators, search tools, version control system, and especially email clients (among other tools) are not things that I feel I should be spending my time learning in great detail. These are very likely determined by the organization you work for. At none of my jobs have I had the choice of email client, for example. Do I care? No. These things are just incidental to the work at hand. I will eventually learn to use what the workflows of the group are built around. It’s typically not that hard.

    2. 9

      Professional-grade tools are, necessarily, more complex and require skill to use.

      I do not agree. Sometimes professional-grade tools are just… better. Like for cooks, for example.

      1. 2

        This is a “well-actually”, FYI.

        1. 15

          The article is premised on a conflict between utility and usability. Pointing out that many professional tools are simpler or easier than amateur tools is an important nuance not covered in the article, and so is a valuable contribution. Dismissing it as a “well-actually” is not a valuable contribution.

          1. 3

            I thought that this line covered the case of professional utility and usability:

            Ideally, we can achieve both usability and utility, and often we do just that. But, sometimes, these tools require a steeper learning curve. If they are more useful in spite of that, they will usually save heaps of time in the long run.

            1. 3

              The quote rustybolt pasted is taken out of context and used misleadingly; here it is, at the end of the opening paragraph:

              In many fields, professional-grade tooling requires a high degree of knowledge and training to use properly, usually more than is available to the amateur. The typical mechanic’s tool chest makes my (rather well-stocked, in my opinion) tool bag look quite silly. A racecar driver is using a vehicle which is much more complex than, say, the soccer mom’s mini-van. Professional-grade tools are, necessarily, more complex and require skill to use.

              So it’s clear that the author is using that statement colloquially/with qualification, and anyone who actually read the preceding statements would know this.

              But even if we accept that the statement is false on its face, professional cook’s equipment is, in fact, harder to use. A stainless steel pan is harder to use than a home cook’s non-stick. A wok burner is harder to use than the burners on a typical stove. A Hobart silcer or stand mixer is much more dangerous and capable than a mandoline slicer or Kitchen Aid mixer. The list goes on.

              1. 2

                The line that I quoted states a fact that is false.

                You are generalizing “tools” to “equipment”. That you can think of many tools for cooks that are more complicated does not make it true for all cases.

                Professional-grade pots, pans, knives, spatulas, forks, stoves, extractor hoods, mixers are all things which I don’t consider more complicated than the amateur-grade equivalents. The same goes for most sporting gear and instruments.

        2. 6

          I’m rather sympathetic to this article. Both in terms of command line tools, and conceptual tools, our industry tends to favor things that are easy.

          You can attribute some of this to ideology, and some of it to just not wanting to put in the work (I don’t say this with judgement–I’m guilty of doing things in terrible ways because I don’t invest the time to learn a better way).

          However, one factor that you have to take into account is that our industry has a lot of bullshit floating around. A large fraction of experienced engineers will swear up and down that the fad of the day makes you super-efficient. Another fraction insists that nothing useful has been created this decade. When a tool is easy to use, I can see for myself what benefits it has. When a tool is difficult to use, I have to take a leap, and the question becomes one about whose judgement I trust.

          1. 4

            Looks like Drew is shifting terminology here somewhat. If we go by the definition of Usability it looks like his Usability is actually Learnability, and his Utility seems more like Efficiency, rather than what the definition calls “Utility”.

            I wish we’d all stuck to a common terminology :-)

            1. 4

              Software tools are different from hardware tools. This rather spoils the entire rest of the analogy, by showing how empty the opening paragraph is.

              Crucially, software tools can be changed over time. They can include user-specific customization, and in some cases can be extended far beyond their original design specification. These changes are not merely compositional, in the case of hardware tools; they can involve deep cross-cutting changes to how the tool behaves.

              In software, we deal with concepts, and anything can be conceptually simple once enough words are defined. As a result, it doesn’t make sense to talk about a software tool as having any sort of innate conceptual complexity which prevents people from using it. BMP, TIFF, and PNG form a hierarchy of complexity if we want to talk about programmer effort for decoding and encoding into their formats, but the user treats all three uniformly with the same box-of-pixels concept. And if the user further conceptualizes an image as a visual signal, then JPEG becomes included in the user’s considerations, despite being totally different from the other three in how it treats pixels.

              The second paragraph tries to give an intuitive explanation of “utility” and “usability”. Ignoring that utility is usually a particular concept in utilitarian philosophy, the examples don’t really make sense. Are utility and usability measurable with real numbers? What is the utility or usability of a child’s tricycle with a pencil attached by a string?

              There is some possible meat in the fourth paragraph. A minivan isn’t a racecar, and part of that is because they have different transmissions with different gearing. There is a concept I’ve noticed but have no name for, where a system has a “slow” analytic mode which operates at the level of seconds/cycle, and a “fast” batch mode which operates at cycles/second. There’s definitely some sort of phase transition within the structure of software.

              And the fifth paragraph is an advertisement. It’s got the only link in the article, to one of the author’s projects.

              1. 3

                Chorded keyboards are high utility, and are not dumbed down to the level of regular keyboards. However beyond those who fetishise so-called professional tooling, and those who have babies on their laps while coding, I don’t actually see the value in a tool that’s hard to use.

                Professional traders have interfaces that require weeks of training to use effectively. Arguably most of those interfaces can be made simpler. Arguably as well exposing the complexity of the underlying domain does not actually make life easier.

                We as a group have mostly rejected languages like APL with massive utility and low readability. I happen to like APL, but I also don’t look forward to reading the resulting code.

                Making tools easy to use is a good thing. If you can expose the same functionality with less work, why not do so?

                This is not to say there is no place for tools that take time to learn. I use vim. I occasionally use emacs. Neither is intuitive until you are trained in it, but I feel better using them than I do IDEs with more buttons than I could learn how to find. Perhaps Discoverable is not necessarily Usable.

                Maybe I’ll put it this way.

                The more usable your tool is, in general, the better; this is disregarding utility as not relevant. Training on a difficult tool costs time, money, and brain cells.


                The other feeling in this post with which I disagree is the “professional software engineer guild” thing of requiring a mentor to get in to this field. I love programming partly because you need nothing but the ability to enter text into a computer. It’s good to encourage mentoring, but I have a distaste for people encouraging mentorship rather than an easy process or tool.

                1. 3

                  Dear Drew

                  I want to raise a small point, not with your argument, but with the text you wrote. You say it’s okay to sacrifice a bit of what you call “usability” for what you call “utility”. And by usability I understand you mean the ease of understanding the tool, and by utility the ability to get something done with it. But usability can also be understood, in the eye of many, the ability to use the tool effectively. For such persons who read a bit too fast, what it seem you say is “It’s okay to make the tool less effective to use in order to make it more effective to use.”. And of course they’ll disagree with such a blatant contradiction of logic.

                  I would suggest that maybe your text will be better would you be restate your argument with simple, easy to understand word as follow : “It’s okay to write tool that take time to learn if, by sacrificing the time to get effective, we get a design that allow expert to work very fast.”

                  I know it is longer and it is more annoying to write it like that, but the reason I encourage you to restate your argument, is that us developer are a bunch of big nerds, and when us big nerds see big word with precise definition, we become full of big self-righteousness and start yelling: “Well, ACTUALLY, that is NOT what the words “usability” and “utility” MEAN”. And then the debate evolve to be about what the correct definition of the words are, completely drowning the point originally made. This is not very efficent.

                  In other words, big “precise” word have poor usability, because nobody understand them in exactly the same way, but every nerd think it has the One True Definition™. As such their utility to get a point across is rather limited. It’s easy to think they allow you to communicate faster, but, unless everybody took the time to standardize such word in the same, precise way, they just confuse everybody. You really have to think about the correct time to use them, and they should be avoided when possible. They most certainly should not be used as an excuse to communicate poorly.

                  I hope you understand what I mean?