https://eugeneyan.com/writing/simplicity/
utterances-bot opened this issue · comments
Simplicity is An Advantage but Sadly Complexity Sells Better
Pushing back on the cult of complexity.
Thank you for this awesome post. It addresses a topic I encounter very frequently but feel a little helpless about. The tragedy lays in that it takes education to appreciate simplicity (see Dijkstra’s quote above). This means that the ones appreciating simplicity will always be a minority. Maybe in an operational context it is easier to grasp if we look at the relationship between the number of lines of code a given product has vs. the number of service interruptions or issues it produces and/or put the lines of code in relation to the utility the product produces.
"Instead of focusing on the complexity of the solution, we should focus on the complexity of the problem."
Mmm isn't this a typo?
Why do you think so?
complexity sells better
Perhaps it's partly our responsibility as engineers to sell our solutions, even adding a veneer of accidental complexity to some solutions as needed while maintaining a simple core.
At least having made the sale, we then have the opportunity to gradually educate customers and guide them to simpler designs in future.
I love this article, thank you so much for writing this! 🤩
There is only one thing here I'd like to discuss and elaborate on for a bit:
It [rewarding complexity] also encourages the “not invented here” mindset where people prefer to build from scratch and shun reusing existing components even though it saves time and effort. This wastes time and resources and often leads to poorer outcomes.
I don't feel like this is quite nuanced enough, and I believe there is more to discuss here.
In my experience, the "not invented here" mindset has an equally powerful opposite bias, where people automatically prefer to reuse existing components because they already know them, it's easier relative to their individual experience, and it saves their time and effort - however, if those existing components are very complex, this can end up wasting time and resources and leading to poorer outcomes as compared to building something simpler.
If we want to emphasize simplicity, when no simple option is available, sometimes we have to invent something new.
And don't get me wrong, I'm not ignorant of the fact that this often goes wrong - we often think something could be simpler, and we end up building something that's only different but just as complex as the thing we were trying to simplify. Some problems are inherently complex, requiring essential complexity that we can't actually get rid of in practice.
My favorite "bad" example is ORMs - we keep building more, they all start out simple, and then explode in complexity. The object/relational impedance mismatch is a well documented fact, and the idea itself is inherently complex. (and if you're thinking of an ORM right now that managed to stay simple, it's probably not an ORM, and more likely just a query builder or data mapper, etc.)
By contrast, a "good/bad" example is how the PSR-6 cache API was followed by the much simpler PSR-16 cache API, which reduced the complexity and number of concepts, making the API much smaller and less opinionated - you can write a PSR-6 adapter for a PSR-16 implementation (and, for that matter, vice-versa) demonstrating the fact that none of the complexity that was removed by PSR-16 was essential to begin with.
There are many libraries and frameworks out there that go far beyond dealing with essential complexity - they often do so in the name of "developer experience", a rather lofty idea, and aptly named "developer" rather than "development", highlighting the fact that this value is often completely subjective and relative to individual experience; as opposed to real simplicity, which is an objective and measurable thing. (lines of code, number of public methods, amount of coupling, etc.)
These libraries can sometimes grow to 10x their original size over the cause of a few years - often with major breaking changes every 6-12 months and, ironically, this is perceived as "good" as well, but often indicates a complete failure to keep the scope of a package contained, focused, and small. In fact, libraries that don't exhibit growth are often perceived as being "dead", and people are often motivated to move on to packages that are more "active", another clear symptom of complexity bias.
Sometimes we have to build something new to avoid this sprawling complexity - if we can make things truly simpler, if we can bolt down the requirements and avoid sprawling growth, this can be a good thing, and sometimes it's the only way to control the infectious complexity we often inherit from "over active" libraries and frameworks.
It's a nuanced topic and we need to be careful not to feed either of these opposing biases. 🙂
Hey Rasmus, thank you for taking the effort to share your perspective, and in such depth too!
💯 that "not invented here" taken too far has bad side-effects too.
May I add your comment, in full, within the article please? I feel like it adds the balance that it's lacking now. Will provide full attribution to you off course, and your comment will stay in the comments.
@eugeneyan feel free to quote/copy/modify to your hearts content 😄