There seems to be this ever-present mantra in our programming culture to keep things as simple as possible. We hear it manifest in several different ways:

• KISS (keep it simple stupid)
• YAGNI (You ain't gonna to need it)
• Don't over-engineer
• Avoid "accidental complexity"
• Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live.
• Code for readability.
• etc

These are good, solid piece of advice, but I worry that some of us (me included) may have been taking this rhetoric too far. What have we been sacrificing at the alter of "simplicity"? Are we avoiding powerful design patterns because they might make the code harder to read? Are we staying away from various tools and libraries because of their learning curve? Conversely, are we hanging on to tools or libraries that we have long outgrown because we are worried about the added complexity of a home-grown solution? Are we avoiding adding features that would really benefit the end-user, because it would require the team to do a complex task (such as building a DSL parser, implementing a technical specification, etc)? Perhaps you can see real value in applying certain philosophies like the hexagonal architecture, dependency injection, the CQRS patterns, railroad programming, etc, but what would the next set of maintainers think? Will they just rewrite it all to be simpler?

Many of these worries are justified to some degree, but that doesn't mean we should always limit ourselves to only picking the simplest options, because, well, that's pretty limiting. Instead, perhaps as a community we need to take a step or two away from the "keep everything simple" philosophy. Life is complex. Programs are complex. Your job is complex. That's ok.

So don't feel bad for introducing complexity into a codebase when the complexity is justified.

Be less judgemental when entering a new codebase. Everything is going to feel complex and abstracted in odd ways. Resist the impulse to rewrite it all, instead, start by walking a mile or two in the previous maintainers' shoes, coding in the fashion they intended you to code in. You might learn a thing or two.

Embrace complexity.

Embrace simplicity.

Balance.