Why Using the Word “User” Can Sabotage Your Software Design

When you realize that the lightweight, simple assumptions you made at the start of a project were completely wrong after six months, you’ve already invested far more effort than expected; using the right approach from the beginning would have avoided this.

One common mistake is the overuse of the word User , which has two fundamental problems: it rarely describes the requirement accurately and it introduces a basic design security flaw.

The concept of a User is vague, and using more precise terms almost always yields better results.

You Don't Use Users

Initially, no software system truly has a “User”. At first glance “User” seems fine, but the business logic is usually far more complex.

1. Airline reservation system has no User

Example requirements for an airline reservation system:

Passengers can view booking information using a reservation code.

Buyers can modify bookings by providing the last four digits of a credit‑card number.

Travel agencies can view and modify their bookings.

Airline check‑in staff can view and modify bookings based on role and airline, requiring passenger identity information.

Basic human‑related concepts here are “passenger”, “agent” (the website can be seen as an agent), and “buyer”. The term User is unnecessary, and many requests must include passenger and agent credentials rather than a generic User credential.

2. Unix has no User

Unix (now often called POSIX) has users who can log in and run code, but the reality is more nuanced.

People who log in via terminal or GUI.

System services such as mail or web servers that run under a User account (e.g., nginx runs as the httpd user).

Multiple people sharing a single admin account for SSH (e.g., the default “ubuntu” account on Amazon Ubuntu VMs).

The root identity, distinct from the others.

These four concepts are almost different, yet POSIX treats them all as Users. Treating them uniformly leads to many security problems, such as the inability to restrict login to only specific individuals.

3. SaaS providers have no User

Jeremy Green recently tweeted about user models in SaaS, noting that SaaS services are almost always:

A person in an organization paying for the service.

One or more people jointly using the service.

If you start by modeling these people as a single User, you’ll end up in a painful situation: you cannot build a team model, you cannot support multi‑payer scenarios, and you’ll have to refactor the system later. The lesson is that you really need only two concepts: a team (to organize relationships and payments) and members (the actual people using the service).

User is a security problem

The word User not only creates business‑logic confusion but also introduces a series of security issues by merging two distinct concepts:

An individual person.

Their representation in software.

Consider a malicious website that causes a browser memory overflow, allowing the remote site to upload your files. The browser runs under your system account, which is also a User. Because the browser’s actions are attributed to your User, the system thinks you intended the upload—a classic Confused Deputy problem caused by conflating the human User with the system User.

The value of early design

Spending less effort to solve the same problems is key to being a high‑productivity programmer. Organizing your software around vague concepts like User will waste massive time and energy fixing future issues. Jumping straight into coding appears productive but is the opposite.

Next time you start a new software project, spend a few hours upfront defining your terminology and concepts. You may never be perfect, but you’ll be far better, and future you will thank you for the preventive work.

Source: 翻译自众成翻译，翻译：有马 Original article: www.zcfy.cc/article/never-use-the-word-user-in-your-code