I just heard a new one today. On the topic of “software development and coding standards” have you ever heard of “Grave Naming”?
I guess it refers to the practice of standardizing specific domain (value) names across development layers. (…from the cradle to the grave)
For example, if you have a concept of Customer. That customer might have an account number. You don’t want to call it “CustomerID”, because this is a human-generated number, rather than a DB auto-number. Since you are following good design practices, you know better than to do that sort of thing. You also want to make sure nobody else calls it that, especially in code or DB, etc. So, you pick a good name to standardize on. The Customer’s account number will always be called “AccountNumber”. Then you enforce the use of that name in all of your tech/arch layers: DB, configs, screen fields, classes/interfaces, and everything else that an IT person would use it. There are no exceptions allowed.
Your marketing or HR folks can come up with cute names like “the Hug Tag” or “Smile badge” or “Customer ID”. Whatevs. You and your team never call it by an unsanctioned name, when speaking with each other. We know you cannot train the marketing folks, but you can train your own people.
The concept behind “Grave Naming” is that it is easier to find/trace data as it goes through a system if you use consistent standardized names. Many companies do this sort of thing by creating their own local jargon. The “Grave Naming” concept just takes the idea of jargon to a higher level, by applying it to IT and turning it into a form of standardization. In the end, it makes things easier when you are consistent across all layers and components of your technology stack.
On paper, it sounds like a pretty good idea. However, I imagine it could be pretty difficult to create a “Grave Naming” standard at some big companies. Depending on how large or segmented your organization may be, it might be nearly impossible to enforce. As a principal, I can see how it would make a huge difference (in a positive way) at large organizations who are currently segmented and suffering from the side-effects of it. However, those people are more-likely suffering from the side-effects of their organization size and the natural fragmentation (and conflict) that commonly goes along with it.
So, from a strictly-academic standpoint, it is an excellent idea. Now… if you can just convince your VP(s) to mandate that everyone follows this standard (because it saves time and money and reduces errors), then you have really got something good.
Remain steadfast, my fellow elitists.