Transaction. Argument. Class. Message. Service. Agent. Method.

If you’re a technologist reading the previous list of words – Transaction, Argument , Class, Message, Service, Agent and Method – each of those words probably had a special meaning to you. Certainly when I read them I can’t help but mentally pre-pending  words like ‘distributed’, ‘atomic’, or ‘database’ to a word like Transaction. But as shocking as it may sound to technologists these are normal English-language words that have existed long before Babbage decided there were far too many errors in logarithmic tables, and have a broader meaning than the precise and narrow confines we choose to use them in. This is one of the  things that makes communication between technical and non-technical people even harder than it should be, and woe betide any programmer working on a system who has one (or…shudder several) domain objects whose names collide with these words that software development has hijacked. “Oh, you’re working on an event planning system for school classes? Here’s your cyanide pill.”

It gets worse once you realise that many of our narrow definitions of words are kind of at odds with their real-world “pre-technology” definitions. Transactions have existed ever since the first chicken was exchanged for the first sack of wheat (or something like that), and yet technologists have chosen to define it (fairly narrowly) as a unit of work (usually atomic, consistent, isolated and durable) against a software system such as a relational database. Only infrequently during database transactions is the ‘exchange or transfer of goods, services, or funds’ recorded. And while technologists don’t think of transactions as being exclusively atomic, consistent, isolated and durable it is more-often-than-not the assumption that goes along with the word ‘transaction’, so much so that a special type of transaction, deemed a ‘long running transaction’ has been created, which much more closely aligns with the normal commercial and financial sense of a transaction. Similarly parent-child relationships (in the context of software development and modelling) are at odds with the commonly understood human reality. In software development a parent-child relationship is often described as:

each parent can have many children, but each child has only one parent

While programmers and data modellers may reproduce asexually, most humans would consider a child to typically have two biological parents, making discussions of ‘parent-child relationships’ with non-technologists fraught with misunderstanding.

Fortunately the first step to solving a problem is often realizing that you have one, and so by recognising that the words that we (as technologists) use have broader meaning outside of technology, and that the misunderstandings arising from these differences in meaning can be critical, we can begin to put in place strategies that can close the gap. I think each project should draw up a list of domain words and technology words if they don’t already have some kind of glossary. If there are any domain words clash with commonly used technology words then just top yourself now. Or agree to pre-pend a word that disambiguates – no more mentioning of ‘transaction’ – something is either a ‘financial transaction’ or a ‘database transaction’. Similarly the subject matter experts should probably look at a list of commonly used technology words (like the one I’ve created below) and see if these are synonyms for business terms, and whether this could also be a source for confusion.

All the good words were taken

While it is not unusual for specialisations to adopt jargon (the term ‘stress’ to a mechanical engineer means something quite different to the rest of us), software development is in the unenviable position of dealing with a lot of abstract concepts that require precise terms to describe them. In the same way that history and mythology are chopped up in a blender to serve as the raw materials for many Hollywood films so to do human languages get chopped up into pieces by programming language designers looking to create easily-readable natural syntax. Here is a rough list of words I came up with that I thought had a better-than-average chance of causing confusion between technologists and non-technologists. Feel free to use it as the basis for your own list to help drive out ambiguity on your project:

• Transaction
• Service
• Event
• Message
• Aspect
• Agent
• Method
• Argument
• Key
• Exception
• Process
• Port
• Socket
• Map
• System

Comments