Semi-Solid Principles

Hey, Ben.

Hi, Matt.

How are you doing?

I'm doing great.

So we don't usually try and make these things in any way timely. We just talk about stuff that is, you know, true forever, but a friend ex colleague of ours recently posted something rather inflammatory about something, which is dear to the hearts of many. And my sodding dog is making such a noise behind me, we're going to carry on. I'm afraid I am dog, I am puppy sitting and so.

We have a guest on this week's podcast.

Special guest is, Is, uh, yeah. Is Monty who is a 12 week old, black lab and is currently in the pen behind me. Anyway, the SOLID principles are things that are sort of taken mostly as truth by a lot of people. I will see it in code reviews all the time. People say, Hey, this doesn't conform to solid. And Dan recently posted a blog entry, the sort of taking it down. And we figured we should talk about that. Now. I'll be totally honest with you. I've been a software engineer for 20 ish years and I don't really know what the SOLID principles are. You know, I, I just kind of people say about them and I'm like, Oh yeah, sure. I'll refactor my code in the way that you said. So I'm going to look to you to teach me first of all, what the, what, what they are. And then maybe we can talk about some of the things Dan raised and maybe you've, I know you'll have opinions because, because you're Ben.

I have opinions. This is, this is what I, this is my gig is I have opinions.

What are solid?

So yeah, so let's talk about the SOLID principles. Um, so just obviously all of our listeners can Google SOLID principles and.

All of our listener.

All of our listener can, can Google the SOLID principles, but just for those who are, you know, in mid podcast and don't want to be bothered, uh, they are, uh, S stands for single responsibility principle O stands for the open-close principle.

That's the most confusingly named one for me.

Yes. We'll talk about all of these. We're going to talk about these principles.

You go through them first.

L stands for the Liskov substitution principle named for Barbara Liskov, who, who presented that in a presentation in the eighties, I think is when she proposed that, uh, I stands for the interface segregation principle D stands for the dependency inversion principle. So those are the SOLID principles.

No wonder. I mean, I can't imagine why I'd never sort of committed that to memory. It seems so obvious in retrospect.

Right? Of course. Um, so yeah, so the, and the controversy is particularly interesting for me. Uh, I never really had the opportunity to work directly with Dan. He was sort of around and about at prev prev co for me, you know, I ran into him a few times and had some conversations with him. It's not like we ever sat down and wrote code together, but, you know, I sort of talked to him and, uh, it was very interested to hear a lot of his ideas. I did actually work a little bit with Bob Martin when I was at, um, Object Mentor back in the 2008 ish timeframe. And, you know, as we had the guest on before James, James Grenning also worked with him at Object Mentor. And when I was at Object Mentor, the SOLID principles were definitely part of the curriculum, I guess I would say that we would, that they would teach in their training sessions.

Bob would be another, yeah.

Yeah, yeah. Um, so I have a little bit of, of, you know, I can see both sides. I've, I've, I've had direct contact with both sides of this war. Um,

War is....that's a strong phrasing. Let's not, let's not phrase it as that.

Yeah. I know I'm being, I'm being a little funny here it's I don't really think that there's actually that much of a controversy here. Right. Um, but, um, I can definitely, I feel like I can argue both sides of this argument. Um, and I have my own sort of take, which is not really in the middle. It's sort of like a third thing off to the side. Um, so we can maybe interesting throw that into the mix and evaluate that on it's merits.

Interesting. But let's, let's talk at least briefly let's do like a one paragraph paragraphs so that I at least. I understand what each of those. S O L I D things. S, the first one was, was what? It was.

Single Responsibility principle.

Okay. That one, I recall something, when I was working at Google, it was, it was sort of boiled down to me and transmitted to me into a, or rather it stuck in my memory. And maybe you can tell me if I'm actually right. This one is like, if you're writing the description of a class and you use the word "and" then maybe just maybe that class is doing too much. So you want to like break it into two classes or something like that. And I, in my mind, I've combined those with the S of solid, right. That's what I think of when people say single responsibility. I mean, like, yeah, if I can explain what this is doing is a price class. It holds a price. Right. There you go. I think that's probably it, you know, if it's the, uh, um, I, I'm not, I'm not gonna come up with any good ideas, but if I have to put the word and somewhere when I'm trying to describe it

Price and Quantity, right.

Well, yeah, you see, that's where it gets tricky. Right.

You just call that you call that an order, or you call that a, like, there's another name for that, right.

It's not true. So yeah, you've picked, that's a perfect example, unintentionally,

Almost like...

because it's almost like you thought about this before, but price and quantity is a really convenient abstraction to have in a trading system, because you always want to place an order. And an order is not a price and a quantity in order has a price and a quantity, but then so does a, an order that's resting in the market. So does your, maybe your risk limits in some ways are related to these things. There's, there's a number of ways where that tuple of a price and a quantity going together is a useful thing of itself, but it doesn't really have two responsibilities. He just holds two pieces of information. Maybe that's where you're, you're. Now you're nodding at me like, yeah.

I mean, these, a lot of these are heuristics, right? Like the heuristic that you got at Google is if you're putting the word and in a, in a class name, think about it, right? Like, you know, are you, are you putting together? And I think a lot of this there's a lot of, I dunno if this is good or bad, but my experience as a software developer has been a lot of this is almost like an oral history that gets passed around from developer to developer about here's the things you should generally do. And here's the things you generally shouldn't. And the interesting thing is that the oral history among a lot of developers turns out to be the same in a lot of respects. And I think single responsibility principle is one of those. It's sort of like the Unix principle of do one thing well, right? There's a lot of, and you can find other examples of this where it's like, you know, keep things focused, do one thing, but then the arguments sort of come in in terms of like, well, what do you mean by one thing? Right.

One thing is a different thing. Cause like my price class can also represent itself as a string and it can be formatted and it has all these other things. So like, if you were to describe the responsibilities of my price, class, it would be wraps the abstract notion of the value of something and can represent itself and perform arithmetic on itself. And, and, and, and before, you know, it, you've got like a hundred ands then in a, in a useful class. But they're not really. Yeah. Yeah. They're not different responsibilities.

Yeah. What do you mean by responsibility?

Is IO a responsibility?

And what do you mean by single? Yeah, exactly. It's like,

What do you mean by, what do you mean? Or is that too...Okay.

Right, right. And I mean, I think that this actually going back to sort of, you know, Dan's comments, I think this is part of what Dan was getting at is he was, you know, he was saying, you know, don't worry about single responsibility, just write simple code. Right?

Right. Which sort of made me think as I was reading this actually of your, the thing you've mentioned, uh, before, uh, the one seconds worth of like microservices, like is there's, it's really hard to measure how big something is. You have to kind of come up with some heuristic and you've used time of before now is like, well, how long does the unit tests for this bit of code work? And that's an interesting way of measuring it as well. And, you know,

It's arbitrary, right?

To each their own. Right. Yeah. Right. Reasonable people could disagree about what it means to be small, or simple.

Yeah. So, I mean, so for me, the way that I interpret the single responsibility principle is sort of the inverse of another principle that is not in this list. The DRY principle, don't repeat yourself. Right? Um, where, um, the litmus test for me is, is something like this. If my boss comes to me and he says, Hey, we need to change this, this business logic. Right. And I, with the knowledge of the code, look at the code and say, okay, but if we change that, then we're also going to have to change this. His reaction tells me whether or not I followed the single responsibility principle correctly. If I say, well, we're going to have to change this if he says, Oh, great, perfect. That's exactly how it should be. Then I know that I followed both the single responsibility principle and the dry principle correctly.

You're coupling things.

You're coupling things together, you change one thing and you're changing something else that's totally unrelated. And that behavior needed to stay the same while this other behavior changed. Right. And you can have a situation where you have two totally different pieces of code that are in fact the same thing and what you should be doing is refactoring that code so that it looks the same and then unifying it. Right.

Got it. Yeah. But you're driving it from a business sort of point of view from the idea of, which obviously not, we not, all of us have the same experience of having a direct business owner that can tell you that kind of stuff, but you kind of like conjuring up in your mind's eye, the sort of pointy head boss to, to, to measure these things in, in this sort of slightly a thought experiment way.

Yeah. Well, and I personally don't think that all that it's, it's impossible for me to say without understanding the context in which a program's going to be used, whether or not, for example, two pieces of code are duplicated, right. You can show me two pieces of code. I can say like, yeah, that's the same code. I'm not going to tell you that you should unify them unless I understand how the code is being used. Right. You can't separate that understanding that's part of an engineer's job is to be the bridge between the technology and how the technology is being used. So, and I think a lot of the SOLID principles have to be thought of in that context of like, you know, how is this actually being used?

So we've, we've covered the, the S of solid. And I think we've got done at least some justice to Dan's point about it, meaning it many, many things to many people. Um, and so maybe we should move on to the, O, again, I've already forgotten what O, is, O, is.

Open closed principle.

open? I mean, again, trivial, trivial understanding now with, uh, with a single letter O. Um. So what is Open Closed?

What does the open-closed principle mean? So that the, the, the pithy phrase here, is code or a module or a class, or however you want to scope, it should be closed for modification, but open for extension. Right. And the way that I kind of interpret this as is if you have existing behavior that you don't want to change, you shouldn't have to change it in order to add new behavior. Now that's, and that's a goal, right? You're never going to be able to achieve that a hundred percent of the time, but like, to the extent that, which you can do that, what this principle is saying, and I'm not saying that this is necessarily true, but what this principle is saying is, is to the extent you can do that, you have produced a better design, you know, design A is better than design B because it is easier to extend and you don't have to modify. Now, this is, this is a place where I have a lot of sympathy for Dan in that, like a lot of what people sort of get into with this is reuse, is designing for reuse, right? They want to write code that can be easily reused,

But that isn't always the right goal for anyone.

Right. I mean, I'm pretty short reuse most of the time when it comes to, like, I like, I like to discover places where things are reused and not try to predict where they're going to be reused.

That's a nice, yeah, that's a good analogy. You discover it. It's an emergent property of the code and the way you're going, but very rarely do you set out and go, I'm definitely going to reuse this and I'm going to polish this beautiful reusable gem only to discover it's used in one place in the code, or indeed you've hamstrung yourself by making it so difficult.

I wonder, I often wonder if there's like a strange legacy in programming where it's like, you know, in the beginning there was ones and zeros and then we invented languages. Right. And so like a lot of programming, you know, this sort of oral history comes from the problems of language designers, right. Because that was sort of the beginning of programming. Right. Of, of like, you know, the design of, of programming languages and a lot of those problems that languages, language designers face sort of got held up as the important problems to solve when really, if you're just building like application code or even certain systems code, like that's not really the main problem that you have, right. Like a big problem for me, isn't creating a reusable standard library that is easy to use correctly and hard to use incorrectly. Right? Like that's not a problem that I solve. I occasionally I do, but not very often. Right. Whereas, you know, if you're designing a language, that's a lot of what you're doing.

Of course.

Um, and so, you know, to me, the open-close principle sort of falls into the, in a little bit into that category, which is, you know, it's useful in certain situations, but I certainly wouldn't make the claim that code that follows the open code principle is just always better than code that does not.

Got it. Yeah. This definitely falls more under the sort of guidelines for measuring a design perhaps in, in, but somewhat in a vacuum rather than being specifically in my use case and for my experience as well, like the, the tooling has changed significantly. And the way we build software has changed maybe since this is not, you know, OO, which sort of says to me, when I hear that, the open close thing, I'm thinking of like, Oh yeah, this is a class where you got extension points that are like overrideable, but you don't necessarily have to, that's obviously one way of achieving that kind of thing, but it's, it smells like that. That's the way perhaps your view would be wafted towards, by the, sorry, that doesn't make much sense, but yeah, it feels OO-y to me. Doesn't have to be. And, and so, you know, like again with, with, um, modern tooling, now, if I need to change a piece of code, it's not scary to open it up.

Yeah. I think at a certain point application of the open-close principle in most contexts just devolves into decoupling. Right. And this is again, kind of getting back to Dan's point about like, just write simple code, right? Like, okay. I think it's a little bit more nuanced than that, but you know, the open closed principle really when you get down to it is just, things should be decoupled from each other so that you don't have to change things in four places. Or, you know, if I'm, if I'm reusing a function, I shouldn't have to read all the guts of the function to understand how it works or change it, or, you know, all of that stuff. Um, but I think that the main application is like you say, like, you know, if you're, if you're building a library or something like that, you really want to think about it. If you're building a library that is going to be used by somebody that you will never meet, um, you know, as opposed to someone else in your organization. And you want to think about that. Um, but you know, it's just that, that one is, is much more about context, I think, than the first one.

I mean, just in defense of like the library writing thing, I'm just going to very briefly, uh, every now and then I've written, I've prematurely created a library, shall we say, and designed it a little bit more than it perhaps needed to do. And probably one in 50. One in a hundred times I've done that, someone else has discovered it and gone, Oh, this is useful. And then used it for things that I didn't originally plan it for it, which is great, but I don't think the benefit of people finding those libraries and then using them and then emailing me and kind of going, Hey, thanks for that, that thing, by the way, we've been using this all the time in our, in our side of the business, you know, wow that's great. Wonderful. Um, but that doesn't outweigh the pain and suffering that one goes through trying to design for something where you're, you know, you're trying to invent a customer, you don't have to design yourself. So that, that customer can reuse it.

Yes, yes, yes. Speculatively doing that as like, you know,

And it's a tax and it's expensive. Yeah.

It is. It's way more expensive to write library code and reusable code than it is to write something that's like more application focused. For sure.

So then L?

Yeah, L! Barbara Liskov, the Liskov substitution principle,

Which means you can switch in Barbara any where you like.

You can, any Barbara shaped object can be replaced with a sub Barbara that is equivalent in every respect. Um, no, I, I actually, I don't know if this is true. I was, I was trying to figure this out when I was reading Dan's Dan's thing of, like, I have heard that Barbara Liskov proposed this as an argument against inheritance. She was like, if you were going to make an inheritance system, it would have to have this property, which is a ridiculous idea. So inheritance therefore is a ridiculous idea.

Oh. It was a reductio ad absurdum. Unfortunately it was just like, Oh, and we have to be absurd then.

Maybe one of our listeners can point us to a reference on this. Cause I was trying to find out whether I've heard this. I don't know if it's true. I want, I want to, I want a reference it says that. Yeah, no, that's what Barbara Liskov meant when she did this. Um, and so it's super ironic that it's in the middle of this list of principles. Um, this to me is something that is very much about object oriented design. Um, if you are writing code in a functional language this is not something that you ever really think about. Uh, I mean maybe a little bit in corner cases, whatever, but it's certainly not risen to the level of, this is what it means to write good code. Right. Um, so, you know, it's, it's the, the basic idea here is that, um, you know, if you have an interface, if you have an abstract class and you have a subclass or a subtype, then the behavior and the definition of behavior is a little bit nebulous here, but the behavior of the subtypes should be indistinct indistinguishable, right? So you can swap out any subtype and you get the same behavior, quote, unquote, from the client's...

Well, you see, that's what I mean. I think I understand where this is going, but that description and the, or descriptions like that are inherently confusing to my pragmatic day-to-day use of sub classing and interfacing. It's like the reason I have an interface so that I can have things that do very different things. When you call, what is your name? They don't say I am an, I am an animal. They go, I'm a dog, or I'm a cat because those are the only obvious ways or, um, circle, lines, pick your OO standard class hierarchy.

I think it is kind of important to say that like, this is from the caller's perspective. Right? Okay. So it's, if the, if the internal state of a, of a class changes differently, depending on which subtype it is, like, that's completely fine, but that's hidden away from the caller. Right. Right. They don't, they don't know that anything is different.

So from the point of view of the contract between the caller and the callee there should be no sequence of events without reaching exogenously to the file system and kind of going, did you write a file or whatever? I shouldn't be able to puppeteer an object that I've been given and work out what it is just by using the API, uh, the, yeah. The calling caller's API, they look the same, right? It's not like you go, well, if it's this type you have to call free and this one, you don't have to call the free thing because, you know, Hey, it doesn't matter because it's not actually allocating anything. So you don't, and you're like, no, no, you always have to call free. Even if it's a no op in the derived class or whatever, because you have to treat them all equally. You're not allowed to go isinstance(), for example, which is the, you know, the back door that we all end up having some somewhere.

sometime I would never do that all the time. I only do that sometimes. Um, yeah. And I mean, I think, I think Bob would say, in fact, I, I know that Bob would say, cause he's written about this, that this is much more about polymorphism than it is about inheritance. Right. It's and you can have this property in languages that are not strongly typed. You can have this, some languages like Python or Ruby or

I was going to say this smells like duck typing.

Yeah. It can be duck typing. You....pragmatically in strongly typed languages, this often comes down to like function signatures, like things can't be following this principle if they don't share the same function signature, because then, or method signature, because then you'd have to know which one you're calling and pass it, the right arguments. Um, but you know, again, I kind of see this as an artifact of object oriented programming with a lot of inheritance hierarchies, which I tend not to use anyway. And a lot of polymorphic behavior, which I use sometimes. But again, it's like, does this really rise to the level of like the top five principles that you need to be aware of when you're writing code? Like yeah, no, not really.

No. It seems not. I mean, there are equivalents in functional languages, right? Matching on different aspects. I suppose you could argue is a sort of polymorphism like you, depending on these things, but, but yeah, you're right. It seems very specific to a particular popular in the nineties programming paradigm and, and, and it made a nice, neat backronym fitting L in the middle of an otherwise cool SOID. He would have like, what no one's going to want my SOID properties, find an L!

Um, and okay. And so that's, so that's Liskov substitution. And the thing is, is that it only gets worse from here, right? As you keep going through,

We scraping the barrel of letters.

Yes. We started strong and now it's like, as you go, like, it gets even more and more like, this is very clearly about a very particular kind of object oriented design that again, you know, if you're still doing that, then you know, you probably know these already, but if, if you know, it's like, so interface, segregation, you know, you're keeping the interfaces. So this is, you have an interface to a thing.

This is the, I right?

Yes, we're on I right now, um, you have an interface you want to keep that interface as narrow as you can get it. So the clients don't, don't depend on things that they shouldn't. And so that the implementers of those interfaces have the least amount of burden, in order to implement. Again, this is very much about like inheritance hierarchies and interfaces, and all this stuff.

Yes and no. I mean, it's, the interface can be a library interface presumably to like, Hey, my library exposes exactly two functions. It has allocate and it has free. And there isn't a thousands of others. And the only reason I bring this up is because something you mentioned there was like, um, to reduce the burden on calling things up, you know, you shouldn't be calling on them. It made me think of Hyrum's law, which is the law that anything you expose, no matter how it intentionally or otherwise will become relied upon by somebody at some point, given enough users of your class. So that reducing the footprint of that seems like a good idea. And that can happen in C libraries as well as C++, or other object oriented languages. Sorry. I'm very focused on specifics here, but yeah,

No, that's good. That's a good, that's an excellent point. Um, and actually, you know, now come to think of it. I was making a very similar argument to that in an earlier podcast when I was talking about file system abstractions and mocking. You remember that? And I was saying that constraining yourself to a limited number of file system operations makes it more likely that you can swap other things out. Right. If you don't think of something as a file, you think of it as this sort of abstract stream that might be a socket, or it might be a pipe, right. Like that is good. I, I kind of think of that as a very liberal interpretation of interface segregation principle, because it's when they say interface in ISP, I think they literally mean like a typed interface,

The actual keyword interface, probably involved somewhere in there.

That's what I, I, I can be talked off of that opinion for certain, honestly, I think it's more useful. I think it's more useful if you do. And you know, to your point of like, thinking of it as more of a general lowercase, I interface not capital I type interface. Um, but I think it's more useful if you think about it that way, but yeah, I was making that exact argument, not, not, but a few podcasts ago, so maybe I should...

In the strange time space of podcast.

Yes, in podcast time.

So that's I.

That's, I, and then the last one D dependency inversion principle. Basically, he's just like dependency inversion principle is you want high-level things depending on other high level things, not low-level things. Right. And it's like, yeah. Okay. So if you have an, let's take the, the object oriented example here, you have an interface that takes an argument. That argument type should be probably another interface and not a concrete class, right? Like you don't want to constrain the implementers of the interface to say that they have to take this particular concrete class. You want them to depend on a higher level abstraction, which is again, an interface or an abstract class, even rather than a concrete class, right.

This is where, like anyone who programs C++ is going, uh, we try not to do that. Or, you know, like there are various reasons why, but we've talked about that before in the abstract high-level components depend on other high-level components rather than reaching down into the guts of, of the class hierarchy and having this sort of, um, well, I guess that's the inversion of the dependency inversion is like having this dependency on a low level thing, which there maybe depends on a height. Yeah, no, I cut you off halfway through the explanation and I'm confused now.

Well, I mean, this is, I think this is the least clear of all of them, and this is probably the place where I agree most with Dan. Right. Just like, yeah, just write simple code. Right? Like it really isn't any more, there's not more much more to it than that now, you know, that's, that's my personal opinion, but I, I think, especially for all the reasons that you were just talking about of like in the C++ world, there's lots of other ways to solve that problem rather than creating higher level interfaces. You know, templating, for example, I think could be potentially used there. Um, but you know, this is, uh, this is the thing where I think I agree the most with Dan and I say, okay, yeah, just, just write simple code. So for me, the SOLID principles are like, they start off real strong, you know, S single responsibility. Yeah, totally get that. I use that all the time makes total sense. Open-close principle in certain contexts, that's really kind of valuable. Liskov's substitution may have been a prank. Interface segregation only useful in very specific situations. And I don't really find myself in situations anymore and dependency inversion, it's like, yeah, I just don't care. So really the SOLID principles should just be like.....SO?

Yep. And even the O is going to like, I, I sort of let yeah. 90% match on the S.

That's why I have the question mark.

The regular expression of this acronym. Yeah. This is, I mean, I was gonna say, this is why we don't have books, but you do have books, but you don't, you don't, I don't believe you've backed up any of your books with complicated backronyms.

Uh, no, no. I do have one, actually.

Go on!

I do have one, FIRE the fire principles, the fire attributes. I guess I did do that. I mean, that was a consultant. You have to literally that's your job.

Is that your job? Just to come up with pithy...

It's in the job description, you have to come up with the pithy, you gotta get people to remember it. Right. And, you know, people don't remember what you do and they don't remember what you say. They only remember how you make them feel. And when you make programmers go, ah, then they feel something, right. Otherwise they're just, they don't feel anything. So you have to just drive it home with those sort of really terrible puns. That's the key to teaching programmers.

Oh, that was the sound of a pun. Right. Cause I was going to say, most developers, I meet do make that sound, but there are usually frustration at me and something I've done.

No, well, that is, that's, uh, you know, uh, happy sailors complain. Have you heard that?

No...

Yeah. Uh, if you, if your sailors are complaining, they're happy and if they're silent, then you're in a lot of trouble. There's about to be a munity. But as long as they're complaining, you know, they're happy. Right.

Yeah. Right. Yeah. That's uh, I, I think that, does that make sense? Sadly.

That's, that's the programmer mindset I've seen many, many times and had many, many, many times. Um, so yeah, so that's, that's, I mean, you know, that's sort of the quick run through of, of SOLID and that's my take on them.

And I think we've, we've done, we've mentioned a few of the things that Dan brought up in his article along the way. And I mean, I basically, because again, the, the, my understanding of the SOLID principles, wasn't very strong. Other than like the S.

Wasn't very SOLID? Ahhhh.....

Now I'll remember because this is how you make me feel. No, because my understanding wasn't that good. Uh, the article was made sense to me just on its own because it was making good points, but, uh, I think I've got a better understanding now, but were there any parts of the article of Dan's article that we haven't covered?

Possibly. I read it like earlier today.

We don't have to read through the whole thing. It was more a question of me wanting to pick your brains about what SOLID, what, so that I could have a decent understanding, because I think I've, I've long had this feeling that I, I'm not as real a programmer as most people, because I spend most of my time in the weeds down in the lower levels of, of the technology stack. And there you can, you got a free pass for a lot of the good design principles, all in the name of performance, you know? Yeah. We don't use this because that's, that would be too slow. And I'm spending more and more of my time realizing that the things that I say like that are not actually true anymore, but it has definitely given me about a 15 year free pass out of like good solid engineering principles, like, you know, high level engineering principles. So I suppose I'm a little bit, um, behind, and I'm now just abusing the fact that we have a podcast to learn from you, which doesn't seem like the worst, worst idea for me personally.

Well, I mean, I, I think a question you could ask are in general, our programming principles, a good idea at all, right? Like, do they hold up over time? Is this a good way to teach people? Is this a good way to mentor people is to have a set of principles that you say like, this is what represents good software design. Um, and I think I could maybe argue that the answer to that is no, I could definitely argue that the answer is yes. I mean, I professionally argued that the answer to that is yes.

But then your paycheck was somewhat dependent on people believing you.

Right, right. Oh, no, really. Okay. Well then we don't need to hire you and that's the end of this conversation. Right. Um, and I mean, I can, I can argue, I think I can argue both sides because I can definitely see merit to both sides. Right. Um, getting back to the whole, like, so there's, there is a technique, this is not a principle. This is a technique that I have used quite a bit when I'm trying to teach people how to mentor. So mentoring mentors,

Woah

and it's called Shu Ha Ri and, uh, it's, it comes from, I think it comes from a martial art. I'm actually not sure on the entomology of this word, but, um, or this phrase.

Isn't entomology, the study of insects, I think, etymology. You're not sure about this insects.

I'm unsure about the etymology of entomology. So, uh, etymology and so Shuhari, is this is this basically three phase model of mentoring where you give people, Shu is the first phase and you give people a rote series of steps to follow, right? You say, do these things, right. Ha is the second phase where you start to help them. They, they start to see patterns and you start to help develop patterns and you name the patterns, right? Like in, literally in software engineering, we've had the patterns movement, and, and, and other principles like this, where you say, you know, these are things that tend to happen, and this is what we call it when that happens. Right. Uh, and then people can start to mix and match those patterns and they see the world in patterns and they start to recognize them. And then Ri is when you sort of move beyond that, and you start focusing on outcomes, right?

The Shu of the Shu Ha Ri.

The Shu of the Shu Ha Ri. Right. And so that second phase, I think, is where these kinds of principles have the most value, right? Because you're trying to get people to move beyond the sort of rote copying of do this, do this, do this, do this, to starting to see what's going on and see the patterns and being able to name them. Let's you talk about them. Cause if you don't give them names, then it's remember that thing that we did the one time with the blah blah blah, and you're 15 minutes into the conversation before you've gotten to the point.

I mean that was absolutely what the, you know, the gang of four patterns book gave me, gave me a vocabulary to describe, even if we weren't using them very often, but you could just say, Hey, you know that thing, that's a flyweight. And then you could have a conversation about why it was a flyweight and yeah. Super useful. But yeah, no, this makes a lot of sense.

Yeah. So, so like once you have those names, you know, and it's like in electrical engineering, you have a resistor, you have a capacitor, you have a transistor, right? Like you, you don't have to describe the properties of a capacitor every time you want to talk about, you know, two plates holding a charge.

And indeed when you're like doing like EE101 type stuff, you know, you're just like, yes, you put a resistor, it's always a 220 ohm resistor next to the led because you, you know, and it limits the current and then you just move on with it. And you say, you just do that. Yeah. Forget about it. In fact, you'll see, I've seen some people online with like, they just make these these LEDs that have the 220 ohm resistor, like, like on the leg of the, of the LED. So they can just plug them into the, but never blow them up. Right. And then later on, you're like, well, what's the principle of that? Well, it'll explode if you put the full current through it. And then later on, you're like, well, I know, you know, I understand what I'm trying to achieve. I'm just gonna, I don't even need the light. I don't need the resistor, I don't need the led. I'm going to lick my finger and put it on the, yeah. Okay. It's on now. Whatever. I'm trying. That's not the best analogy.

Yeah. Yeah. So, so at each phase there, you can kind of get stuck in a little bit of a cargo cult, right. Where if you, if you're just following a pattern, you never really are following the steps and you never,

If, for example, somebody's livelihood depends on you. Um, following the things that they're saying, they might argue that there's a certain, like, not so much a cargo cult as like a, a willful, uh, recycling of ideas, which I know we've got ideas, you know, we we've talked before about how we do this, um, this process of determining what we're going to talk about. We've got some of those things on there, so I don't want to go, I don't want to go into that now. We've got not enough time left to start on that whole world. But yeah. I mean, so these are like the eddy currents that keep you in one of your little things, because, you know, there's, there's, you know, there, uh, there there's the agile world that says, no, this is how we do things around here. And there's a benefit to being able to talk about it. But then as you say, it could be a limitation.

Right? There's lots of parallels with lots of things. And a lot of it comes from expertise, right? Like if you are observing something that somebody does and you start to hear them talk about things in terms of patterns, but you don't understand what those patterns are. You can actually subtly reinforce that sort of pattern style thinking, because that's the only mode that you have to communicate with them. Right? You say like, Oh, shouldn't we add a resistor to the, to the led? I don't know anything about resistors or LEDs, but that worked at my last job. Right? Like, unless yeah. Like, unless you really understand why it is that you're doing that, then it can be the organizations can reinforce this, you know, managers can reinforce this, all kinds of things can sort of, you know, standards, committees and certifications and all these, are you a scrum certified blah, blah, blah. Cause you do these steps and those steps, and these steps, right? Like all of those things can be reinforcing to sort of keep people to sort of hold them back and like never let them progress to the point where they are letting go of the patterns and just focusing on outcomes.

On the outcome. Yeah. That's a, that's a really powerful way of thinking of it. But, and again, it's not like this is a bad thing necessarily. It is. It's a natural progression. I mean, I'm just thinking about silly things like learning to drive, you know, you get in the car and your driving instructor says, do these things. Question not why we're doing them. You know, one day you'll do you'll realize why. And I mean, particularly, uh, in, in the UK, when I was growing up, actually one of my best friends was my, uh, his father was a driving instructor and there was all these things that we'd have to do, like passing plates. As you turn the steering wheel, you always have to have one hand on the steering wheel, which means that you're essentially got your hands at the like 10 o'clock and two o'clock position.

So, yeah. So yeah, I mean the SOLID principles are a way, especially if you're operating in that sort of object oriented world. And honestly, I kind of feel like they almost apply more in Java than they do in C++, like they sort of came out of the nineties and I feel like I obviously Bob and those guys are very well experienced C++ programmers. So it's not like I'm, I'm saying that they're, they're, you know, coming from a place of ignorance on this, but, you know, I, I maybe would recharacterize this as it's in a lot of ways, easier to apply those principles as written in Java, right?

Yes.

Um, like it's much clearer and you know, maybe that's a nod to Java and it's, it's, you know, it was based on the design of, of things that at least at the time were, were novel and good, but, you know, it's, it's something where, unless you're, you're doing that particular style of software development, you know, it's just....so, so?

Ha-Ha! Well, I mean, that seems like, it seems like we can't beat that now.

Mic drop?

This is definitely a mic, or a mic wallop as I keep walloping my mic on this funny stand. You can probably hear. Yeah, no, that's. That's awesome. Um, yeah. Well now I know what the SOLID principles are, and I know that I can disregard the, the lid drop the lid, take the lid off solid. We can make some more puns. And we know that the open close principle or open closed principle pretty just means right. Easy to understand code. That's easy to change. And the single responsibility principle, I think when you praise does right. Easy to understand code. So what I'm really hearing.

It's maybe a little more nuanced than that.

It's just, I mean, write straightforward code and that's almost always the right thing to do, right. If you're faced against faced up a decision, it's like, which one's the easiest one to do. And most of the time is the easier thing to do. And I've,

If I were to quote Bob, I would say yes. Write simple code all the time. That is what you should do. The SOLID principles can be a way to achieve that, if you know how to apply them correctly.

Sounds like a great way of explaining it and a great way to finish the episode too.

Sounds good to me.

So catch you next time.

Yep.