Linguistics Crisis In Microsoft Technology


With technology expanding in both complexity and quantity, the task to name each component and functions of a technology product becomes more daunting and thus creates the room for confusion and dubious meaning regarding terms used to explain the technology itself.

As a long time SQL Server DBA, I start to notice this linguistics “mess” probably from SQL Server 2005 when I see terms like ‘securable’, ‘facet’. 

‘Securable’ is, strictly speaking, an adjective, but it is now treated as a noun in SQL Server, while ‘facet’ is a word I bet not many people know or use. To me, it is the same as ‘property’, which is way easier to understand.

Is it a big problem? No, of course not at this time, but can we have better and more meaningful words to replace them? I think so.

The even worse naming convention are found in SQL Server Extended Events terminology. For example, in sql server trace, ‘column’ of the trace is now called ‘action’ of the XE “session”, I just do not get it why this change is necessary or what advantages this change brings other than confusions. There are also numerous names that make you scratch your head. For example, there is an action called “task_time”


But I just do not know whether this means a time point, i.e. the time when the current task executes or a duration of time, i.e. the duration that current task executes.

Another example of an action “task_elapsed_quantum”, what does this mean?


Actually, there are many other places where reading MS documents (or message without any documentation) can drive you crazy and you really want to give up.

This kind of linguistics mess is not only happening to sql server, but also to other products. For example, .Net Core, .Net Standard, .Net Framework. But to my understanding, .Net Standard is better to be called the “Standard of .Net” to reduce any confusions, i.e. .Net Core is an implementation of the “Standard of .Net” (various versions).

Recently, in Azure domain (“Azure” itself is also very awkward in pronunciation) , Microsoft named one product as Microsoft Graph, again this is a very anti-intuitive name because graph really means graph, something related to picture drawing.

I’d like to define Technology Literature (TL) as the collection of technology documentation about product introduction / features, operation manuals, user guides and best practices etc.

TL is actually an ultimate User Interface between technology practitioners and the technology products. Microsoft does not do very well in this regard. I personally guess this is because most of people in Microsoft are STEM graduates instead of English literature graduates. As such, they usually generate less reader friendly TL works and they do not care. Or worse, some people who come up with those “weird” or “dubious” terms may feel proud of themselves as if this can prove their vocabulary superior. It will be very unfortunate if people think complexity and big-word description means better products (like Extended Events feature in SQL Server). I somehow do have this feeling towards SQL Server XE, which is still less used by DBAs than SQL Server trace (either via Profiler or Server side traces)

The long term impacts of low quality TL is you will lose your “readers” (i.e. IT practitioners) gradually, esp. the new “readers” will simply not “read” your works if there is better TL (from new or old competitors) somewhere.

I think Microsoft as a vendor of producing huge amount of software products (thus lots of TL works) should create a position called Chief Linguistics Officer (CLO) or establish such an office to take care of all these TL related work, like product naming, product feature designing and documentation. They probably can start by first creating a list of words (like 3000 words) that are allowed to use in naming and documentation, then making some other rules to ensure better quality TL.

I just hope, someday, in IT world, there will be a competition for “Nobel Prize Of Technology Literature”. Not until then will CEO pay enough attention to TL.