Single Most Important Advice to Programmers
I have been a programmer (or, more mystically, software design engineer) since the early C language days. I am old and wise, so please listen like a padwan to a master jedi.
No matter which programming paradigm you use — object oriented language and design patterns versus functional programming, or assembly language versus high-level language — one thing you need to heed is the principle of having a single physical location for every variable or object. You could be adept in several design patterns, but if you forget this principle, your skill is not worth much. Why is this so important?
Programming is the art of building something while minimizing the introduction of bugs. Your idea may be most brilliant, but if it doesn’t work because of a bug, or you or somebody else have to spend the time to fix your bug, then your idea is not realized and wasted.
What does it mean to have a single physical location for each variable or object? Variables live in hierarchy: from the most local to the most global. The most local variable is one which can be stored in a CPU register. Procedural languages like C allows the programmer to declare a variable anywhere — from within two curly braces, all the way to a global immutable variable (constant). Which pair of curly braces a variable is declared determines its locality. The principle of having a single physical location for each variable means that, every variable has to be declared at the right level so that if there are two variables that mean the same thing but are declared separately (in C this means a variable which refers to the same thing is declared in two separate curly brace pairs), then you have a big problem.
In object-oriented languages this same principle is embodied in the principle of least coupling between objects and encapsulation: a class has to be self-sufficient such that whatever it needs outside of its definition is declared as an interface, as a configuration parameter, or even as a column in a database table.
In build scripts, this principle means having a single file that defines ALL configuration variables. Most software engineers understand this, but don’t give it the importance it deserves. I can understand because I’ve been there: “Why bother when I can clearly see in an instant that this constant I declare in this file is the same constant I declare in another file (possibly even using a different name)? When I modify one, of course I modify the other too. What’s the fuss all about? Besides, if I combine the two configuration constants, I would have to modify a bunch of other source files. It’s not worth it.”
The problem, my dear engineer, is that you have just introduced a serious problem which will bite you or somebody else in the future. Of course, right now, at the heat of coding, it’s easy for you to remember that the two separate but same configuration constants need to be modified as one: simply edit two files instead of one. However, give it a month or even just a week, and you would have forgotten about this “minute detail”. A week after you’re done coding and everything works, your dev lead changes the requirements such that you will have to modify the same configuration parameter (among other changes necessary). Chances are you will modify one file only; and boom, you have a big bug. You are lucky if this bug manifests itself immediately and all you waste is a few hours of debugging. What if the bug is subtle and won’t manifest itself until after release? Then this one bug can potentially bankrupt the company you are working for, if it is so serious and not fixed immediately.
If you have at least a few years’ of programming experience, you should know that the earlier you catch a bug, the cheaper it is to fix it. The most expensive bug to fix is that which is not caught until after release. All the programming tools and languages you use are designed with this most important objective — to catch bugs as early as possible and even to reduce the probability of introducing a bug in the first place. All these tools would be for naught if you yourself don’t see the importance of the principle of having a single physical location for each variable, constant, or configuration parameter.
