One day I started running with my friend. No prior planning. No management. We just arrived from office and my friend ask “do you want to go for exercise?” I said yes. Then my friend says come on let’s run.
Without any second thought, I changed dress and started running with him. We were desperate and we push our limits on the first day. We were breathing heavily. We ran about 4 miles.
There was severe pain in my legs but we were motivated so we did not care.
Next day the motivation was gone and It’s gone for long. We never went for exercise even after months.
Do you have this kind of experience? You have started something out of desperation and then after some time leave it.
For example:
You started reading books and leave it after 1 or 2 weeks!
Or
You started dieting and didn’t bother to think about it again after one party with friends!
So why we do it- why we start something and then leave it?
This is because somewhere in our conscious mind we are thinking about our health. All of us know that exercise is good for health and we should do this. But we don’t have the time (put any other excuse here).
We learned about these healthy habits from the news or from articles. We thought in our mind that we should try these. But we never do. So these things all add up and one day they outbreak.
Psychologists called that emotional wave. We were on an emotional ride when we started running. One problem with the emotional ride is that they declined after some time. And we fall back to our old routines.
You can feel other emotional waves as well. For example, eating healthy food, wake up early, not waste your time on social media, TV, movies and etc.
As a programmer, you may experience emotional waves. For example, you want to gain experience in another technology and therefore you started a personal learning project and never finish that.
Another emotional wave for programmers is that they want to make good object oriented designs. Often I had these emotional waves but like running I could not keep up.
So in this post, I will discuss what you can do to keep up using object-oriented design(OOD) methodology and not fall victim to emotional wave.
What is stopping you?
OOD is an important skill to learn. Once you are good at it, learning frameworks will be easier. Writing maintainable code will be easy. You will feel proud of yourself.
Learning OOD as a skill will certainly lead you to the club of elite software developers.
You want to recognize yourself as someone who knows about object oriented designs. You want to see yourself in the design role.
Ok. Ok. Ok. We all know the benefits of OOD then what is stopping us? There are two kinds of factors: internal and external.
External Resisting Factors
The first external factor is your boss. Your boss does not understand OOAD. Especially if your boss is non-technical.
Your boss thinks that you are wasting resources. Because applying OOAD process will not produce a single line of code.
Most of the benefits of using OOAD are not immediate. Benefits like reusability, modularity, and testability are visible when there are changes in the code. Changes happen in future. Hence why invest in something that is not important now?
Believe me, your boss is thinking there will be no change in the code — so why extra effort?
Guess what!
You will have to update/upgrade/modify your code. In software development, the only thing that is constant is ‘CHANGE’.
Hence convincing your boss is one huge external factor.
Another external factor — not enough resources. Sometimes we believe that if we have good tools then we will be able to go for OOD.
For example, UML modeling tool. Some developers believe that if they don’t have the perfect UML designing tool they cannot design.
Internal Resisting Factors
Harder than external factors are internal factors. The first one is that nobody will appreciate you when you start applying OOD process. This is because you don’t have any concrete evidence right now to show the benefits of your code design.
External appreciation is critical to get us moving. Hence if nobody supports us during our journey then we can lose the motivation to design our software properly.
Another internal fear is that you will doubt yourself- i.e you may doubt on your design skills. You yourself don’t know if something will be any helpful in the future– as results are not imminent while you are designing.
This is truer if you are a junior developer. You only have studied about design patterns during your studies. Due to this, you are lacking experience and confidence.
Another fear is the fear of failure. I believe this is more common. I am the victim of this fear. Once I design a software where I use generalization when there was only one line of code was common in two classes. Due to this, I have to manage more classes.
I always thought – what if I failed while making this design choice and due to fear of failure – I never did it. Failing once has made me resistive to good design practices.
Too many factors, what should I do?
Yes up to now I only described the factors that resist us. First, I described that sometimes our emotions are on high point and we want to make something happen like getting fit or making good engineering design.
But the reality of the world sets in and we leave the good things for tomorrow. Which never comes.
The first thing to design better is to create self-awareness. Create awareness of the factors that can limit your ability to do things which are good for your future.
Some factors I already have mentioned above but they are not limited to these. There can be many others. Whatever they are following guideline will always help you.
How to handle external fears?
Now, to deal with external factors(your boss and etc) you have to find small opportunities. Opportunities where you can make your design better.
For example, an opportunity is when you are debugging. While debugging your code you have the opportunity to stretch time. Here you can apply design practices and make your code better.
Another opportunity is when your boss asks you about an estimate for implementing a feature. Here you can add additional time for design activities. Make sure that you only add hours or 1 to 2 days at max. Never allocate weeks for design activities.
Another opportunity is when you are set for review. This can be rare and it varies from places to places. When you are reviewing your code for any unseen problem you can refactor your code for a better OO design.
You might be thinking that how can we make a good design after all the code is written?
Well, you can make your design better at any stage of the development. An OO design is not only a one-time activity.
How to Overcome Internal Resisting factors?
To overcome internal factors the key is confidence. Believe in that whatever you are doing will be helpful. Once you have this firm believe, you will observe the benefits of OOAD over time.
This is extremely necessary if you are a junior developer. Lack of experience will make you doubt the benefits of OOD methodology. Once you have confidence and willing to give in the effort, you will reap benefits.
Once you are confident then don’t worry about what other people are thinking. You will not need external motivation to carry out your work.
Next is fear of failure.
I used to think more about failures than success. What if all the design effort that I am doing will not be helpful. What if all the additional number of classes created due to the design process will be a headache to manage!
And most scary feeling:
My boss and my colleagues will make fun of me!
Yes, I have these fears and how do I tackle them. It’s simple. Just do it. If you failed (which happens rarely) then you know that you have learned something- But if you don’t give it a shot what will you lose?
For example, you will lose:
- An experience which can get you to higher places.
- Using object-oriented programming languages in an object oriented way (Not the procedural way).
- Most importantly trying out new things in your life 🙂
Look, what I am saying is “start small”. Find the small opportunities to apply OOAD skills. Take small risks. These small tests will bring you the wealth of experience and you will be far ahead of your peers in the coming years.
So, what are the obstacles that you face? Are they internal or external.? Reply me via email or write them in the comments.
Hey dude. First of, great article! I read your articles every single time and really appreciate your efforts. I myself am a junior developer with just 3 years of experience under my belt. About one and a half year ago I stumbled over the great book ‘Clean Code’ by Uncle Bob and was astonished how much I did wrong. Let’s be honest: I was a really shitty programmer before I started reading it. But practice and patience (and a lot more reading about OOP and Design Patterns) did it’s work. A couple of months ago a new coworker started at our company and he did not know nothing about OOP so I took the chance and tried to explain to him what I have learned so far. He was incredibly thankful for all the advices I gave him and this is what I have learned from that: TEACH OTHERS! Because they ask questions you never came up with you start checking for them and actually learn alongside with them. This really skyrocketed my learning curve and it is an incredibly rewarding experience for both sides!
TL;DR: Teach others.
Thanks man.
Yes, your story pretty much resonates with my story. Thanks for sharing your experience.
I believe that teaching others will not only help others but it helps you too. I learned too much by teaching others because I tried to understand the topic from each perspective. I tried to answer all of my questions — that arose in my mind while learning.
Because of that I can answer the questions asked by my students. Hence I strictly follow this rule : learn something like you have to teach it to others.
So, would you like to share the top-most problem or challenge or question that your coworker student had?
I think most of our discussions were based around the concepts of Dependency Injection, Inversion of Control and design patterns. By discussing which design pattern to use and why we think it is the right choice we both learned the most about OOP and OOD.
Speaking for myself: Internal resisting factors were the ones that kept me check for a long time. I was always in doubt about my own skills because I had no one to tell me if my code was good or bad. I was only judged by “problem solved equals good code”. But after my coworker was able to use my code only by extending some interfaces (without making changes) I realised that all the hard work paid off. This was a huge boost of confidence.
Another way how I overcame my fears was start writing my own library. I only use it for myself but every time I extend it I make sure to go through the old classes. Most of the time I find things to improve or to refactor. This helps me keeping track of my own progress and in addition I always feel pretty smart 🙂 Hence, boosting my confidence.
What was your first “Wow, I did it the right way!” moment? And do you have a special way of keeping track of your own progress?
The first aha moment–I wrote my first large project code using vb6. It was painful. When I started writing code using oop.. The basic concepts like encapsulation brought in the happiness a.k.a easy to change..
To keep track of the progress–
I do reviews and note the benefits of any design pattern I implemented.
Most of the design patterns or any principle didn’t make sense until you implement that.
Hence implementation and review are the keys for making progress.