There is a famous phrase from Albert Einstein which says that in this world survive not the strongest individuals, even not the smartest ones but those who are the most adaptive.
And that is definitely true for most situations in life. Seriously, look at the cockroaches. They’re so adaptive creatures and they can survive almost everything, even a nuclear blast, due to their extreme adaptivity.
Another example is the bacteria and viruses which sometimes adapt to the treatment they have been exposed to. They often mutate and become resistant to it.
Also, for us, humans, if we don’t adapt to a certain society then we are being kicked off from it. If we don’t integrate ourselves and align our culture and values with the agreed ones from that society, then we become strangers, and sooner or later we are cut out like a tumor. If we don’t adapt to the situation there is a good possibility to be attacked, rejected, crushed, and destroyed in one way or another.
However, there are lots of exceptions to that statement and places where it is not really correct.
For instance, we all know the experiment with the frog and the boiling water where the premise is that if a frog is put suddenly into boiling water, it will jump out. However, if that frog has been put in a pot full of cold water and then placed on a hot stove so that the water will be brought to a boil slowly, the frog will not go away from the boiling water. Instead, since this process is slow, the frog will not perceive the danger, it will adapt to the new water temperature and finally, it will be cooked to death.
So what happened here is that this adaptivity of the Frog actually killed it.
Software development can also be an exception to that rule.
Let me give you some context with an example situation that has happened to me a lot of times.
I presume all of us are doing code reviews of the implementation of our colleagues (If not, you should soon start doing it and here you can check 10 tips for it).
I have been doing this activity for many years and even more in the last several years.
So, sometimes I can see a “smelly code”, which applies to really bad practice. Let’s call that piece of code – a durian*.
* Durian is a fruit that can be found in Southeast Asia. It is a sweet one, however, what is special about it is its odor. To me, it smells like a mixture of garlic, dirty socks, puke, and bubble gum. And it has a really strong odor. It is forbidden in most public places.
Then what I am doing in those situations is to contact the developer and explain to him/her what can be improved, why it is important, how it can be done, etc.
And do you know that I very often receive an answer similar to this one:
– Yeah, I know that and I was thinking of doing it so, but I saw an example in the code which was done the same way I did it. And even though I know it is not the correct way I made it consistent with what is already there.
So what is happening is that even though the people know that this introduces a technical debt and we will have problems in the future, they are doing it because they follow an example and they were tempted to apply it themselves.
Do you know what that is?
The Broken Window
This is an example of the Broken window theory in practice.
The mentioned theory is used in criminology and it is based on the statement that:
“Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken.“
If we see something incorrect and that is not being fixed by anyone, what that means to us is that this is totally fine and we can repeat the same bad practice. When we see the same bad example, used in more than one place then that makes it a role model.
Remember, Entropy is a universal rule, which is working all of the time, so we must apply a constant effort in order to hold it.
It is crucial to pay attention to that, especially if you are working on a legacy project.
It is very easy to ignore professionalism, however, nobody is going to benefit from it – neither you, your colleague, your boss, or the company you are working at.
There are several things which I think are important in order to keep us in shape and thus to provide a quality product:
- Do not be lazy – motivate yourself, create challenges for yourself, be proud of the product you deliver
- Be proactive – do not be afraid to propose changes, different solutions, or things that nobody has done so far.
- Do refactoring – apply the “good boy scout” rule.
- Be a leader – support the people you are working with.
- Especially if you are taking a more senior position – always support the others and give them the courage to propose their ideas and to be more proactive.