When coding standards and design patterns wont help you
We all have been through those phases in our lives as developers where we religiously followed coding standards and used the most appropriate design patterns. Before we got to that stage we would have been in a stage where we did not care what these meant or we did not even know these, and sometimes we will be in a situation where we cannot use them for some reason no matter how much we want to. In all these cases the job got done and we got paid. So, do we really need these? Do they really matter? Or are they just instruments of torture which more experienced and opinionated developers use on juniors? Is it possible at all to write a piece of code that is not coded as per standards, has no design patterns and absolutely no documentation and still works? Works without failing?
The answer is YES - read on to find out more about situations where ditching the best practices might be the only way to get there.
Keeping it short and simple (KISS) or Keep it generic?
In one of my earlier posts I wrote that when the developer cannot get his head around the abstraction of a problem in terms of a highly generic and configurable design, he builds the simplest possible solution with lots of hard coding which means that the solution cannot be scaled in the future. I made it sound that it was a bad practice.I still maintain that it is a bad practice. However, I will say that there are situations, and it needs special judgement to identify these situations, where not being generic is the way to go.
Think about it this way - when you write a piece of code, what is the probability that you will need to run the same piece of code for a different set of inputs? Or for example what is the probability that the code that you copy pasted and slightly altered in three places will have to be used in 10 other places and hence merits being put into its own method? In most cases you will find more scenarios where that code will be used or scenarios where you will run that code for different inputs. And in some cases you will write a few lines of code that will not get changed in the whole lifetime of the application. In the former case, it makes sense to write generic code and in latter case it makes more sense to just write the damn code and move on to more important things.
And it takes an intelligent decision to identify these scenarios.
The overheads of generic code
When we write generic code to satisfy more than one scenario, we almost always end up with
- Lots of methods and a long stack of methods calls sometimes very deep
- Parameters, hence local variables and fields and lost references to variables or unwanted references to variables beyond their scope
- Variables mean state information and state information can get corrupted by multiple threads accessing the same state or when we do not update state properly
- Configuration - XML, YAML, Property files and all the hell
- Not being able to change something without breaking a lot of other things or requiring lots of regression