"What keeps a customer coming back to your product?" he asked.

"The user experience," I said.

He went on to tell me that, no, it's not the user experience but rather the latency at which messages are passed around the framework, the reliability of the implementation under the hood, the consistency of behavior of all of the complex parts behind the user interface. The buttons and graphics and whatnot make things look nice, but they mean nothing if the software behind the scenes is unreliable.

"Yeah, you're right," I said. I didn't bother debating or explaining my position, that I consider all of that to be part of the user experience.

That moment reminded me that the larger a project gets, the more likely we are to find pockets, if not entire organizations, of developers who contribute important features to a product without identifying with end users or considering the end-user experience. We are fortunate if someone else does this on their behalf or if they develop against requirements derived from specifying an agreeable user experience. We are less fortunate if this is left to some last-mile integration test, where the best signal we get is, "the more times I click the button, the slower things get, and one time it didn't seem to do anything at all, but then the next time it did."

We can remove fortune from the equation entirely if we make sure all contributors keep the end user in mind. Depending on what you're building, one easy way to do this is to have contributors use what you're building. At first it will be entirely unusable, but as time and features progress, it will become barely usable, and then from there it stands a chance of becoming great. Feedback loops are tight, and the same people who build the thing are coming up with great ideas--"if I was going to use this thing so often, it would be great if it did [...], and it's kind of annoying that it's always doing [...], so we should fix that." If you're building something you can't immediately use individually, regularly, it still goes a long way to at least be able to tell a story about how what you're contributing is connected to the end-user experience. "Our API can't throw exceptions because our exception runtime allocates memory non-deterministically, can also terminate the process if it runs out of memory, and runs the risk of terminating callers' processes if anything we raise goes unhandled, and our application is a daemon providing a stream of the forward-facing camera's frames to the rest of the stack in a safety-critical context," encourages user-experience investment and innovation far more than, "our API cannot throw exceptions."

A bleak situation in my mind is when a group of developers need to consult some oracle to get feedback on the user experience. These oracles are typically UX or Product teams. An oracle is thought to deliver some message or decree faithfully. It's not that we can't trust UX and Product. It's just that the mere presence of these teams often indicates segregation between the end users and everyone else building the product, and segregation leads to telephone. The way out of this downward spiral is having the people who build the thing use the thing or at least having them talk with people who use the thing.

When I said, "user experience," to the gentleman, I think he immediately imagined a team by the same name. But I'm not talking about the team. I'm talking about the phenomenon.