Intentional Code - Minimalism in a World of Dogmatic Design
Why Does Everything Feel a Bit Broken?
Most software isn't failing because of one catastrophic bug. It's degrading under the weight of a thousand tiny, thoughtless decisions. The central theme of this talk is that we've become so focused on applying rigid rules, patterns, and "best practices" that we've forgotten the most important thing: communicating intent.
Organizing code by architectural type (/controllers, /models, /services) is like smashing up a classic car and sorting the parts into bins labeled "Wheels," "Seats," and "Windshield Wipers."
You've organized the pieces, but you've completely lost the "car-ness." The intent of the system is gone.
This talk was a plea to put design back into software by making every choice—from a folder name to a line of whitespace—an intentional act of communication.
Intentional Design
-
Software is Literature: The primary audience for your code is the next developer, not the compiler. Software is a constrained form of literature that communicates concepts from one programmer to another, which also happens to be executable by a machine. If the human-to-human communication fails, the system is brittle and hard to maintain.
-
Intentionality > Cleanliness: The dogma of "Clean Code" can be actively harmful. Applying rules without understanding their purpose often leads to more complexity, not less. A function isn't bad because it's "too long"; it's bad if its intent is unclear. Don't just follow rules; understand the trade-offs.
-
Fight Complexity, Not Symptoms: The enemy is complexity. A Philosophy of Software Design - John Ousterhout describes complexity as anything related to the structure of a system that makes it hard to understand or modify. The central challenge of software design is ensuring the solution's complexity is, at most, as complex as the problem it solves—and no greater.
-
Deep vs. Shallow Modules: The best abstractions are deep modules. They hide a large amount of functionality and complexity behind a very simple interface.
- Deep (Good): A simple
File.Open()call that hides the immense complexity of file systems, hardware drivers, and OS-level operations. - Shallow (Bad): An abstraction that doesn't hide much. The interface is almost as complex as the implementation, adding cognitive load for no benefit. This is the "pass-through method" problem.
- Deep (Good): A simple
Actionable Tests for Your Designs
Instead of rigid rules, ask these questions about your code and systems. They serve as tests for the quality of your design.
-
Could this be done with fewer moving parts? Every dependency, module, or system you add increases cognitive load and maintenance cost. Is the trade-off worth it? Often, a few dozen lines of self-contained code are less risky than a "free" package with a huge dependency tree and an unstable future.
-
Is this operable? Software that is hard to observe, deploy, manage, and automate slows the pace of change for everyone. This is a direct tax on innovation and safety. An elegant design that is impossible to run in production is a failed design.
-
Is it easy to change? The best software is the software that is easy to change. Since software lives for years, its ability to adapt is its most important quality.
-
Does the form reflect the function? At a micro-level, use visual cues (whitespace, code flow, naming) to guide the reader. Code with good "form" feels like poetry—it leads the eye and makes its rhythm and intent obvious. Poorly-formed code is a wall of text that forces the reader to parse every character, increasing the chance of misunderstanding.
An End to Absolutism
"Any design, when stretched to it's logical, absolute, extreme, becomes nonsense."
There are no silver bullets. The answer to almost every hard design question is "it depends." Our job as engineers is to understand the context, weigh the trade-offs, and make an intentional choice that reduces complexity and clearly communicates our intent to the next person.