In a recent post, inspired by an interview with Kirk Pepperdine, I’ve presented my view about the notions of “dumb” and “clever” code. Kirk’s reaction to it prompted me to think about the topic once more.
While I’m perfectly aware that in it’s origin, the notion of “dumb code” has been meant as synonym for “simple code”, and “clever code” as a synonym for “unnecessarily complex code”, I still see issues with the adopted terminology.
For one thing, even if “dumb” really meant “simple”, there is still no common understanding what “simple” actually is. While some, like me, believe that the simplicity to pursuit is the simplicity of the end result, many confuse simplicity with obviousness. This is what I meant by the difference between simplicity of an action outcome versus the simplicity of the action itself. Doing the next thing that comes to my mind is a simple and quick action. But does this behavior pattern necessarily yield a simple system? I’d say: No.
Further, even if everybody agreed on the goal that it is the outcome to keep simple, we still have the issue that simplicity is “in the eye of the beholder”. For example, it is often a paradigm shift that leads to brilliantly simple solutions. But a paradigm shift is usually not very obvious. I’d even say, it is extremely unobvious. Seeing it requires a level of skill and understanding far beyond novice. Consequently, the “intention” behind code that resulted from such a paradigm shift may not be obvious to novice programmers. They will usually complain that the code is “unnecessarily complex”, even though it may be by far leaner than what they would have done.1
Finally, a subtle but far reaching effect comes into play when changing the language from “simple” to “dumb”. It reverses the common connotations of dumb and clever (by valuing dumb over clever, contrary to “common sense”). Because this is counter-intuitive to someone with no background knowledge, it would require an explanation to avoid misunderstandings. However, in its every-day use, an explanation is rarely given.
In the end, what remains is a slogan, taken out of context, and left to interpretations – interpretations that are very well made on behalf of common sense about the concepts of dumb and clever. Combined with novices pleads for “novice simplicity“, and a constant pressure in software projects to reduce cost, it is only natural if the notions of “dumb code” and “clever code” experienced a different connotation by the wider public than originally meant to.
But that’s what usually happens when a rigid value judgment is based on a diffuse concept.
Last but not least, I’d like to conclude with this thought:
Even if none of the above issues were true, I still wouldn’t want to call any of my code “dumb” no matter what. How can I possibly be proud of “dumb code”? I couldn’t!
The language we choose acts in mysterious ways on our psychology, so I prefer to watch mine.
- Psychology Of IT Language
- About Real And Fake Projects
- The Costs Of Not Doing Something Else
- Evolution And Project Management
- Of Boiling Frogs And Chinese Whispers
- Show some code that follows some good OO patterns to someone used at procedural programming style to see what I mean. Or have a look at the open source PHP scene: A remarkable portion of PHP code does not involve object orientation. It is also a ground where I constantly find violations of the DRY principle. I don’t thing such code is overly simple. At the same time, most open source PHP projects (and most non-PHP projects, for that matter) claim simplicity as one of their main qualities – as exemplified by the ever-recurring slogan “simple, but powerful”. [↩]