User research as a barometer of software design

As both a programmer and a UX designer (and having studied and done UX/usability research), I have quite a few things to say about this. (The following points aren’t in any particular order, and don’t necessarily come together to form any larger point.)

Examples?

You give one example (‘DRY’) of a pattern that’s supposedly Correct™ but might not make code “easier to work with”. That makes the post read a bit like one of those innumerable “Against <Some Commonly Done Or Used Thing>” essays, where the author, annoyed by how everyone’s always telling him to do or use that thing, even when he kind of doesn’t want to do or use it, decides to go on a rant about the thing. (Which is not necessarily a bad thing; such rants are often entertaining, and sometimes quite necessary.)

So, are there other examples you are thinking of (or can easily think of), of software design patterns that are supposedly Correct™, but that actually (you think) might make code harder, and not easier, to work with?

How close “contact with reality”?

You talk about user research at the start of the post, but then you transition into talking about thought-experimentation. I note that these are not only not the same thing, but not even the same sort of thing!

Attempting to do user testing as a thought experiment, instead of doing it for real, would be useless. I can tell you, from personal experience, that the value of user testing comes from the fact that users can, and will, surprise you. You can sit back and imagine users interacting with your system as much as you like, and you will never be able to imagine the sorts of things that actual users will actually do when they try to use it. Never.

I see no reason why the same shouldn’t be true in the case of software design patterns and the coding experience…

Note that this is especially so given that what we imagine it is like to work with one or another sort of code, is affected quite strongly by our existing views on the design patterns (or other properties of a codebase) in question. If I think that DRY is a sine qua non of good code, then, when I imagine working with code that conforms to that principle, I’ll imagine a sense of ease and elegance; while the very thought of working with a duplication-heavy codebase will fill me with revulsion.

In your case, I suspect, what happens is the reverse: you don’t think much of DRY as a principle, so, when you do this thought experiment, you get more or less the opposite result. But in neither case does the thought experiment actually tell us anything (or rather, anything more than we already know) about how it’ll actually go, once we sit down and start coding…

The third user

You write:

The bigger picture is that you want code that is designed in such a way that it is easy to work with.

But the question you neglect to ask (and you are in exalted company in this, I assure you!) is: easy for whom, exactly—and just what constitutes “working with” the code?

“The Third User” is a famous essay by Bruce Tognazzini (creator of the Apple Human Interface Guidelines, and a legend in the field of software usability). It explains the pattern behind many of Apple’s design choices over the last two decades or so (the essay was written in 2013, but it has become, if anything, even more true since then). That pattern is simple:

Design the product so that it appeals to (1) the person looking at it in the store and deciding whether to buy it, and (2) the person who’s just bought it, opened it, and is now using it for the first time (and not deciding to return it; and writing good reviews on Amazon and making enthusiastic posts about their new purchase on social media; etc.). Don’t bother designing the product so that it fits the needs of (3) the experienced user, who has long since mastered the basics, and now has more complex needs, and wants to do advanced things. (Why bother? You already have their money, after all.)

As the market for computers, smartphones, etc. has grown, and as startups (and, therefore, new products) have come to play an increasingly large role as sources of user-facing technological products, there has been a tendency in user testing to focus on new users. There are many factors that have contributed to this, too many to enumerate here, but the result has been that “how quickly can a person start doing something with the product, knowing nothing about it (and having absolutely no interest whatsoever in reading any instructions or taking any time to learn anything)” has come to dominate most other possible questions for user testing to answer.

The result is that the “third user effect” has become pervasive in consumer technology. The potential user is appealed to, and the new user—but not the experienced user; not the advanced user. (Remember the term “power user”? One hardly hears it, these days… there’s a reason for that—and it’s not that modern software is just so capable that it lets anyone do all the clever things that once called on advanced skills to accomplish!)

What you are proposing, in essence, is to enshrine the “third user effect” in how we think about software design.

Is it easy to work with a codebase? How does it feel? Both the answers to those questions, and their relevance, depends on the details! Are we talking about how easy it is to figure out just enough to start adding new code, how quickly one can “get up to speed” and start contributing? Or are we, instead, asking about long-term effectiveness—over a period of a year, two years, five years, of working with this codebase, how productive can you be with it (how long does it take you on average to add a feature, for example)?

What about long-term maintainability? DRY is a good example here: if you have much code duplication, and you want to change how the code does something, do you have to change it in one place, or in twelve? Is the duplicated code exactly the same in each of those twelve places, or is it slightly different in two of them? Do some of the instances of that code have side effects? Are you likelier to introduce bugs with your twelve changes than with the one?

And speaking of bugs—how easy is it to fix them, or find them in the first place? It’s a truism that fixing bugs in code is harder than writing the code in the first place, so if you make it easier to write code but harder to fix bugs in it, haven’t you made things worse?

More broadly: are you optimizing for the one-time contributor, or the long-term maintainer? Is your goal to get some code written now, or for that code to still be working in a year or a decade? Is the point merely to write code, or to write good code? To do something, or to do the right thing?

It's a trap. It's a trap in UX, and an analogous trap in software design.

The problem with UX research, as normally practiced, is that it prioritizes first impressions and neglects what happens when the user has been using the system for awhile and understands it well. So you wind up doing things like adjusting all the buttons to control their prominence, to guide new users to the main interactions and away from the long-tail interactions, at the expense of those buttons having any sort of coherent organization.

In the case of software, UX-style user testing is going to lead straight into a well known, known bad attractor: brittle magic. There is a common pattern in libraries and frameworks where they do a great job making a few common development tasks look really easy, shielding the developer from a lot of details that they probably should not have been shielded from. And what happens with these systems, almost invariably, is that as soon as you start using them for real instead of in toy examples, they reveal themselves to be overcomplicated garbage which impedes attempts to understand what's really happening.

I think you've noticed that the consequentialism vs deontology debate happens in software design, just like everywhere else.  My preferred solution is to recognize that you don't always have the time (or the willing customers, or the knowledge of what dimensions to test) to be empirical about an approach, and having a set of heuristics (aka rules) to guide you is incredibly helpful.

Predict the results, and test your intuitions whenever you can, and especially when it's a pivotal decision you can't change later.  Taking on dependencies and locking in to a language or platform fall into these categories - be careful, prototype, measure.  The vast majority of things (factoring of your codebase, location and sharing mechanism for libraries, etc.) you can make lighter-weight choices, and test as you go - if it becomes annoying, then change it.

UI design contains both.  By the time you're getting to user testing, you've ALREADY committed to a small number of options, and you've done so by your own use of the product, and intuitions about what different customer personae will want.  And even when doing user testing, there is usually NO WAY to resolve the "beginner vs expert" conundrum.  You can only test on beginners, so you only get evidence of how easy it is to discover how to do a new thing.  You lose out on understanding how cumbersome your design is for someone who spends hours each day in the product and just wants to get their work done efficiently.  

The way to avoid that is to override the user research with your intuitions, AND put enough telemetry into the product that you can learn over time how the product is actually used, to figure out the right balance (or make the investment to serve both sets of users).

Some people seem to do this automatically. They notice which things make code harder to work with and avoid them. Occasionally, they notice things that make working with code easier and make sure to include those bits in. I guess that's how you get beautiful code like redis or Django.

But I've never seen any formal approach to this. I've gone down the software craftsmanship rabbit hole for a few years and learned a lot thanks to it, but none of it was based on any research--just people like Beck, Uncle Bob, Fowler, etc. distilling their experience into blog posts or books. The downside of that is that it would ignite furious debate that would go nowhere because there was no data to back it up, just anecdotes. These debates, I think, turned a lot of people off, even though there were gems of wisdom there.