When I originally had an idea for this series, yes it will be a number of posts, I had in mind the title: “Principles that govern our code”. Then, through some thinking and discussions that followed from that original thought that had even been in draft for some years already, I had a bit of a mind shift. Shift in the sense of, should I add another writing to the already polluted ecosystem or for the sake of personal growth, challenge it a bit? Or was it simply for the clickbait title, who knows, I am personally getting lost these days in discussions around these subjects.

When I talk about principles, or currently how I view them as dogmas, I am referring here to things such as design principles, patterns, etc. Even if you’re starting in this field, you probably already stumbled upon some of them. They have cute names; some can be classified as government agencies. Where the acronym says something, while the reality behind it is often misunderstood and rules the code from the shadows. Shadows of old, where we stick to things that may or may even not, work in the original context. But then came a book about it, some conference talks and somehow it became a dogma. Something to live by. Where you will be persecuted for not knowing about it or refusing to apply it where it made no sense.

This is also, in my opinion, making it even harder to start learning programming. We’re bombarded and yelled at when not following those, while the focus should be first going over the hurdle of solving some basic problems. And then gradually learning how to work in teams and on enterprise-level projects. Somehow it is expected that someone just starting in the industry knows all of these. My road started differently and I still remember the adrenaline rush just having the first “Hello world” printout on the screen. My code was a mess during those times, while also developing a need to learn more. As it, in my opinion, should be. When I passed the barrier of just being able to solve these simple problems and making simple applications, I ventured on the road of learning about how to structure my code. How to make it easier to maintain. Testable. All these things were a linear progression in acquiring the knowledge I didn’t have. Later on, I went to university where I started learning about concepts different languages, and higher/lower level topics, all the way to the assembly. There was a, somewhat natural, progression. While nowadays due lack of developers you can see bootcamps and such popping up. With unrealistic expectations. Where they try to cram this process of N-years in a matter of months.

Don’t get me wrong, I am not saying the university is a good way to learn to program. Far from it, in some cases. It is a good place to meet future colleagues and maybe dive into topics that you never thought of. While on the other hand, most of the courses are stuck in the past way of thinking. Based on the books that were written by the people who probably need to keep up with times. While there were some good ones, most of them were teaching concepts that were not being used in practical application for long periods of time. Or maybe, as academics, they should have been the ones challenging the “ways of old”. This is hopefully slowly changing, in response to the growing number of online courses and boot camps. They can’t be stuck anymore as before, so there is some movement on that front. And with the rise of AI, education will need to incorporate more on how to work well in teams and stuff like problem-solving, critical thinking, and more creative side that AI struggles with.

So where I am going with all this and what does it all have to do with principles and dogmas? In my opinion, these are the enablers of them. They preach and enforce their existence. While at the same time, they suppress any critical thinking. Comform or perish. This is an interesting thing in the times when we claim enlightenment and progress beyond what we could have ever imagined. That is why I wish to ask a simple question. At least in the context of the topic at hand.

How far are we willing to go before we realize our principles/dogmas should be applied based on facts and common sense?

Not every code needs to be DRY. I saw what can happen when this gets applied in extremes, where the complexity and amount of code to support it defies belief. Or an even better acronym I heard for a similar definition. DIE. Duplication is Evil. Seriously? I mean, common. Do understand people that who write books and such, need something catchy to stick with the reader, but this is bordering insanity. Sometimes YAGNI, when put in context is an obstacle for later on. Where a small abstraction at the start would save months of refactoring later on. And the list can go on. And it will, with every blog in the series touching one of these dogmas. With my view on when and how they should be applied, not just let us start with them and deal with the consequences as they come. I don’t think these principles are bad, they have their reasons. But when you follow them as dogmas, then it is a hurdle. Like everything in our world, it depends.

I really don’t like the word depends as it means that any answer is a good one. Anything goes, in translation. While the opposite is usually true, we just don’t have enough input to produce a smaller subset than the entirety of our knowledge. This is also why I started making this series and not just a single blog. As it would be too much, with the pros/cons of every principle out there. I will try, with my limited knowledge, to illustrate my views and how they apply to different problems. As already in the previous paragraph, there is some common sense when it comes to doing anything in our code. Which we gather through experience and seeing when we should start with a bit of complexity. And when complexity is just an obstacle. All of this also has a lot of different contexts, hopefully, which I can also provide different takes on. Meaning, things like architecture, type of project, team, etc.

My point is not to shun all the knowledge we gathered. I am trying to impose questions and thinking processes when this knowledge should be applied. To move back to principles as the term that will lead to better software and make team work more efficiently together. So let us start with the first one in the upcoming blog, keeping our code DRY.

Until next time, keep asking questions and challenging the established way of thinking.

Posts in series:

  1. Dogmas that govern our code, DRY
  2. Dogmas that govern our code, YAGNI
  3. Dogmas that govern our code, Test everything