Design patterns, different approaches to current state of the art

This episode on Codurance Talks reviews design patterns and why they are important for every developer to know. This podcast features special guest, Hibai Unzueta, Full-stack engineer and founder of several projects, the last one being Lotu*.

Design patterns are a controversial topic, where there are very different opinions and approaches. During this podcast, the guests address this topic by talking about professional experiences and the debates that are generated around design patterns. While free coding is a satisfying endeavour, it's easy to reinvent the wheel and fall into the same mistakes of days gone by.

Hibai Unzueta, Full-stack engineer Javier Martinez Alcántara, Software Craftsman at Codurance and José Enrique Rodríguez Huerta Managing director at Codurance Spain, chat about that and share their thoughts and views. 

José Enrique Rodríguez Huerta: 

Hello, hello, hello and welcome to another episode of Codurance talks, the podcast where we talk about all things technology, software development and craftsmanship. I am José, JRHuerta on LinkedIn and Twitter and I'll be your host for today's session.

I'm joined today by two, let's say software engineers. On one side, we have Javier Martinez, who is a software craftsperson here at Codurance; and Hibai Unzueta, did I get that right Ibai? Who is tinkering at Lotu, an application for thinking.

And the topic for today is design patterns. This is something that usually comes up a lot. And recently, we've been doing a couple of meetups around certain aspects that we feel like every developer should know about. And design patterns are one of those. However, it's a very controversial topic. Because if you ask people, you know, should people know about these things, this is something that maybe you want to test in an interview, when you're recruiting. Or you know, some people say, I've learned a bunch of things, you know, from “The Gang of Four” book, but I've never really actually used that or, you know, it's something that hurts sometimes because people try to apply them and not really understand what it is about. So to get the ball rolling a little bit, let's start with setting the context, right? What do we mean by design patterns? Which of you wants to start?

Javier Martínez:
So let me continue Jose. Where as José mentioned, this is part of a series of talks and meetups in which we treat this theme, patterns, and we will treat architecture in September. For me, and in the context of the of our previous session, when we define a design pattern, as a way of solving a recurring problem that happened while we are developing, if we go to the main reference, “The gang of four” says there are some issues and problems and especially in the context of they can afford in the object oriented a paradigm. If you adopt one of these patterns, you will solve it in an elegant way, let's say, in an efficient way. Because these problems were happening in many places in experience of the outdoors, this generates a pattern basically, that you can apply now, or when you face the problem, and later on, because it's really likely that you you find this problem later on. Well, but this is a topic, no?.

Hibai Unzueta: 
I think my first experience with the Gang of Four patterns was actually some years ago, I was doing c++ development out of university, and I didn't know much about how to structure my code. So I had a colleague who pointed out that this book existed. So it was basically at that point where I started to get interested in patterns and, and it seemed like a very good idea at that point to me. I think I felt that I didn't know how to structure the code, I was feeling frustrated because I was new to the craftsmanship toy. I didn't have good heuristics. Sometimes I didn't know how to structure my code. So this was a great way to get started. So, I started applying pattern c++ code at that point.

Then later on, my career went to other places, I started to get into web development, started to get into JavaScript... I was doing more front end work. And I stopped referring to design patterns. In a way I started to get interested into functional programming as well. And, you know, over time, I, my feeling is that it's something very contextual to c++ a specific time, specific language, you know, working with an object oriented paradigm. So nowadays, I don't find myself using them. So when people mention them again, my feeling is that, well, thye have been useful for me to think about these, to learn about this, but, you know, they are not in my day to day programming life right now.

JRH:
So, for me this has been a bit of a love hate relationship, right? So because, as you said before, as part of that learning curve, the idea of understanding first, what it is that you're doing, and I feel books like The Game of Four, Enterprise patterns and so on, gives you a good foundation on how to solve certain things.

But then on the other side, once you're there, once you learn some of those, the problem that I see is that you start seeing patterns everywhere, right? And at least for me, it was a bit of a process learning not to use them as well, right? To some extent, it was like, this is the right way. So everywhere I saw something that will fit, I will try to do it there. And that's actually counterproductive, in my opinion, but a necessary step. If you really want to get a grasp of the concept properly.
JM
So did you feel it? Like, “Oh, I'm using patterns, I am using this pattern everywhere...”

JRH
I know, of course, it was not like that. It was more like, oh, here, this fits really well here, boom, and try to implement it. The problem came when, you know, the complexity of the thing had gone out of proportion, just because you started introducing a bunch of layers of abstraction that were not that necessary to begin with, right, sir? It was just a matter of, you know, making it over engineering, in a sense, in many cases. That's one problem that I found. The other problem was, you know, if someone comes in, and they don't know what you're referring to, and so on. Then increases the cognitive load for someone who's joining the project, to then have to understand it's not there, you can no longer see it just looking at the code. Oh, it's evident what this thing is doing when you have, you know, five layers of abstraction on top of things.

JM
This is interesting because it happens to me, you know, well, I am the least experienced here in this crew. So it happened to me that when I arrived at a PHP project, and also to a Java project, I saw the people using the patterns and many levels of abstractions. And I said, I mean, this is over engineering. So, there is a thin line, to me, and it takes time and expertise to distinguish when is proper engineering and where is over engineering. Or, you know, this feeling of “Well, I think you are applying too many patterns”, or maybe when someone new joins the project and does not have the knowledge about the pattern is like, “do we really need this?”. We have kind of… I mean, you and me Jose, with the builder we’re like, “do I really need a builder? I mean, I have really nice constructors in Python. Why? Explain to me why, no?”. And it's interesting, also, whether the paradigm that you mentioned, Ibai, that you were going away from an object oriented paradigm. For you, to get also, apart from the usage of patterns, or is more than experience?

HU
Yeah, so I think that there have been very good points here, like, one of them is that they have here, I think, of course when you introduce an abstraction, it's like a trade off, you basically are introducing some complexity, they're introducing some code that is not, it's not business code, it's something that is going to support the business code. So you are introducing something. So if you get a good value out of it, then that's great. But if you are introducing an abstraction, and you are only seeing the negative aspects of it, the complexity or the that you're not being explicit, you're hiding stuff behind this, these abstractions, then it's going to be cost for the readability of your code, the maintainability of your code. So over the years, I’ve, like, become more and more of a minimalist in the sense of, if I can avoid adding extra code, I do it, you know, every time I can, I can avoid that. Because when I am reading code from somebody else, I like that, I don't have to open like a million files. And that I can see what the code is trying to do, as fast as I can, because time is the most important thing for me. So I don't want to lose a lot of time. So, sometimes I think that you just get one of these patterns. And you repeat this same form that was done in the past by somebody else. And this is like, you're not really implementing the will, you're using an already proven solution. Okay, that's fine. That looks, that sounds fine. But you are, you know, writing this extra code over and over again. And I think that you can also reach the situation where you suddenly see the problem in a different way, and you solve it in a different way, and you solve it with desco. And you solve it with a simpler mental model. Or maybe you don't need this, these two patterns, you can just avoid them. And you can just get a better grasp of what the business is telling you to do, which in some cases could simplify the code. So I think that sometimes patterns can sort of, you know, standardise like patterns to progress in the language or problems in the match between what the code is doing and what the business is asking you to do. So it's like, this is the part that I'm not that comfortable with.

(....to be continued.. )

About Lotu*:

I’m tinkering with a new tool I call Lotu, a Basque word that means ‘to tie’. Lotu works like this: You create small bites of text or other media. Then you quickly tie them together in different ways, create conceptual connections that you grow over time. This way you can incrementally evolve your thought, bit by bit.

Hibai