Tony Hoare, 1980

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies; and the other way is to make it so complicated that there are no obvious deficiencies.”

Tony Hoare wrote or delivered these words in 1980 in “The Emperor's Old Clothes.” Hoare's Turing Award lecture reflected on programming-language design and the expensive consequences of complexity. He contrasted clarity with systems whose flaws hide inside their sophistication. The quotation emerged from a concrete argument about how computing should work. The date assigned to this NewsStreets series is a calendar placement, not a claim that the quotation originated on March 18. Restoring the source keeps the words connected to the problem, audience, and technical conditions that made them meaningful. It also shows which part of the argument belongs to Tony Hoare and which interpretations were added later as the technology spread into new settings.

Its central insight is operational rather than decorative. Simplicity makes reasoning, testing, maintenance, and accountability possible because important behavior remains visible. Teams can apply that insight by naming the outcome they want, identifying the people affected, and choosing evidence that would reveal whether the design actually helps. A memorable quotation is useful when it sharpens a decision: architecture, interface, governance, maintenance, or the allocation of power. It is less useful when it is used to borrow authority without examining the speaker's reasoning. In practice, the principle should change a review question, a test plan, or an ownership decision rather than merely decorate a presentation.

Important qualifications keep the idea from turning into dogma. Simple is not the same as small or featureless. A design can hide complexity in dependencies or force it onto users; genuine simplicity must be evaluated across the whole system. Technology operates inside organizations and communities, so performance on a narrow benchmark cannot settle every question. Responsible practice makes assumptions explicit, documents tradeoffs, invites criticism, and provides a way to correct harm. That discipline does not weaken innovation; it gives ambitious work a clearer relationship to evidence and a more honest account of who carries the risk. A careful reader should therefore ask what the quotation leaves outside its frame, which stakeholders are absent, and what contrary evidence would require a different conclusion.

Current systems have made the underlying question larger, not obsolete. Large software supply chains and safety-critical services make understandable architecture a security and reliability advantage. For individuals, the quote can guide the next choice without pretending to supply a complete formula. For organizations, it can prompt clearer goals, better measurements, and more accountable ownership. Its lasting value lies in translating an influential idea into careful practice: understand the source, test the claim, keep the limitations visible, and revise the system when real users or real conditions contradict the preferred story. The standard is not admiration for a famous technologist; it is whether the idea helps people build systems that are more understandable, dependable, useful, and worthy of trust.