Simplicity Rules

Despite all that has been written about simplicity - from the SOLID principles to refactoring to simplicity quotes - many of us still struggle to do the right thing. We're better informed than ever about what constitutes good code and yet we continue to create huge swathes of unnecessarily complex code.

But why is that so many developers find it so difficult to create clean, maintainable, simple code?

Some might blame the parents. And they may have a point, for many, it is our parents who nurture and instil strong work ethics and a desire to simply care. But I would argue - and I am basing this on years of teaching and mentoring hundreds of developers - that confidence and experience play a huge part in the quality of an individual's code.

Picture this. You have spent years immersed in the culture of one technology stack. You understand the tradeoffs and benefits of every decision and choices because you have spent spent long hours reading and writing enough code in that language or technology for things to become second-nature. You are at one with the tooling, the syntax, the culture, indeed every aspect of the language. An inability to express intent and create clean code is simply not an issue. Why should it be, you feel so on top of the technology that you're pretty much an expert(!)

And suddenly you are thrown into a whole new technology stack with its own set of rules, its own culture, its own preferred way of doing things. You can make decisions, but are they the right decisions? Maybe they are but are you absolutely sure and what gives you that certainty without experience? When the syntax of a language allows a problem to be solved in several ways, which approach should you take? Before you know it, you can quickly become paralysed with indecision and uncertainty, driven by a new found vulnerability.

(And let's face it, in an industry where knowledge and expertise is king, not many of us are very good at dealing with vulnerabililty. We should be, but that's for a different time.)

Moving to a new language throws everything on its head. You spend half your time fighting the syntax, learning new libraries and often programming by Stack Overflow. Eventually, and only after many many hours of hard labour, you reach a new level of learning and gain enough confidence to do the right thing.

This is what it's like to be a newbie. Experienced developers often forget this. It's the old Kata thing, you need to do something at least 5 times (with me, a lot more) to really understand what you are doing, to get below it's skin, to get it wired into your DNA, like those battle-hardened lessons from previous projects. It's only then that you can really start to express yourself clearly.

To be clear, I am not saying that lack of confidence or indeed experience is a reason for creating poor code. They are most definitely not. But I can see how folks can get consumed in a complexity of learning, and how their code might initially offend the eye of an experienced developer.

But one thing still holds true, no matter the context - you should still have enough sense to apply solid engineering principles to your code. They are universal after all. The rules of simplicity - short methods, short classes, minimal indentation, consistency, intention revealing names, etc - are non-negotiable. They should be wired into every developer from day one.

Or put another way. Simplicity rules.