Simplicity

I have been thinking, lately, about what my -not so hypothetical- list of “absolutely essential principles regarding technical implementations around DevOps topics” would look like. I quickly thought of a few items, and did not want to make the list longer than 5-6. Then I wondered, how would I sort them, by importance? Is there any element, any practice, any mentality that is absolutely crucial to every design, right from the start, and still useful years after?

Of course, the thing we build must do its job. Of course. That goes without saying. But “to do its job” is not the topic I kept coming back to, during this mental exercise. It was, however, simplicity.

This is an argument in favor of simplicity. Simplicity, which is so easily forgotten in designs, so quickly drowned in lines. Simplicity, which is so frustratingly sought after when debugging, so beloved and admired when reviewed.

If we were religious about it, Simplicity would be a goddess. Maybe we would perform rituals to her, like tech-priests from Warhammer 40k, calling for her knowledge and help, and worshipping her every manifestation in design and code.

“Looks Good To Me” would become “Looks Good To Her”. We would greatly praise those who came up with ingenious, coherent designs, those who created PRs with clean, documented and functional code. We would celebrate our heroes, award them prizes, gold and honorary positions. We would listen to them, promote them, encourage them to keep on the same path, share their wisdom with everyone else. Educate us in their masterful ways.

But also, we would condemn and criticize those who did not choose the simple way. Those who added bugs (unknowingly). Those who did not finish the implementation, those who left it (unknowingly) broken. We would make those follow the best of us, shadow them, make them work together, until they learn to recognize their own mistakes.

And also, we would punish those who knowingly introduced bugs, those who knowingly left the implementation half-way, those who purposefully made anything more complex that it needed to be. Those, we should seek to ostracize from our community. They can not be saved, nobody will want to work with them, and most surely there is not enough time and desire to keep fixing the mess of anything they touch.

Simplicity is the foundation upon which we build everything else, but also the columns which keep the whole structure standing and allow for anyone to bring down and rebuild walls when required. And it is the lanterna on the top of our structure, that shines to the whole town, and beyond.

What is DRY if not a manifestation of Simplicity? Write a function, a module that will do the job many times over, whenever called.

What is SRP if not a jewel in Simplicity’s crown? Create a piece of code, a tool that will do the thing you want, do it well, and do only it.

And what is Premature Optimization if not heresy? Trying to implement everything at once, thinking yourself as a mastermind who can go against Simplicity? You will suffer, as will those around you. Endlessly, suffer. And, you will see what you have built come down, eventually. Falling upon itself, when someone, or even yourself, tears down a column you had written off as a non-load-bearing wall. And you will lose colleagues, when someone tries to go into the basement in the foundation and gets lost in the labyrinth you put there. If you are not an evil king, stubborn on the road to hubris, nor a megalomaniac architect, dreaming about your grand designs every night, then why build as one?

Take it easy, scholar. Do it in increments. Start small, start simple. Get feedback, get reviews. Iterate, always with simplicity in mind. Do not tie together things that should be left apart, but do provide an interface for those that should communicate.

Create and find your group of like-minded individuals. Build your community as an altar to Simplicity. Observe, think, discuss, design, implement, review. Repeat.