The Power of Language in Technology (and why I don't use QA as a verb)
Language is the most powerful asset available to our species. It is the facility that allows us to interact with each other, convey meaning, express our viewpoints, and influence thinking. The language we use is both a product of our mental constructs, but also a conduit that affects the formulation of those constructs. It is so intertwined with the models we create to make sense of our world and the metaphors we use to explain our ideas that it cannot be treated independently of a more holistic view of human cognition. Over time I have grown to appreciate the powerful influence language has on thinking and behavior and now I more explicitly consider the words I choose as part of system, process, and organizational design.
Language and the Scope of Influence
I'm sure you've heard people say "I'm a visual thinker—I prefer to draw a picture than write a paragraph". The impact of the spoken and written word is sometimes devalued in favor of visual representations of concepts and designs. I do not argue the importance of graphical expression as a powerful multi-dimensional medium for thinking and communicating, clearly the best and most efficient way to express complex relationships and dynamics in system design. My argument is that the written and spoken descriptions of these systems—the labels we choose, the metaphors we invoke, the actors who participate—have the potential for lingering persistence and broad dissemination using the most available channel for human communication. Words create mental images and frameworks that then get passed to others in the way we describe them. They are the serialization of complex objects that can be transmitted over bandwidth-constrained mediums, like casual speech and undecorated text, and therefore lend themselves to the propagation of concepts in a viral way.
The relationship between words and concepts and the visual representation of things is well studied. In The evocative power of words: Activation of concepts by verbal and nonverbal means, the author states:
"[...] words are not simply a “pointer” or a means to access a nonverbal concept. Rather, they provide a special way to activate the multimodal representation that constitutes the concept. We have argued that verbal labels activate conceptual information—the visual components, at least—(a) more quickly and accurately and (b) in a less idiosyncratic way."
Given this powerful relationship between the words you use and the concepts they enrich, along with their facility for widespread dissemination and influence, it is worth thoughtful consideration when constructing the narratives that support the ideas that you hope to persist and upon which you build complex systems.
The Names You Choose
As a former software engineer, I've always thought that one of the most fun and creative aspects of this profession is that you get to create your own worlds and name the things in them. The names you choose for classes and functions, attributes and variables, components and services—all contribute to the complex world you are building, and communicate not just behavior, but relationships and scope. These choices you make are as important as the names of characters, places, and organizations in a novel or movie script. Imagine if the opening line of Moby Dick was "Call me Brad". But beyond setting the mood and a suggestion of importance, the kinds of words we use in system design suggest the overarching gestalt of the system itself, and this is a fundamental factor in how the system will be perceived and used.
Consider one dimension of a high-level system design—the makeup of the components that provide the foundation of what you are building. Some systems are inherently action-oriented. The services you build perform actions on objects or data, processing them, transforming them, moving them through a pipeline, or triggering other processes based on the results of the actions taken. The primary players in a system like this are the engines that do the work and as such are verb-like; the secondary players are the objects being processed, and tend to be noun-like. The overarching orientation in a system like this will place emphasis on those processes and the services that perform them, and the nomenclature and paradigms we use will reflect that. Now imagine a system that is fundamentally about entities or objects and their relationships. Each object in a system like this might have an interesting lifecycle or state model, but these dynamics are subordinate to the entities themselves. In a system like this, the primary actors are noun-like and the secondary aspects are verb-like. The decision about whether the highest level metaphor for the world you're inventing is predominantly verb-oriented or noun-oriented will shape how you describe the system, and the names you pick will reinforce or dilute that metaphor. Thoughtfulness around this aspect of your design language is oftentimes lacking.
Choose Your Metaphors Wisely
The biggest challenge in designing complex systems isn't picking names that match your metaphor but deciding what that metaphor is, taking into account the words you've already started to use when describing your design and the influence they have had on your thinking. The linguistic decisions you make during the formative stages of design not only affect your conceptualization but also the way a larger audience will perceive your intent. A well-considered design tends to hold together and naturally fit with the language you use to describe it. Nomenclature that feels arbitrary or forced is an indication that your design isn't yet entirely coherent.
In the seminal book Metaphors We Live By, George Lakoff and Mark Johnson explore the impact our experience in the physical world has on more abstract concepts. They describe as an example the commonly used metaphor of war as applied to argument or negotiation. This metaphor runs so deeply in our culture that it has shaped the language we use to describe argument and how we think about argument as an adversarial activity. From the book, consider these examples:
The authors invite the reader to imagine how our language and thinking would change if we applied a metaphor of dance to the same concept. Not only would the phrases we use be different, but the way we think about the topic would be so fundamentally different, that it wouldn't be argument at all. In fact, it's hard to even conceive of such an alternate metaphor working in this case, because we are so deeply conditioned to think about this activity in terms of the metaphor that's been applied as long as we have been old enough to consider it.
The metaphors you use, accidentally or by design, in the work you do are not likely to have the impact on language and culture as something so deeply seeded as argument as war. But it's not much of a stretch to realize that the metaphors you do invoke affect more than just how people talk about your work—it impacts how they think about it at almost a subliminal level. It's enough to give one pause as you approach the whiteboard.
Design for Emotion
I recently read an article by James Courier of NfX about the steps to consider when naming your startup. In this article, he asks:
"Why does a name matter so much? It’s psychological. People often aren’t aware of the impact your name is having on them. What emotions it evokes in them. Whether they think you’re strong or trustworthy or friendly or expensive. It sets expectations of your company in the blink of an eye. And first impressions are hard to change. Both positive and negative."
The psychological implications of the language you use extend beyond the name of your company. Consider the name Human Resources and consider the emotions it evokes compared to some trending names for the same function: People Operations, Talent Management, or Employee Experience. Consider the difference in feeling you get from Customer Support versus Customer Care or Customer Success. The impact of the feelings conveyed by these names might seem insignificant, but they affect the people who work in and with those departments. The names set the tone for company culture and shape the charter of those organizations. It is not superficial.
Does emotion play a role in system design? Beyond the sometimes silly choice of terms that software engineers are known for (I admit, guilty as charged), anthropomorphism is a common device used to describe actors and components in systems. It's effective and evocative to describe the actions, responsibilities, and relationships between aspects of a system in terms of human qualities and behaviors. The human traits we attribute to components give the system a certain personality and make the behaviors of those components more predictable (assuming they act in character). We talk about what a component knows, how it's constrained, and the job it performs. This seemingly trivial use of language is actually a powerful way to convey complex behavior in a way that is memorable and extensible—you don't have to know all the details of the system to know what to expect, and you can imagine how the system might behave in the face of new conditions.
Describing Teams and Processes
Earlier I touched on the nuanced emotional impact of a department name—Customer Care, Employee Experience, etc.—on the teams that make up and interact with those functions. There's a deeper connection between how we describe processes and the teams involved in them that is worth consideration. As we design our organizations and make decisions about roles and responsibilities, we think about the locus of control and whether decision-making is centralized or distributed. Often it's a combination of both, with clear ownership and authority for certain matters and a more decentralized process used in other areas. One example is spending authority, where approval is allowed at the department or team level up to a certain amount of spend but requires executive sign-off when the amounts are higher. How does language impact the way we think about ownership and responsibility?
I have a certain point of view about testing (software product testing, in particular). How we test is driven by the risks we face, the cost of non-compliance, the nature of the product we're building, and the resources available to address these concerns. Testing strategy is multifaceted, and the individuals and teams involved in its execution bring different perspectives, skills, and areas of focus. Central to my thinking on this topic is that it is not performed by one group. When it is, that group is usually called Quality Assurance. My opinion is that while a comprehensive testing strategy might involve testing specialists with QA in their title, it is best considered a cross-functional endeavor. Developers, QA engineers, analysts, product specialists, and even users or user proxies, play a role in delivering products that meet the quality objectives of the company. Not just QA.
As a result of my viewpoint on this matter, I avoid the use of QA as a verb. I know, companies would kill to have their company name used as a verb (Google, Uber, Slack, Zoom, etc.), but when people talk about QA'ing their software, they are reinforcing a subtle placement of responsibility on one group—the one with QA in its title. Call me pedantic, but I think it matters.
Whether or not you agree with my perspective on software testing, I would urge you to consider the impact of language on your organizational design and the way you want work activities and responsibilities to be seated in the company you create. While it may feel like an arbitrary exercise in naming well-known functions and teams, the subtle impact it has on company culture and norms of behavior is not so trivial.
Reflecting on the Words We Use
As a teenager, before I was introduced to writing software, I was planning on being a writer of prose. I enjoyed writing short stories and essays because it gave me control and freedom over the language I used, the literary devices I could employ, and the effect it had on the reader. When I got into writing code, I found some striking parallels. I could pick programming languages, leverage frameworks and patterns, and see their impact on achieving what I set out to build. I have always drawn strong similarities between the creative writing process and the process of software design and implementation. I also see parallels between software design and organizational design, so the similarities to writing apply there too. Perhaps these associations reinforce for me the importance of language in technology.
There is a stereotype, and a pejorative one in my opinion, of the brilliant software engineer who doesn't do well in social situations and isn't particularly good at communicating with non-techies. This stereotype devalues communication skills in the tech world and therefore reduces the importance of language as a fundamental skill in the design process. I would argue otherwise. Independent of the organizational and cognitive implications of language, the artifacts we create (e.g. source code) are communication mediums that contain profound value beyond the functionality of the products they implement. The ability of a technology artifact to accurately communicate the design intent of its authors factors into an organization's ability to manage tech debt and extend, adapt, and maintain a company's crown jewels. A thoughtful treatment of language in all aspects of our technology-based business should be a core competency that we embrace and teach. Language matters deeply, perhaps more so than is commonly considered, in what we create and how we create it.
Catylex | Driving Customer Success
2 年Great article: written words are so important. It make me think that we need to invest in reading as a skill set, especially in younger generations. Too often they default to images and one liners.