Common misunderstandings of Software Developers

Software development is a complicated subject. There are many things we have to learn almost every day and it is important to understand these concepts thoroughly. Half baked understanding can lead to misunderstandings and this article lists some of the common misunderstandings of the software developers.

Following are some of the good things that software developers are supposed to follow,

• Test driven development
• Design patterns
• Keep it simple, stupid (KISS)
• Don’t repeat yourself (DRY)
• Use good commit messages
• Commit small changes

Now some of these maybe skipped at first time of coding a feature or fixing a bug but we have to make sure that we go over these once we complete the small changeset that we are working on. I have seen lot of software developers knowing all of these things but sometimes half understood and that leads to common misunderstandings of software developers.

Let’s go through some of them,

Test driven development (TDD) is very hard

Well, test driven development is not very hard but a different approach. Many software developers are accustomed to code first and tests later. When you shift from this approach to TDD, you feel it’s very hard.

One of the most important thing of TDD is breaking changes into very small chunks and then understanding the requirements for those small chunks. Once you understand the requirements then start writing test cases which are failing for the expectation and then start writing the code to make it pass.

I have taken this as the first point because this is one of the most common misunderstanding of the software developers.

Overuse of design patterns

When most of the software developers read about the design patterns, immediately they start thinking that I should use it everywhere! Well, that’s not the case. It is very important to understand that design patterns should not be overused. Keeping code simple and maintainable is the most important thing so the KISS principle.

Check if the design pattern fits rather than because you want to use it. Many software developers, when come across a new design pattern they simply try to fit it where it’s actually not required.

Obsession with performance

Any problem statement should be solved first. Once you reach to the solution and then you measure the performance and find that it’s sluggish then go for the performance optimization.

I have met many people, who are obsessed with the performance. An example is, using HashMap and synchronization over ConcurrentHashMap before even measuring the performance impact.

I am not saying that you should NOT think about the performance but rather complete the requirement and then in the second iteration check where you can optimize it.

Useless commit messages

Commit messages are one of the most debated topic. Almost in every company that I have worked so far, I have discussed this topic.

Commit messages should contain the information about the overall functionality change and not which file or class has changed! Everyone can check that from the diff itself. Following is one of the useless git commit message,

Changed RegistrationMailer class

One of the important point which in my opinion developers miss in the commit message is the bug/ticket/task id. Now you might ask why is it so important? Well, it’s important because if you want to understand the whole picture behind the change then this ticket id will help you. Simply open the ticket and go through the description to understand the whole picture.

Another good thing of having ticket id is the commit messages pushed to the JIRA which can help you to understand the complete story of how feature was designed.

Huge list of small commits on the feature branch

You must have heard this from someone in your company at least once. It is one of the trait that every good software developer should have.

Now, a common misunderstanding about this short commits/changes I have seen is the huge list of small commits on the feature branch and then a huge Merge/Pull request containing about 200 files!

It is very important to understand here is short commits means a short contextual change. Change should NOT be breaking anything and is complete on it’s own.

Well, that’s all for now, these are the most common misunderstandings of software developers I have seen so far.