# User research as a barometer of software design

([Cross-posted](https://adamzerner.bearblog.dev/user-research-as-a-barometer-of-software-design/) on my personal blog.)

In UX design, they do something called [user](https://blog.codinghorror.com/low-fi-usability-testing/) [research](https://sensible.com/rocket-surgery-made-easy/).

Consider an example. You have two designs: A and B. You think A is better but John thinks B is better. Who's right?

Well, you can debate a bunch of stuff. Design A breaks this guideline, Design B does breaks that guideline. Or... you can actually sit down next to users and _watch_ them use each design. See how much difficulty they have and stuff. If users are all confused by Design A and content with Design B, then Design B is the winner, despite whatever the theoretical arguments might say.

I think the same thing is true in software design. For example, consider two designs: C and D. Design C has a lot of duplicate code, whereas Design D is, well, DRY.

Design D is better, right? Isn't DRYing up duplicate code is a good thing?

Maybe. Maybe not. They might have taught you about DRY code in school, but that doesn't matter. The barometer here is user research, where the users are the programmers. Imagine that you had some programmers try to build the app using "wet" code (Design C). And then imagine that you had other programmers try to build the app using DRY code (Design D). Who would have an easier time?

Why am I making this point? Isn't it obvious? Well, I think that it can be easy to get lost in the weeds a bit with software design and lose sight of the bigger picture. The bigger picture is that you want code that is designed in such a way that it is easy to work with. Imagine having to implement a new feature and being able to easily read through the existing code, understand it, and figure out where you need to make the change for your feature. That is what we are aiming for.

What do I mean when I say I think people get lost in the weeds? Here's what I mean. I propose that they fall victim to [Lost Purposes](https://www.lesswrong.com/tag/lost-purposes).

Imagine a high school student who starts off trying to get good grades in order to get into a good college, in order to eventually get into a career that will make them happy, but who finds themselves stressed about getting a B+ in a class during the last semester of their senior year when they have already been accepted into the college they are going to attend. This student now cares about the grade in and of itself and has lost sight of the fact that it originally was just a means to the end of leading them to a happy and fulfilling life.

Similarly, the purpose of different design patterns like DRY is to make the codebase easy to work with. But, like the high school student, we lose sight of this. We start seeing them as ends in and of themselves, and we judge code according to how DRY, SOLID and ACIDic it is. Unfortunately the acronyms are just a proxy for what we are truly interested in. They're not the real thing.

That doesn't mean the acronyms aren't useful though. I think that they are useful. I just think that they need to be combined with... something else. It is easy to lose sight of the forest for the trees when you think about the acronyms. User research, at least as a thought experiment, helps you keep sight of that forest, I propose.

Consider the DRY vs "wet" example. At first it might seem obvious that you'd want to dry up that duplicate code. But what happens when you do a little thought experiment. Imagine, in your minds eye, yourself working with the DRY code. And now, again, in your minds eye, imagine yourself working with that "wet" code.

What does it feel like? Maybe that "wet" code [isn't actually that bad](https://gordonc.bearblog.dev/dry-most-over-rated-programming-principle/)? Maybe it's kinda nice. Maybe you find that, despite what the professors said, the duplication isn't actually causing you difficulty. Maybe you [enjoy](https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction) the fact that you get to deal with things at a more object/ground level rather than at the more abstract level that the DRY code forced you into. Maybe it lead you to some new acroyms like [YAGNI](https://www.martinfowler.com/bliki/Yagni.html), and some new rules like the [Rule of Three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)).

Again, I'm not saying that this sort of thought experiment is The Answer. It's not. It's just a tool to help us avoid losing sight of the forest. But if it were our only tool, I don't think we'd be able to get through the forest. It wouldn't be enough. Imagine if you had never been taught any design patterns. Your instincts wouldn't be as good. What I'm proposing here is that this thought experiment is quite effective when used in conjunction with the things we are already accustomed to using.