The Rule I Followed to become a Great Developer

DISCLAIMER: The article is in no way an intention of bragging about my development capabilities. The intention is only to emphasize in so many ways on a rule which can surely, in my opinion, help developers improve quite a notch and become a better developer. I would like to reach as many developers as possible with an intention to create a belief in them regarding the principle I spoke. Thanks for reading the blog. Please feel free to share.

For several years that I spent in IT industry while working on a different roles and responsibilities such as developer, technology lead and architect, I was looking for that ONE THUMB RULE that would have made me a great developer. Additionally, I also wanted to know what rule could I follow to put great architecture or great software design? I always wondered if any such role even existed that I could have called UNIVERSAL RULE that I could use architecture, design and development phase. I also wanted to share this rule with others including fresher/junior developers such that they could focus more on solving business problems using IT and not get bogged down by software quality issues? Well, I knew my intention was great. But, whether it was possible to find such rule kept me researching.

Did it sound like me getting over ambitious? 🙂

Then, thankfully, Destiny pull happened!

I landed in a small software services company based out of Hyderabad which was bleeding with software code quality issues with its customer making major complaints on code issues and poor developers. Quite a challenge it was as I was better but still unaware of that thumb rule. This was the time I got my Eureka Moments!

This is when I got opportunity to try and experiment with what is called as “Single Responsibility Principle (SRP)“. The SRP principle is one of the SOLID principle which is primarily a set of principles for object oriented programming.

SRP recommends that every class or method should do just one thing and that’s it. In another words, the class should have just onee reason to change. The principle can be stretched to architecture and design. The idea is that every module or application should try and achieve one larger objective consisting of smaller functionality which could be split into multiple packages and classes.

Fine, but the question you may ask is how did it make me a great developer and how did it help me solve the code quality issue of the organization I joined. Valid questions.

This only principle helped me to write code of great quality in following manners:

1. Code Smells such as Long Classes/Methods Gets Nailed: I started writing comparatively small classes and methods which used to deliver just one functionality. This helped me to write cohesive code which can be termed as code of high re-usability. All of a sudden, customers started appreciating the developers as these code were easy to read and maintain. As a matter of fact, code complexity also decreased as a result of thee fact that methods and classes got smaller as a result of having lesser decision points (McCabe Code Complexity). This also led to code having higher test-ability as it was it easier to write good unit tests and achieve greater code coverage. Some of the popular & common code smells that were nailed upfront were long classes, long methods, duplication to some extent etc. This enhanced the overall code maintainability which is one of the key software quality characteristic as per SQUARE standards (ISO 25000).
2. Modular Design: In addition to benefits in coding, this also helped the team in accomplishing good architecture and design models for their projects. This is because they were able to segregate similar functionality into one module or application, and suggesting on different modules or applications for different set similar functionality.
3. Higher Code Coverage: The whole notion of writing code based on single responsibility principle also leads to writing classes with methods responsible for one unit of functionality. This, in turn, makes it easier to write unit tests that could cover various different tests for testing the unit of functionality.  This leads to higher code coverage.
4. Higher Code Usability: The classes and methods doing just one thing becomes easy to read and understand which in turn increases the overall quality of the code.

Today, if I have to suggest JUST ONE RULE for greater code quality, it has to be SINGLE RESPONSIBILITY PRINCIPLE. Let me know what you think about this.