Why This Matters
This is an opinion essay arguing that the industry conflates "small" tools with "simple" ones. Using a word-frequency example implemented as a Unix pipeline versus a Clojure program, the author shows that small composable text-streaming tools become awkward the moment requirements shift slightly, while richer data structures adapt cleanly. The point matters because "keep it simple" is often invoked as a fix for the kind of multi-layer tooling complexity that produced a nine-month debugging saga in the author's own coverage pipeline.
Key Takeaways
- Simplicity is not the same as minimalism: a chain of tiny Unix utilities can be harder to reason about and modify than a longer program with named values and real data structures.
- The essay grew out of a talk on a coverage bug that took nine months to debug, where 'prioritize simplicity' felt like an unsatisfying answer to complex tooling.
- How a tool represents data, not how few buttons or lines it has, determines whether small requirement changes stay easy.
@notjack.space: UIs with too many buttons confuse and alarm me
@sixfold-origami.com: ah, this is the unix thing!
@notjack.space: no, because I want cross device sync to actually work
Do we need simplicity?
Recently, I gave a talk titled "Precise, consistent, and reliable code coverage". It's about a truly gnarly bug that took my company 9 months to debug. At the end, my friend Predrag asks:
How would you recommend that we think about building tools such that these epic debugging stories aren't as necessary?
and I answer him:
We need to prioritize simplicity. If you go back to my coverage pipeline, there are a lot of nodes in this diagram. [...] The tooling's complicated. We need to rethink how our computing works.
I'm not satisfied with that answer.
Unix pipelines are not simple
... continue reading
GoKawiil