AFS II: PLEASE stop invocating KISS and DRY..2026-07-31
AFS II: PLEASE stop invocating KISS and DRY<br>Published 2026-07-31T01:27:44Z<br>DanielThis is part of the AFS (Acronym Fatigue Series) I’m working on. If you haven’t, please read the introduction first to understand why I’m wary of acronyms here.
DRY = Don’t Repeat Yourself<br>KISS = Keep it simple[,] stupid (some add the comma some don’t)<br>Note: I like KISS in principle.
Ah yes. DRY and KISS. The ultimate hand-wavy acronyms invoked to ask for pedantic changes in pull requests. The acronyms I use to reassure myself that the refactor I am doing is necessary despite the tangled mess I am coding.<br>They are well meaning advice. They try to guide coders into better code. Generally smaller. More maintainable. But in reality maintainable code, more than subjective simplicity and non-repetition, requires careful thought and understanding. It requires empathy for the person that will have to read and work on the code you wrote, even if that’s yourself in a few months, because we all know you will not remember why you did something in a specific way 7 months ago.<br>Also Note: Here I’ll consider Initialisms and Acronyms interchangeably because I’m fatigued of both. Acronyms are when you pronounce the abbreviation as if it was a new word (NATO -> nay-toe, NASA -> nassa, scuba, laser, etc), and in Initialisms you spell each letter (DIY, FYI, BRB, etc). I didn’t know this until after I started this series. In Spanish, “acronimos” are a subset of “siglas”, so I’ve always been ignorant of their distinction and used them almost interchangeably.
Keep it simple stupid<br>Coined by Kelly Johnson as part of his philosophy of making easy to repair combat jets. It is not clear to me if it should have the comma or not (calling the counterpart stupid vs keeping stuff stupidly simple). Regardless, it was coined in a very specific context and for a specific reason: making jets easily repairable for an average mechanic under combat conditions.<br>In software one of the first main advocates of the KISS principle is the UNIX Philosophy. In this case the UNIX Philosophy encompassed multiple principles that some people summarized as the KISS principle. Again. Here the KISS principle isn’t the center of the UNIX Philosophy. It’s just a way to summarize their principles.<br>When KISS is randomly invoked in a PR or discussion, I don’t really know how to respond. It is such a broad acronym that it can mean anything. I mean I like simplicity too and in general I do agree with keeping things simple, but in what regard do we need to keep it simple? In UNIX for example it materializes in modularity and making simple tools that can then be composed into more complex tasks. It also materializes into the interface being just simple text. And that’s it.<br>But what does KISS mean when designing an API? Do we keep the implementation simple so that it can be easily maintainable? Do we keep the interface simple so it can be easily used? Do we keep the scope of each endpoint simple so they can be versatile and support any future use-case? Simple can mean anything.<br>Simplicity is a very subjective matter. “Simple” in Java is not the same as “simple” in Python. “Simple” in Golang is not the same as “simple” in Ruby. In Python it may be about reducing the amount of work required for a feature. In Golang it’s about keeping a minimalist featureset. In Java idk I haven’t used it. In Ruby, similar to Python, it’s about readability, minimizing human effort, but also about elegance. And in the they are all fine interpretations of simplicity.<br>So each language and programming paradigm carries its own culture. Not only in the structure of code but also the tooling for each language becomes an expression of the culture around it.<br>XML, SOAP, JSON, REST, Protobuf, GRPC: They all are a product of their language culture and time. KISS was probably thought of in some way or another for each one of these formats/protocols, with very different results. KISS is not a culture. KISS is timeless. Everyone likes simplicity. Period. The question is what is simplicity for you?<br>DRY is a mess<br>Roses are red<br>Violets are blue<br>I abstracted for DRY<br>And now my code is a mess for you<br>– Me
As I said, I like KISS in principle. But DRY on the other hand, I consider harmful.<br>I like repeating myself. I like letting the code grow until it begs for a refactor. I also like to write well thought abstractions when I’ve understood and worked on the problem for long enough. It’s rewarding, but it usually comes after an awful initial implementation. Be it a prototype, pre-existing code, or my own flawed code deployed to production.<br>DRY for the sake of DRY is awful. It’s an advice given to newcomers that don’t really have the experience to know that a bad abstraction is way...