SOLID Principals and the soft side of the force.
(Another little step to help mind the gap between softies and techies - just an essay)
I always try to follow principals, patterns and good practices that have been raised from other's theories, practices and experiences. There are countless articles about SOLID principals.
I also try to follow my own experiences and experiments and what I have learned by trying, inspecting and adapting. And I am not talking only about the technical side, I am talking also about the soft skill side of dealing with technologies and much more important, with people.
I enjoy observing and filing the gap between soft skills and tech skills. I am amused (and sometimes get pissed off) when I hear developers saying that the scrum master, the manager, the “whatever role that is not techy” does not understand a damn thing about technology. And that person should not have this role and probably they think they would do better themselves (and maybe they would but that is not the point here anyway).
I am amused also (and sometimes get pissed off) when I hear some manager, scrum master or PO, whatever softy, saying that this developer is very shy and that he does not communicate well or enough or is always by himself between the chair and the screen and that he is not able to estimate nor does he like to do so and is always looking at his portable phone in each and every SCRUM ceremony that he ultimately thinks there are useless anyway.
Have we tried to talk to each other? and maybe even teach or train each other? Have we tried first to be honest and without fear communicate with each other? Or have we decided already that this is just not a fit. It is so simple to just let go. The only way to do so is silence. It is just like failing: the only way not to fail is not to try.
As people start to share opinions (this is indeed what we call talking or having a conversation) there will be certainly agreements but mostly there will be disagreements and hopefully healthy confrontations and that is good. The confrontations and the disagreements are the ones that will make us grow. The most important is that we accept the differences and that we acknowledge this gap between "techies" and "softies" so that both sides may build better and more happy bridges. Usually one way to avoid confrontations is to avoid communication, and to me it is just like being afraid… or dead. And as we say in Portugal: “If you are afraid, bye a dog!” 😊
Get used to it, people, we do not change. (well, ok, ok, this is may be arguable….) But we may try certainly to make some adaptations that hopefully will lead to some kind of improvement that later on could be called a change. This WIP (Work In Progress) is just a small step, an essay and a small trail to help fill in some “concrete” within the gap between developers and the rest of the world, and vice versa.
I believe that everyone wants to be better. Softies that do not understand the engineering of code would certainly love to be calmly super developers. Super techies on their side would certainly take that pill that would make them this Kool and comfortable and great public communicator for ever. (they are certainly some that have both, lucky them!). In our Era, in this dimension of time we are leaving in, gaining soft skills when one has tech skills, and gaining tech skills when on has soft skills must certainly be good! No?
SOLID principals are a great helper to well-crafted object-oriented software. They do not solve it all, indeed, but if understood and applied correctly they will certainly help toward lowering technical debt. I know them by heart as many design patterns and apply them everywhere and every time I can (I should not have written “…every time I can” 😊).
I am not sure I fully understand them all in all their dimensions. I think every developer should know them as best as possible. Actually, anyone involved in software design and development should try to learn the SOLID principles and at least be aware of their existence and grab some concepts around them. To do so one needs to have some quite good OOP concepts.
They may be not easy at first. Everything is difficult until it is not anymore.
SOLID principals are not patterns. Patterns actually offer some kind of implementation. Principals only offer guidance. SOLID principals may and are of course related to some software pattern(s). They actually complement each other. Some SOLID principals have direct patterns counterpart. Not all patterns are directly related to one of the principle of the SOLID collection. Some SOLID principals need multiple patterns to be fully fulfilled. And, by the way, there are other software development principals than SOLID: DRY (Do not Repeat Yourself, YAGNI (You Are Not Going to Need It), KISS (Keep It Simple Stupid) and much, much more…
Each SOLID principal should be the target of its own article. We will look superficially at each principal regarding its tech side just too get to know it and summarize it. We will then try to define a soft skill equivalent principal for each one.
I do not know if there are already some "SOLID" principals applied to soft skills. As I searched the internet, I could not find anything related. Anyway, I decided to give my 5 cents about it. I have been actually thinking about it for some time, and as I said above: this is work in progress.
I also hope this might be of some help towards lowering "soft skills" and "tech skills" debt. And I am sure my point of view about this subject will evolve and maybe someday will give rise to an upgraded article.
I do not think about what I am writing as to be “right”. This is not code: this is my opinion at the moment. I am sure that when I have finished I may already have change many things.
To better understand this essay and grab my aim you may need to have some OOP concepts if you are a softy. If you are a techy, you may need some open minded and soften point of view.
Let's get started! 😊
S for Single Responsibility Principal (SRP)
Cohesion is key in software engineering and it may be defined as a piece of code (a class, a method/function, a web method, a micro-service for example) having a well-defined, atomic and unique purpose (that certainly may be part of the solution for a higher problem). Some state that a block of code should have only one reason to change. I like this definition. That does not mean that, to do what it has been written for, it should not use many outside functionalities as needed but without coupling. Mostly it should have only one single purpose, a single reason to exist and to do what it does, a single responsibility.
Having a single responsibility in life sounds very boring. But indeed, for mother nature it looks like our only responsibility, our main purpose in life, is to have children. 😊. For many Humans is to find oneself! I Love both, there is time enough for both plenty of it! Anyway, let’s Step one level in the philosophical and social chain trying to counterpart the SRP on soft skills.
One soft skill that may be related (and i believe it is a very good soft skill actually) is having "single minded qualities". Being able to not multitask is challenging (at least for me). I believe that monotasking achieves much more results quicker. Anyway, in SRP (on the tech side) time is not inherently involved. So, let's say that once we start a single task with a single responsibility we do it until it is done. The only reason to change is because some other need jumped in and we are sure that it is most valuable to do the transition and later on get back to what we were doing than to finish what you have in hand (if it happens many times then something is wrong, may be…).
The SRP on the soft side of the force may be: “Do not multitask, do what you are doing until it is DONE.”. 😊
O for Open Closed Principal (OCP)
Being able to add functionality with ease and without regression issues is key. It is much more important than to be able to change existing code to achieve new business values. Why should I want to change some already well written piece of code and by the way delete some existing functionality? Even if I do not need it anymore, it may be needed again later on as it did the first time it was written (happens so frequently). But for sure we need upgrades! we need new and valuable business features side by side or on top of our code base. Well written code should be open for upgrading, for improving, for accepting easily new or better functionalities without touching or modifying existing code nor implementations nor responsibilities. This is not a change actually, this is an improvement, an upgrade. I love improvements and upgrades.
Oh change, CHANGE!! I love this one: Do we human change? this is a tricky one and can quickly reach polemic discussions and it is quite understandable. Myself, well, I do not believe so, I do not believe we change. I love one of my grand mom’s philosophy of life: "Understand others and search for yourself when you are talking about who he is not present". Besides being a beautiful statement and also an honest one, if people changed how could we found ourselves or understand others?
Besides people saying "I was not myself" and that certainly sometimes may happen, we are what we are, good or bad. When we believe it is bad, we may try to improve, and get some better. When it is good we can still learn, improve and get better at it. But change? what? suddenly I am a lamp? 😊 and then what, for some time only, then I will get back to my human way or form. Suddenly I am not waterfall anymore?
We should take some baby steps towards an upgrade, towards an improvement that may look in the long run that some little things have changed.
OCP on the soft side of the force may be: “Do not try to change, adapt instead: look inside, learn, look again, improve, upgrade”. 😊
L for Liskov Substitution Principal (LSP)
Being able to enforce both first and second SOLID principal is key. Inheritance in OOP usually states that deriving classes forms between them a "is a" relationship. An object of the derived class (extended) “is a” object of the base class (super class). And that is fine. Actually, not always!
Liskov states that deriving should be much more than a “is a” relationship, it should be a "is substitutable for".
When we have cohesion and when the code is well encapsulated and derived, we have to be able to use any derived (extended object) in the place of any base (super) object without any disruption nor modification. From another point of view, we may say that if we use a reference to an object of a base class it should be transparent to pass in a reference of a derived (extended) object of that class.
Why do we want to achieve that anyway?
We should freely be able to upgrade our objects deriving from it and creating extended objects but still work with and still be able to do what their base class were intended to do. Derived classes should fully respect and follow the contract and the purpose of their base classes. (not on the agenda but anyway I would not feel complete if I did not tell that deriving is not the only nor always the better way to make more powerful/specialized objects that still can do simple things. Composition may be in many situations a good and even better way to do it, this is called: "composition over inheritance principal". Both composition and inheritance are very important and find their logical place within OOP architecture).
Usually if we are not able to fully use a derived object in place of an object of the base class we may not have a correct abstraction. Maybe we are doing the right thing but certainly we are not doing the thing right.
I did not find it easy to grasp a soft skill principal counterpart for LSP. A child should always be able to fully replace his parent? I do not think so. This would be good… maybe. 😊
In the real world (whatever that means) this is what I came up with at this moment: we should not forget about the simple things in life and also the long way we have been going through to become better man, to reach some deeper knowledge. Whenever we reach higher grounds we should not forget where (and when) we came from. When we are able to do complicated things, we should always keep doing the simple things in life. I also believe that some things are so simple for some people and the same things may be so complicated or so difficult for others and this happens much more that we can perceive or understand sometimes. I do not believe Liskov substitution principal has a direct counterpart in the human world but this might be a fair approximation. With more time maybe I will find new ways to look at this principal on the soft side of the force.
LSP on the soft side of the force may be: “Whenever one gets more abstracted, elevated, one should not forget about the simpler things in life.” 😊
I for Interface Segregation Principal (ISP)
Designing interfaces with the SRP principal in mind is key. Not making anyone implement methods that they do not need is a good thing. Abstraction and some form of polymorphism (late binding) may be achieved by depending on interfaces instead of concrete classes and that is a good thing. Nevertheless, having too many methods in a contract may be very bad, unless we always need to implement all of them. We may see this as being the SRP for contracts. Once in a conference a speaker asked if anyone had a definition for a micro-service, nobody was answering, so I decided to give it a shoot and I said: "A micro service is the application of the interface segregation principal to a web API". is it not?
A soft skill for this one is actually one of my favorite. One should not be forced to behave in a certain way. I have what I consider a delicious story that may fit here (if it does not fit it does not matter as it is indeed a delicious story to me):
"A grand mom was standing near by a cross road looking as if she wanted to actually cross the street. In the meantime, a young fellow passing by looked at her and with some hurry took her arm and helped her cross the road, disregarding her while she was gesticulating and trying to say something. When they reach the other side, the young boy was quite pride of the achievement until he heard the old lady say: 'young boy, honey, thanks a lot…. I did not mean to cross the road'"
I absolutely believe in free will, in all his dimension. I do not tolerate when someone wants to force me or anyone else on how to behave in a particular situation. As I will not tell someone how to behave. (unless when I am defending that one should be free 😊) I will certainly give my opinion if asked. And I will certainly have no problem to ask for an opinion.
Everyone is (should be?) granted the right to behave as he so fit, as long as he is always “man enough” to handle responsibilities and consequences.
We should not make others behave or do things as we think they should be or think they are right. We should always be able to prove that a certain way is better and then let people choose. That is why code and computers are so different. In the digital numeric word, there is always irrefutable ways to prove that something is better or worse, it can be hard sometimes but it is possible. I mean, this word is made only of 0s and 1s. And most important, to me, code (software) has always been very tangible. In the human word, I believe that truth and to be right or to be wrong are only the interfaces that we have chosen to use, chosen to believe.
Beside not making anyone do what we believe it is correct we should explain it and be able to explain it simply, like a simple interface.
“If you can´t explain it simply you don’t understand it well enough”. A. Einstein(?)
ISP on the soft side of the force may be: “Be simple and single purposed when interacting with others if you simply want to make yourself simply useful”. 😊
D for Dependency Inversion Principal (DIP)
Sometimes I am not completely sure to understand fully DIP in all its dimensions. At the moment i believe i will not be able to explain it fully and simply, yet.
I believe than decoupling code, modules, software is key! There is a lot to understand, to say, to write and to demonstrate with code regarding DIP. It is not that straightforward as it may look at first site. It is, most of the time, related with DI (Dependency Injection) and IOC (Inversion of Control), but there are also voices that states they are not the same. They are certainly related and may be even complementary but indeed, they are not the same.
DIP is deep and has many faces. The mind set and reasoning flow when programming using OOP is usually Top down (we are trained this way). We abstract and define real world entities using classes then create objects of those types of classes. Objects have methods that creates other objects when needed. Mainly high-level modules, classes, entities whatever depend now on low level ones. DIP states that they should not. Actually, it should be the opposite. And more, both should not depend on concretions but on abstractions. And more, abstractions should not depend on details.
I will assume here (for the sake of being able to finish writing this first essay) that one of its simplest form (or part of it actually) is the Dependency injection technique. We will move on with it. (At the end it is anyway an important programming principal).
Not depending on construction is key. Avoiding coupling within methods because of the construction of dependent objects is a must have. Putting it simply we shall not use the "new" operator inside any method, that is, we shall not construct any object we might need inside any entity unless the purpose (responsibility) of that entity is to create objects. If we still do so, we will create highly coupled code. On way to measure this kind of coupling is to measure how difficult it is to unit test atomically that method.
Instead of constructing objects inside methods we shall pass those dependencies through parameters and better yet we should receive those implementations using interfaces. Using abstraction, we can pass any implementation we want that follows the expected contract. Along with applying this technique to decouple use from construction, we also need to apply some creational pattern (factory method may be), right? I mean, we need to construct the objects somewhere, do we not? 😊
Oh my, is that so difficult to find a counterpart soft skill principal for the dependency inversion? I mean, it sounds common sense to me. If i need to ride a bike why should i need to construct, i don´t know, breaks? If you want me to ride a bike, give me breaks so that i can lower the speed and stop when i need. I should not want to construct breaks just because i want to ride a bicycle. And more, I should not depend on any specific kind of breaks but only on the fact that it should break down speed.
If I have a method which SRP is to save some data to a database it should not have to construct the repository to do so but instead it should receive an interface with a “SaveToDatabase” method on the contract.
Actually, this is the principal that gave me more trouble to find a soft skill "equivalent" that would suit the purpose of this essay. Anyway, since we are talking about Dependency Injection as a flavor of Dependency Inversion, we are talking about receiving features we need instead of building them ourselves. Maybe we are talking about giving responsibilities to others instead of doing it all alone. We are then actually inverting responsibilities. Inverting who has power. So, we are not talking only about collaboration we are talking about empowerment. This is quite fashionable within the Agile world and sometimes it is not stated that power is not given without costs (most of the time). That is why it is easier to follow the leader. That is why it is easier to construct the required objects and create coupled dependencies.
DIP on the soft side of the force may be: “Power is for whom will accept it because most wants it but few will take it. With power comes greater responsibilities” 😊
Debrief:
Single Responsibility Principal - SRP
An entity should have only one reason to change.
Do no multitask, do what you are doing until it is DONE, DONE.
O for Open Closed Principal (OCP)
Software entities should be open to extension and close to modification
Do not try to change, adapt instead: look inside, learn, look again, improve, upgrade.
L for Liskov Substitution Principal (LSP)
Objects of derived classes must be substitutable for objects of the base class.
Whenever one gets more abstracted, elevated, one should not forget about the simpler things in life.
I for Interface Segregation Principal (ISP)
Client should not be forced to depend on methods it does not use.
Be simple and single purposed when interacting with others if you want to make yourself really useful.
D for Dependency Inversion Principal (DIP)
high level modules should not depend on low level modules but the opposite and both should depend on abstractions.
Power is for whom will accept it because most wants it but few will take it; With power comes greater responsibilities.
Some Final words:
I hope some will find interesting to think about using engineering principals and try to relate them to human behavior. I mean we are in the turning page of deep learning and AI.
I really believe that in many organizations there is a quite huge gap between soft skills and tech skills, between management and engineering.
As software development involve along with SDL management methodologies I believe that this gap needs to be tightened.
Everyone that deals with SDL (Software Development Life Cycle) either on the soft side or tech side of the force has (among others 😊) the single responsibility to mind the gap between tech skills and soft skills and be open to improve and help improve those skills. Teams will then become more self-sufficient and a substitute between each other on different roles. It will help to achieve this by being simple when communicating, teaching or training others so to be the most useful and finally being able to strengthen each other so that power will not only be wanted, it will be naturally accepted and even embraced and maybe we will go together towards a better tomorrow, for everyone.
That’s it. Thanks for reading!
Thanks LU, L.U 😊
Best Regards from Porto, Portugal.
Daniel Carrilho.
Nobody does anything alone, here are some very important References: