A plea against IT abbreviations and upper-casing

Every project I have worked on there is an abundance in abbreviations used for almost anything, from project names (codes) to mappings, (source) systems, workflows, team member names and database attributes. Even worse, the meaning of these abbreviations is lost or vague and in some cases even wrong (because the ‘real’ abbreviation is already taken)! Every time I feel it makes it so much harder for new team members to grasp the meaning of the system and/or organisation and I keep wondering if fully writing names is really that much hassle.

I say use abbreviations only for recurring technical functionality like functions/stored procedures and operators in ETL mappings.  For instance an abbreviation SP for a stored procedure or EXP for expression is perfectly defendable.  But why shorten BATCH to BTCH for instance, or PARAMETER to PARM, or make abbreviations of types of document (TD, FD anyone?).  The worst are the abbreviations in column and table names, where really the model should be easy to read. The argument to use abbreviations is often that it’s too much hassle to type in full names when using an SQL client (time, typo’s). But really, how often does that happen. And is it really that bad? I think the time to write queries with regularly named tables and attributes does not outweigh the ease of use and ‘readability’ of the model, (documentation) set-up and (ETL) programs. In the end it should all be about making the management information system future-proof and manageable and not be easy to query  on database level (note: not DB-level here) by the DBA’s or developers.

The other argument is often query speed and storage, but again is that really a viable argument nowadays? The price of storage is many times less than a hard-to-understand system.

That said, abbreviations have their use and it pays to follow the guidelines, naming convention or best-practice for the tools you are using in your project. But, if you try to use abbreviations only for (documented) recurring functionality in code I think you’re doing well.  And of course industry accepted abbreviations like ID or NR are allowed :).

A little side note, source systems are usually abbreviated as well and it pays to design a little metadata system around these definitions to make sure the abbreviations and source systems are defined in a single spot in your system. The ‘end-game’ of the management information system is usually about having overview of the integration with the rest of the organisation and it pays to store which (types of) interfaces from which source are going in and out of your DWH, and what they all mean. It will make the handling of changes much easier and keep the troubleshooting easier with the ever-changing team. And as a plus you will be able to report on it too!

The same is true for upper casing, this too seems like an old-school IT leftover. Again, in times where the design and development is much less technical than it used to be it pays to keep the system readable. And with upper casing this is quite literal. In some cases you really have no choice like with some database management systems, but many tools allow you to use lower case or CamelCase. Why not use it? There is much research on the way the information is processed by the human brain in regards to the upper or lower case to back it up :).

 
Roelant Vos

Roelant Vos

You may also like...

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.