Entrusted freedom on Developers

Developer's Responsibility

Created by katemangostar - www.freepik.com

Disclaimer : The content of this blog are my views and understanding of the topic. I do not intend to demean anything or anyone. I am only trying to share my views on the topic so that you will get a different thought process and angle to look at this topic.

We learn many languages and frameworks which have some specific way of achieving a functionality. Once we learn them the next task is to understand how differently we can use it to our best interest. It's not always true that what we CAN do, we SHOULD do. Sometimes there is a freedom entrusted upon Developers with this responsibility.

Let's take a real life example. We have roads with printed lines to show different lanes. It is in for the sake of effective traffic management that we should follow lane discipline. But we CAN drive the car such that we are sharing 50% percent of both lanes. It can be done but would create havoc. Now the question is SHOULD we really do this ? Definitely Not. Similarly in programming we have some freedom given by languages or frameworks. I will take an example of Java programming language. In Java we CAN have many methods in a class. Few may be public and others private. We justify that we should not have a single big method hence we should divide it into smaller ones. Since that logic is specific to that method and not to be exposed to the outer world we make them private. When you write test cases for the original method, you end up writing more code in the test classes to test that method. This makes testing a nightmare. It makes code refactoring even worse only because you have to resolve many failing test cases. Moreover its difficult to understand as well.

Java does not restrict us to write certain number of methods in a Class. But we SHOULD limit it based on our level of comfort considering factors such as TESTABILITY and READABILITY. I always consider these two factors primarily because small chunks of testable code is easier to refactor and has less impact than a bulky code (Obviously unless its properly mocked in the test cases during unit testing). Readability is important since we all know that 80% of the time is spent on maintaining a software than developing it. For maintaining it, we need to quickly understand it. Unless we understand a code we cannot refactor it with confidence.

Summing it up I would say that always try to understand what you are coding and don't write a code only because you CAN write. Always try to find the best way to write a code. Freedom should be used judiciously. Think beyond HOW. We always focus on HOW to use a language or framework but the true fun lies beyond it.