How Program Design Choices Affect People

Code doesn't have opinions the way people do, but it does have assumptions baked in by whoever wrote it. Every field you declare, every limit you set, every default value you pick is a decision about what the 'normal' user looks like. A single line inside one method — a String capped at some length, a boolean defaulted to false, a numeric field that can't go negative — doesn't stay contained. It runs the same way for every single person who touches that program, so whatever assumption is baked into that line gets applied to all of them, whether or not it fits.

Take a signup form with a name field declared as a String with a 20-character limit. Most names fit fine, so the programmer who tested it with their own name saw no problem. But plenty of real legal names — names with multiple parts, names from naming traditions the programmer never considered — run longer than 20 characters. Those users get truncated or rejected, not because anyone decided to exclude them, but because nobody decided to include them either. The absence of a decision is still a decision once the code runs.

This connects directly to why classes bundle fields as private and expose only controlled access through methods: encapsulation controls who can change what, but it says nothing about whether the limits and defaults you chose are the right ones. A class with airtight encapsulation can still be badly designed for its users. That's why thinking about who will actually use a program — people the designer may never meet, with needs the designer never pictured — has to happen alongside the technical design, not after it.