Configuration Is Not Customization
There's a distinction that most software blurs, and the blurring causes real problems.
Configuration is technical. It determines how a system operates — which database it connects to, how many threads it spawns, what port it listens on. These are decisions about mechanics. Get them right and the system works. Get them wrong and it doesn't.
Customization is personal. It determines how a system presents itself — the theme, the layout, the default view, which notifications you receive. These are decisions about experience. Get them right and the system feels good. Get them wrong and it feels hostile.
Both involve settings. Both involve choices. But they serve completely different purposes, and treating them the same way creates problems that neither can solve.
Configuration requires expertise. You need to understand the system to configure it correctly. Database connection pool size, cache TTL, timeout thresholds — these aren't preferences. They're engineering decisions with performance implications. A bad configuration doesn't just feel wrong. It breaks things.
Customization requires no expertise. You just need to know what you like. Dark mode or light mode. Sidebar on the left or the right. Weekly summary or daily digest. These are preferences, not engineering decisions. A bad customization doesn't break anything. It just annoys you until you change it.
The problem starts when software puts both in the same place.
Open any sufficiently complex application's settings page and you'll find them jumbled together. "Theme" sits next to "API timeout." "Notification preferences" sits next to "Log verbosity." "Display name" sits next to "TLS certificate path."
This isn't just a UX problem, though it is that. It's a trust problem.
When you put configuration and customization in the same interface, you're telling the user that changing the font size and changing the database driver are the same kind of decision. They're not. One is reversible, consequence-free, and personal. The other can bring down production.
The user who confidently changes their theme might hesitate before changing their notification preferences, because the settings page has taught them that settings are dangerous. Or worse — the user who casually changes their notification preferences might casually change the connection pool size, because the settings page has taught them that settings are harmless.
The best systems I've used separate these completely.
Customization lives in the product. It's accessible, friendly, and encourages exploration. Change it. Try things. If you don't like it, change it back. Zero risk, immediate feedback.
Configuration lives in files, environment variables, or deployment tools. It's deliberate, versioned, and reviewed. You don't stumble into it. You go looking for it, and when you find it, the format itself — YAML, TOML, environment variables — signals that you're making a technical decision.
This separation protects both audiences. The casual user never sees the dangerous settings. The engineer never has to navigate past theme pickers to find the connection string.
There's a deeper issue here about who the audience is.
Configuration is for the person running the system. The operator. The admin. They care about reliability, performance, and security. They want sensible defaults and clear documentation about what each setting does and what happens when you change it.
Customization is for the person using the system. The end user. They care about how the tool fits into their workflow. They want it to feel like theirs — not because they configured the thread pool, but because the colors, layout, and behavior match their preferences.
These are different people with different needs. When you serve them through the same interface, you serve neither well. The operator gets a settings page cluttered with cosmetic options. The user gets a settings page that's intimidating because it's full of technical parameters they don't understand.
This maps to a broader principle: not all choices are the same kind of choice.
Some choices are reversible and low-stakes. Try it, see if you like it, change it if you don't. Customization lives here. The cost of a bad decision is mild annoyance, and the fix is one click away.
Some choices are irreversible or high-stakes. Think carefully, understand the implications, test in a safe environment first. Configuration lives here. The cost of a bad decision ranges from degraded performance to data loss.
Good systems make the stakes obvious. They don't hide dangerous choices behind the same interface as safe ones. They don't require the same level of deliberation for "which color scheme" as for "which encryption algorithm."
When I build tools, I try to eliminate configuration entirely and make customization unnecessary.
brain.py has no configuration file. The database path, the table schema, the search algorithm — these are decisions I made once, correctly, and encoded in the code. There's nothing to configure because there are no meaningful alternatives for the use case.
There's no customization either, because the tool has no visual interface. It takes input. It produces output. The output format is the only thing you might want to vary, and that's handled by a flag (--json), not a settings page.
This isn't always possible. Complex systems genuinely need configuration, and user-facing products genuinely need customization. But the reflex should be toward fewer choices, not more. Every setting — configuration or customization — is an admission that you couldn't find a single right answer. Sometimes that's honest. Often it's lazy.
The test is simple: if a user changes this setting and something breaks, you mixed up configuration and customization.
Customization should be safe by construction. There is no wrong answer for dark mode. There is no dangerous notification preference. If changing a "preference" can degrade the system, it's not a preference — it's a configuration parameter wearing a friendly label.
Keep them separate. Make the safe things feel safe. Make the dangerous things feel deliberate. And whenever possible, make the right decision so nobody has to make it at all.