Rules are mostly made to be broken and are too often for the lazy to hide behind. – Douglas MacArthur
For the past few weeks, there has been tsunami of debates going on about the principles and rules being followed in the programming world. First initiated by the stackoverflow.com podcast and again triggered by recent CodingHorror post.
Its true that more the rules, more the complexities and constraints. If we just go through the time line of software industry, we can get more and more rules / principles / best practices recommendations as more mature the industry has become or is becoming. The rules and principles of object oriented development that have become popular since early 1990′s or so are the foundation of current software industry trends. But just imagine the beautiful yet complicated world of software development without these doctrines?
Jeff and Joel have been especially critical of Unit Testing and Uncle Bob’s SOLID principles. It is true that there has always been debate among the experts about the magnitude of unit testing your code. While some people may unit test only core components while other may test each and every aspect of their code. Whatever approach people follow, both will be productive and /or counter-productive to some extend. But if we compare the scale of effect between productivity and waste of resources as a result of unit testing, there will be and there has always been in most cases where people have achieved earlier aftermath rather than latter one. I just want to say that yes you can ignore unit test completely and even after that write kickass code but criticizing the concept of unit testing seems to be act of being ignorant especially when you are such a senior programmer. I am also new to unit testing and sometime feel why the fuck I’m writing dual code (original code and unit testing it). But being a rational programmer I will and always follow the industry standard principles and guidelines and I am feeling that my abilty to write clean + resuable code is improving day-by-day.
Jeff and Joel have been especially critical of Unit Testing and Uncle Bob’s SOLID principles. It is true that there has always been debate among the experts about the magnitude of unit testing your code. While some people may unit test only core components while other may test each and every aspect of their code. Whatever approach people follow, both will be productive and /or counter-productive to some extend. But if we compare the scale of effect between productivity and waste of resources as a result of unit testing, there will be and there has always been in most cases where people have achieved earlier aftermath rather than latter one. I just want to say that yes you can ignore unit test completely and even after that write kickass code but criticizing the concept of unit testing seems to be act of being ignorant especially when you are such a senior programmer. I am also new to unit testing and sometime feel why the fuck I’m writing dual code (original code and unit testing it). But being a rational programmer I will and always follow the industry standard principles and guidelines and I am feeling that my abilty to write clean + resuable code is improving day-by-day.
And going to the next topic, I feel criticizing SOLID seems kinda act of irresponsibility. In the world of object computing, SOLID defines the contextual boundary that I take as parameters for making self judgment of my code and measuring myself. For people not familiar with SOLID here is a short intro or you can just google.
- Single Responsibility Principle: A class should have one, and only one, reason to change.
- Open Closed Principle: You should be able to extend a classes behavior, without modifying it.
- Liskov Substitution Principle: Derived classes must be substitutable for their base classes.
- Dependency Inversion Principle: Depend on abstractions, not on concretions.
- Interface Segregation Principle: Make fine grained interfaces that are client specific.
- Release Reuse Equivalency Principle: The granule of reuse is the granule of release.
- Common Closure Principle: Classes that change together are packaged together.
- Common Reuse Principle: Classes that are used together are packaged together.
More information about SOLID can be found here.
Okay for now just forget about Jeff’s post but just look at those comments. After reading some of them I feel the state of dismay at the current state of software industry and came to know there are some people in the world who says GoF Design Patterns is a crap and some just don’t need any rule (kinda cowboy coder).
And the list goes on…
Conclusion
Being a beginner in software world, I may not be appropriate person who could criticize experienced and techies like Jeff and Joel. But sorry guys I don’t give a fuck! I will express my frustration if I’m not satisfied with others’ thought. It’s my right 
And I also don’t claim that I can follow each and every rules and best practices but still I am trying and will try to write code following them. I want to take programming as the art of craftmanship rather than cowboy work. In my opinion, there are programmers who code to get paid and there are some who code not only to get paid but also as a chance to learn and improve continuously. So, what type of programmer are you?
Yes you can write kickass code by not following any rules or just by creating your own rule but the question is how are you going to compare the quality of your code without these principles and rules?
Readers what do you think?
The title of this post has been taken from this tweet.
