Simple is hard

In my early career in sales, we had an unspoken rule: the word "sophisticated" was banned from our sales pitches. The reason was straightforward—people are naturally wary of complexity.

The idea of "simple is hard" isn't new; it's a concept that many leaders and thinkers have endorsed. If you search for it on Google, many people have coined it before, I even saw a blog on the domain simpleishard.tech some time ago. The idea is you have to work hard to keep things simple a pivotal philosophy in user experience/UX design. A long time ago, I read the book Don't Make Me Think by Steve Krug's and the general idea is that a well-designed website or application should be so intuitive that users shouldn't have to think or puzzle over how to navigate it. By focusing on practical usability principles like simplicity, clarity, and common conventions, Krug argues that designers can create more user-friendly interfaces that require minimal cognitive load from the end-users. This resonates hard with the way I believe we should do engineering, and the way we should treat our code bases. Cognitive load is not necessarily new neither when talking about code.

UX Mindset in Coding: Refactoring

So here's the thing: we humans have this weird knack for making things harder than they need to be. Give us a simple task, and we'll find a way to add all sorts of twists and turns. We end up with something way more complicated than it needs to be on our first draft. At this point, you are presented with two options:

The latter takes more time, obviously, simply because of the extra time for improving code. The Red, Green, Refactor cycle acknowledge this and insist on allocating improvement to code that already works.

red_green_refacor source

The challenge of writing simple code in engineering is, to me, similar to adapting a UX mindset. It's not just about what the code does, but also about how easier it will be for the next programmer to understand it. Refactoring is basically UX for code. A famous quote from engineer John F. Wood in the year 1991:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability.

Applying YAGNI (You Ain't Gonna Need It) discipline, in that sense, is a must for survival . Don't add code you think you'll need in the future; just write what you need right now, and nothing else.

Factorisation & refactoring

While researching on refactoring, it appears the actual origin of the word is not clear, or at least there is no real consensus for it. I would not be surprised if this comes from factorisation in algebra, point covered by Martin Fowler. There is a real connection between the two concepts: they're both about simplification.

Here is an example of factorisation.

If we refactor the numerator we get to see how this equation can be simplified.

Both equations are exactly the same but one is much easier to read and understand at first glance. We just needed to put a mental effort to get to the simplification, and that extra effort is truly what makes simple a hard thing to do.

Bill gates famously said:

I choose a lazy person to do a hard job because a lazy person will find an easy way to do it.

I won't necessarily qualify myself as lazy but I definitely pick the solutions that will give me or my team less "future" work.

In conclusion, embracing simplicity in engineering, much like in UX design, is a challenging but vital practice. It requires a thoughtful balance of discipline and foresight, ensuring our solutions are not only effective but also intuitive and maintainable for those who follow in our footsteps.