Simple Is Not the Same as Small in Software Design
Original: Simple Is Not Small
Why This Matters
Clarifying the simplicity vs. smallness distinction directly impacts how engineers design maintainable, scalable software systems.
Software architect jyn argues that 'simple' and 'small' are distinct properties in software design. Using Unix pipeline vs. Clojure word-frequency examples, the post shows that small programs can still be tightly coupled, making modification harder than a more verbose but decoupled alternative.
The article opens by referencing a 9-month debugging ordeal, after which the author's recommendation to 'prioritize simplicity' felt unsatisfying. To clarify what simplicity actually means, the author compares two word-frequency programs: a classic Unix pipeline using cat, tr, sort, and uniq, versus an equivalent Clojure program using higher-order functions.
When a small requirement change is introduced—showing words in original file order rather than by frequency—the Clojure version adapts cleanly by storing an ordered sequence and a frequency map separately. The Unix pipeline, however, requires temp files, complex regex substitutions, multiple sorts, and joins, becoming significantly harder to modify.
Drawing on Rich Hickey's talk 'Simple Made Easy,' the author defines 'simple' etymologically as 'sim-plex' (one braid) versus 'com-plex' (multiple braids). The Unix pipeline is small (few lines) but complex in Hickey's sense—its components are tightly coupled through implicit interfaces like line-delimited text. The Clojure version is larger but more decoupled, making it easier to reason about and extend.
The key insight: smallness (fewer lines or components) is not equivalent to simplicity (low coupling). A program can be concise yet deeply coupled to its context, while a longer program with named intermediate values and clear data structures can be genuinely simpler to maintain and modify.