Design Decisions as Moral Choices: Winner Was Right

What did Langdon Winner argue about artifacts and politics?

Winner argued that technologies are not neutral tools but embody specific forms of authority and power, and that design decisions inevitably include or exclude, enable or constrain, particular groups of people.

Winner’s most famous example is Robert Moses’s Long Island parkway overpasses, designed with clearances too low for public buses. The result: bus-dependent populations (predominantly low-income and Black communities) could not reach Jones Beach. The bridges did not announce a racial policy. They enacted one. The concrete itself was a political decision, permanent and silent.

The essay was published in 1980, the same year as Searle’s Chinese Room. Both have aged remarkably well. Winner’s thesis, once considered a provocative claim by a political scientist, is now the foundation of an entire field: Science and Technology Studies (STS). The evidence has only accumulated. Technologies are never neutral. They always embed values. The question is whose values, and whether the embedding was conscious.

How do software architecture decisions embed ethical commitments?

Every architecture decision determines who can access a system, how data flows between parties, what behaviors are possible or impossible, and whose needs are prioritized when resources are constrained.

I designed an API rate-limiting system in 2021. The system allowed 1,000 requests per minute per API key. A reasonable technical decision. But embedded in that decision were ethical commitments I did not examine at the time. Large enterprise customers with resources to distribute requests across multiple keys effectively had unlimited access. Small developers with a single key were constrained. The rate limit was “fair” in the sense that every key had the same limit. It was unfair in the sense that it systematically advantaged organizations with more resources.

This is Moses’s overpass in code. The rate limit did not announce a policy of privileging large customers. It enacted one. The architecture was the politics, whether or not I acknowledged it at the time.

I have since cataloged 7 categories of ethical commitments embedded in common architecture patterns:

• Authentication systems: Determine who is included and excluded. Requiring a phone number for 2FA excludes people without phones. Requiring a government ID for verification excludes undocumented populations.
• Data retention policies: Determine the power relationship between the platform and its users. Retaining data indefinitely empowers the platform. Allowing deletion empowers the user.
• Default settings: Determine the experience of the majority who never change them. Privacy-invasive defaults are an ethical choice disguised as a technical one.
• Performance optimization priorities: Determine whose experience is prioritized. Optimizing for fiber connections disadvantages mobile users in rural areas.
• Accessibility architecture: Determines who can use the product. Every inaccessible interface is an exclusion decision.
• Algorithmic ranking: Determines whose content, products, or applications are visible. Every ranking function embeds a theory of value.
• Error handling: Determines who bears the cost of system failures. Failing silently protects the system’s reputation at the expense of the user’s understanding.

“The things we call ‘technologies’ are ways of building order in our world.” — Langdon Winner, Do Artifacts Have Politics?, 1980

Why do architects fail to recognize their designs as moral choices?

Architects fail to see their moral agency because engineering culture frames technical decisions as value-neutral optimization problems, separating “how it works” from “who it affects.”

The separation is a fiction, but it is a powerful one. When I designed that rate limiter, I thought I was solving a technical problem: preventing API abuse. I was not thinking about access equity, small developer impact, or the distribution of power between large and small clients. The framing of the problem as “technical” concealed the ethics within it.

This concealment is systemic, not individual. Computer science curricula treat ethics as a separate course, if they include it at all. Architecture review meetings discuss scalability, reliability, and performance. They rarely discuss power, access, and equity. The tools we use (architecture decision records, technical design documents, RFC templates) have sections for trade-offs, alternatives, and risks. They do not have sections for ethical implications.

I added an “Ethical Implications” section to my team’s architecture decision record template in 2023. The first 3 months were awkward. Engineers wrote “N/A” or “no ethical implications.” By the sixth month, they were writing 2-3 paragraphs. Not because the ethics had appeared. They had always been there. The template just made them visible.

What does ethically conscious architecture look like in practice?

Ethically conscious architecture begins with asking “who does this design affect and how?” before asking “how do we build it?” and includes affected populations in the evaluation criteria.

• Stakeholder mapping: For every design decision, identify all affected parties, including those who cannot advocate for themselves in the design process (future users, users of competing products affected by market dynamics, communities whose data is used).
• Access auditing: Before shipping, ask: “Who cannot use this? Who is excluded by our authentication, our pricing, our performance assumptions, our language support, our accessibility decisions?” Document the exclusions explicitly.
• Power analysis: For every data flow, ask: “Who gains power from this flow and who loses it?” Data flowing from users to platform increases platform power. Data flowing from platform to users increases user power. The architecture determines the direction.
• Default ethics review: Every default setting should be reviewed for its ethical implications. The question is not “what is the best default for the business?” but “what is the default that respects the interests of the person who will never change it?”

How does this reshape the role of the architect?

If Winner is right, the architect is not merely a technical role but a political one: every system design is a distribution of power, and the architect is responsible for the distribution they create.

This is uncomfortable. Engineers prefer to think of themselves as builders, not politicians. But Winner’s argument is not that engineers should become politicians. It is that they already are, whether they acknowledge it or not. The choice is not between technical work and political work. The choice is between conscious political work and unconscious political work. The unconscious version is more dangerous because it operates without scrutiny.

I have begun treating every architecture review as an ethical review. Not by adding a separate meeting. By adding a single question to the existing one: “Whose lives does this design affect, and have we considered their interests?” The question takes 5 minutes. It has changed 3 major design decisions in the last year. One of those decisions, reworking an authentication flow to support users without smartphones, affected an estimated 12,000 potential users who would have been silently excluded.

Winner wrote “Do Artifacts Have Politics?” in 1980, before the internet, before smartphones, before cloud computing, before AI. His thesis has only become more urgent. The artifacts we build now mediate the lives of billions. Every API is a gate. Every database schema is a taxonomy of what matters. Every ranking algorithm is a theory of value. Langdon Winner was right: artifacts have politics. The architect who ignores this is not apolitical. They are simply unaware of the politics they are enacting. And unawareness is not innocence. It is negligence.