The Secret to Fighting Buzzword Fatigue

A little while back, I made a post in which I mused about the work-retire dynamic as an unusual example of large batches in life. In the lead-in, I made passing reference to a post where I talked more specifically about buzzword fatigue. This is that post (with this explanatory paragraph pre-pended, of course).

It feels amazing, in an odd way, to give something a good name. You have to know what I mean. Have you ever sat around a whiteboard with a few people, tossing out names for some kind of module or concept or whatever, scrunching your nose and shaking your head slightly at each suggestion? “No, that’s almost right, but I don’t think that’s it.” And then finally, someone tosses out, “let’s call it the clobbering factory!” and all of your eyes go wide as someone else yells, “yes!!”

Names are important. There’s a certain finality to naming something, even when you wish it weren’t the case. Have you ever failed in the quest for the perfect name, only to say something like, “aw, screw it, let’s just call it ‘circle’ since it’s a circle on the whiteboard, and we’ll rename it later?” If you have, you can’t tell me that the thing’s official name isn’t still “circle,” even 3 years and 23 production releases later. You probably even once tried to rename it, grousing at people that refused to start calling it “The Phoenix Module” in spite of your many, many, reminder emails. It stayed “circle” and you gave up.

There’s an element of importance to naming that goes beyond simple aesthetics, however, when you’re naming a concept. Products, bits of code and other tangible goodies have it easy because you can always point at what you’re talking about and keep meaning from drifting. With concepts… not so much. Next to their tangible cousins, they’re like unmoored boats in a river and they will drift.

And I think that the amount to which they drift is controlled by two main factors:

1. Uniqueness
2. Mappability to known concepts in context

Story Time

Rather than go into a dry explanation of this, please bear with me for a bit of story telling. I think it’ll make my point a lot more vividly. Drawing from one of my emerging, favorite resources, fakenamegenerator.com, consider two people taking part in an interview: Ethel, the candidate and Katherine, the interviewer and boss. Imagine that this takes place sometime around 2004. You’ll understand why shortly.

Ethel and Katherine sat in Katherine’s office doing the standard interview dance. It’d been a long but successful day for Ethel, having held up admirably through a few rounds of technical screenings that included white board coding sessions, questions about manhole covers, and assorted other things designed to amuse bored software engineers at the expense of hapless job seekers. She’d run that gauntlet and Katherine was so impressed that she imagined Ethel could probably read through her attempt at a poker face.

When Katherine signaled the home stretch with the inevitable, “what questions do you have for me,” Ethel seemed confident. “I’ve spent the last nine months working on an agile team, and I really think that this is the direction software development is going to head. Is BlusterCorp agile at all?”

Katherine leaned back and pursed her lips, giving an outward impression of calm consideration. She was, after all, the boss here. What a weird question, she thought. Images flickered quickly through Katherine’s mind: a ballerina, a scooter weaving among stopped traffic, a high level, half-elf ranger equipped with a longbow. But none of those made any sense in context.

Katherine squinted a little as the silence became palpable, leaning forward to buy another second or two. She was the boss here, and in no position to be stumped. Ethel was a good candidate — how silly would she look? It must have something to do with how they develop software or interact, and being agile means like being flexible and able to hop around quickly… it must have something to do with their working hours and, maybe, where they work. Maybe they work fast…?

A half-formed though was better than none, so Katherine started babbling her way around the question. “Oh, absolutely we’re agile here. We move quickly as a group and there’s a lot of flexibility to how we do things. A lot of people have laptops, so you’re even welcome to work outside on sunny days if you don’t mind the glare. And we let people be flexible with hours, though we work hard and aren’t afraid to go the extra mile after hours if customers are having problems. We’re pretty nimble in making sure we respond to their needs. So yes, we’re definitey agile.”

Ethel narrowed her eyes briefly, considering, but then smiled. I’m not sure Katherine understood the question, but I believe her when she says she’s agile, and maybe they do a different kind of agile here. If they make an offer, I’ll have to remember that part of being agile is working where you’re needed, when you’re needed. That makes sense.

And so, on that fall afternoon in 2004, a small redefinition “agile” software development was born. It wasn’t the first, and it wouldn’t be the last. Whatever the original, ‘official’ definition of a term like that might be, it is constantly redefined in the trenches.

The Pseudo-Code of Redefinition

In that story, Ethel started with some imperfect, but fairly standard, definition of “agile software development.” Perhaps she’d even read the manifesto. Katherine had never heard of it. But she did know what the term “agile” meant in the English language, and she understood its use in a variety of contexts. After all, “agile” is a pretty versatile word that can mean a lot of things.

The two parties were able to carry on a conversation centered around a word for which they had markedly different definitions. This is only possible with a term that is (1) common in the vernacular and (2) highly mappable to known concepts. Humans are remarkably good at inferring meaning from contexts and reading non-verbal cues, so it’s entirely possible for two people to throw around a term that means different things to them initially and to converge loosely on some definition. It might be the right definition or a fantasy. It might be one person’s definition or the other’s. They might just trade non-sequitur for a bit and move on. But whatever they do, they’re altering canon. The definition of the term changes ever so slightly with each conversation because each party will go on and use it with their new frame of reference in future conversations.

The dynamic is altered with a unique term. Imagine if instead of asking what she did, Ethel had asked, “Is BlusterCorp mogotrevo at all?” (This is a made up word, courtesy of FakeWordGenerator). Katherine would have had absolutely no idea what Ethel was talking about. It would have been impossible for Katherine to form any sort of context, so no matter how blustery she was shy of being a master beginner, she would have been forced to swallow it and say, “I’m not familiar with… mogotrevo… what does that mean?”

Similarly, this is not possible with a term that cannot be mapped to known contexts. Imagine the question as, “Is BlusterCorp motorcade at all?” That’s a word that Katherine certainly would know, but the sentence is nonsense. Again, Katherine would be forced to ask for context or definition. The two couldn’t fudge their way through, mangling the definition.

Let’s say that we could more or less model the lifecycle of a given term this way:

public void SpendUsefulLife(Term term)
{
    while(!term.IsMeaningless)
    {
        var ethel = GetRandomPerson();
        var katherine = GetRandomPerson();
        Globals.UseInConversation(ethel, katherine, ref term);
    }
}

A term is born, probably in a room with a whiteboard and people shouting, “yes, that’s IT!” Then it gets passed into this method where it’s used until it’s useless. Before the loop guard allows exit, countless people have conversations involving the term. In each case, the two people have their own internal representation of the term’s definition, and the term has a broader, societal definition. I’ve made the term parameter a reference parameter to underscore the point that each conversation alters the definition of the term to some degree, however slight. Eventually, the term becomes useless, blowing up into enormously broad use like some kind of buzzword red giant, before collapsing into a useless, brown dwarf husk of a buzzword. This means that there is a concept of usefulness that is intrinsic to the term itself and that this property is mutated with each use. So not only does the definition change, but any conversation may be the tipping point conversation that ruins it for everyone.

The contents of UseInConversation, I think, would be utterly fascinating, but are beyond the scope of this post. It’s kind of late and I’m tired. I invite people to riff on this, though. I think you could represent it with an increasingly sophisticated algorithm or perhaps some machine learning. Slap some sensible constraints on there, and we could certainly have fun with it. The only ones that are relevant here, right now, however, are the notions of uniqueness and context mappability. When Ethel and Katherine talk, if either of them has a null value for the term in the context of the conversation, then the term is not altered. I would also posit that one way definition conversations like that imbue the term with a “drift resistance” as time goes by, meaning that such terms become a lot harder or perhaps even impossible to kill.

Examples and Wrapping Up

Think of fad terms that are the most groan-inducing over the course of time. The ones that you can hear sales/marketing folks, consultants, managers, recruiters and the like bellowing past one another, blissfully unconcerned with their meanings (not that you programmers are always above this, either, mind you). Agile is certainly an iconic example. But think of other current ones: lean, influencer, software as a service, disruption, pivot, craftsmanship, minimum viable product, microservice, and so on. These are all words that have some amount of industry meaning, but anyone hearing them could limp along, faking it, grinning, and altering (degrading) the definition.

But they do eventually die, and go to rest in a forgotten, overgrown graveyard. Anyone remember the term “hyperlocal” from about 2009 or 2010? How about “microblogging?” “Transliterate” as a term for people that use different media? “Blended learning?” “Speed networking?” All of these are things that were easy to map to context and whose understanding could be faked since most of them were just combinations of words that people already understood.

Think about a different set of concepts, though: Scrum, Kanban, A/B Test, Test Driven Development, Search Engine Optimization, Gamification (ish). All of these are terms that people wouldn’t know or else would be hard-pressed to map onto a context other than the originally intended one. Those are the terms that last.

In the end, buzzword fatigue arises from the re-purposing of familiar terms for new concepts. So as much as we’d like to blame the various buzzword spouters for this, they’re really just showing up and saying, “hey, dudebros, what are we talking about — oh, yeah, I know what literate means and I used to drive a Trans Am, so I’m a totally transliterate dudebro!”

The moral of the story is that only you can fight buzzword fatigue, especially for any terms that you coin. When coining a term, take care that you’re calling it something that prohibits any context inferences at all. Or, for goodness sake, make it a new, unique word (not just two common ones slammed together). Otherwise, down the line you’re going to be doing the world’s most intense facepalm when a recruiter with no idea what it means asks you if you have 12 years’ experience with something you invented 3 years ago.