logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Utility-vs-usability.md (3401B)

    

  1. ---
  2. title: Utility vs usability
  3. date: 2020-11-06
  4. outputs: [html, gemtext]
  5. ---
  7. In many fields, professional-grade tooling requires a high degree of knowledge
  8. and training to use properly, usually more than is available to the amateur. The
  9. typical mechanic's tool chest makes my (rather well-stocked, in my opinion) tool
  10. bag look quite silly. A racecar driver is using a vehicle which is much more
  11. complex than, say, the soccer mom's mini-van. Professional-grade tools are,
  12. necessarily, more complex and require skill to use.
  14. There are two attributes to consider when classifying these tools: *utility* and
  15. *usability*. These are not the same thing. Some tools have both high utility and
  16. high usability, such as a pencil. Some are highly usable, but of low utility,
  17. such as a child's tricycle. Tools of both low-utility and low-usability are
  18. uncommon, but I'm sure you can think of a few examples from your own experiences
  19. :)
  21. When designing tools, it is important to consider both of these attributes, and
  22. it helps to keep the intended audience in mind. I think that many programmers
  23. today are overly concerned with usability, and insufficiently concerned with
  24. utility. Some programmers (although this sort prefers "developer") go so far as
  25. to fetishize usability *at the expense* of utility.
  27. In some cases, sacrificing utility in favor of usability is an acceptable
  28. trade-off. In the earlier example's case, it's unlikely that anyone would argue
  29. that the soccer mom should be loading the tots into an F1 racecar. However, it's
  30. equally absurd to suppose that the F1 driver should bring a mini-van to the race
  31. track. In the realm of programming, this metaphor speaks most strongly to me in
  32. the design of programming tools.
  34. I argue that most programmers are professionals who are going to invest several
  35. years into learning the craft. This is the audience for whom I design my tools.
  36. What trouble is it to spend an extra hour learning a somewhat less intuitive
  37. [code review tool](https://git-send-email.io) when the programming language
  38. whose code you're reviewing required months to learn and years to master?
  40. [![An XKCD comic which depicts a table that compares "time to improve task" versus "time saved by improvement" and how to figure if the improvement is worthwhile](https://imgs.xkcd.com/comics/is_it_worth_the_time_2x.png)](https://xkcd.com/1205/)
  42. I write tools to maximize the productivity of professional programmers. Ideally,
  43. we can achieve both usability and utility, and often we do just that.
  44. But, sometimes, these tools require a steeper learning curve. If they are *more
  45. useful* in spite of that, they will usually save heaps of time in the long run.
  47. Instead of focusing on dumbing down our tools, maximizing usability at the
  48. expense of utility, we should focus on making powerful tools *and* fostering a
  49. culture of *mentorship*. Senior engineers should be helping their juniors learn
  50. and grow to embrace and build a new generation of more and more productive
  51. tooling, considering usability all the while but never at the expense of
  52. utility.
  54. I'll address mentorship in more detail in future posts. For now, I'll just state
  55. that mentorship is the praxis of my tooling philosophy. We can build better,
  56. more powerful, and more productive tools, even if they require a steeper
  57. learning curve, so long as we're prepared to teach people how to use them, and
  58. they're prepared to learn.