share
Nobody is motivated to buy a development tool when the marketing pitch is “leverage synergy.”
Tell me if this sounds familiar: An online buddy listens to you describe a programming problem and suggests a tool that might fix it. You want to learn what the development tool can do, whether it works with your existing infrastructure, how much of a pain it is to use, and whether your company can afford it.
So, you go to the vendor’s website to learn more. Perhaps you download a brochure, or you view an “About our product” webpage.
Three minutes later, you go screeching into the night, running away as though the hounds of hell are pursuing you.
It’s not because the software is terrible. It’s because the marketing language chases you off.
Some marketing buzzwords are more painful than others. Maybe a vendor uses meaningless, trite descriptions. Or it presents a conclusion (“best-in-class!”) instead of describing the product features that help you reach that conclusion yourself (“The Turbo Ninja Plus is the only tool that has this unique feature – I must have it, or I will surely die!”).
How painful are these buzzwords? When I surveyed developers online, more than 800 people told me which marketing terms most make them want to scream.
For transparency: I must confess that Redis is guilty of using these marketing buzzwords. I do my best to stomp them out (I’m the editor, hereabouts), but you are sure to encounter these terms. (I do hope you poke around to learn more about Redis because we do have lovely software that, I promise you, does cool and unique things.) We’re working on fixing the buzzword problem, k?
Also, please be compassionate towards marketing professionals; it’s hard to be both creative and descriptive. Everyone tries to spiff up their verbiage, but it’s a losing proposition. Sportscasters soon learn that there’s a finite number of ways to say, “The count was 3-and-2 when the pitcher threw a fastball down the middle.” The intention is to make the copy interesting, but overused buzzwords become stale and abstracted terms that obfuscate, distort, and (most of all) bore.
Software developers understand that vendors must tout their products, but they are less understanding when the marketing language is an immediate turnoff.
But which marketing buzzwords tick developers off the most? I won’t make you scroll to the end. The most often mentioned, with the most fervor:
But oh, there are so many more buzzwords used in business and IT. I offer them to you for schadenfreude and desk-banging exclamations of agreement.
Several require an explanation, however, so I categorized the results.
Vendors attempt to hijack meaningful terms to support their own needs. It doesn’t work.
Many terms have a genuine meaning where the distinction matters. End-to-end is an easy example. In security, it’s important to distinguish between security at an endpoint (prevent someone from picking a lock) and how security works through an entire process (encryption throughout). But I’ve seen vendors discuss software as “an end-to-end solution” where it’s just noise.
When used correctly, telemetry refers to useful state data that helps IT professionals analyze, diagnose, or identify trends in a computing environment. When it’s a buzzword, developers and other techies hear telemetry as “a way for vendors to have far too much information about your environment.”
If it’s a technical description, it’s fine. If it’s hyperbole, it loses a developer’s interest.
Digital transformation is at the top of this list. Sometimes, clever people invent something new that becomes a game-changer. We can all point to tools and technologies that genuinely transformed our lives: GPS. HTML. The camera phone.
We also can admire the first development team at a bank that brainstormed, “Hey, if we connect our systems in such-and-such a way, people could scan paper checks to deposit into their bank accounts.” We admire the efforts of web development teams that built curbside delivery systems seemingly overnight. Those people can use terms like “digital transformation” without blushing.
But lots of marketing campaigns describe a trivial new feature as part of a digital transformation project. So do CIOs who want to present themselves as forward-thinking. I was going to list examples, but you don’t need them.
Best practices also is a real thing. It might be defined as “lessons you learned the hard way,” “the canonical method,” or “recommendations based on extensive experience.”
That isn’t how it’s mostly viewed in the wild, though. Often, it’s a vague arm wave. In the eyes of many software professionals, “best practices” suggests that a problem has only one right answer, which is not usually the case. When they see the term, they quit reading unless it’s from a trusted source.
However, we all know what’s meant by “best practices” – and so do search engines. Even if we dislike the term, it isn’t going away.
Agile, too, is real. The Agile Manifesto disassembled the waterfall development model. Of course, Agile has its detractors, as does any development methodology. I won a journalism award by explaining why users hate Agile development (and what developers can do about it), in which I shared wisdom gained the hard way (so that I wouldn’t have to write “best practices”).
But Agile as a buzzword has nothing to do with daily standup meetings or iterative development. Corporate management likes to use “agile” as a synonym for “flexible,” but they may as well write “supports capricious decision-making.”
Artificial intelligence (AI) and machine learning are important technical endeavors. They are changing the world in important ways, such as in finance, health care, and creating cool avatars to use on Facebook. They also keep ethicists busy.
But it seems as though any software that searches a knowledgebase is described as “AI-enhanced to deliver the best results,” and any application with an IF statement is lauded as machine learning. “It’s AI-infused!” they promise. Next up: “the new trashcan 5K, powered by AI!”
Special mention: Anything at scale, unless it’s backed up with clear descriptions about the steps to cope with growth. Scalability is fine. “At scale” often means nothing.
I admire the first person to invent the expression single pane of glass instead of writing “status dashboard” or “administrative interface.” That first use was imaginative.
The three millionth use of the phrase? Not so much.
When I asked on Reddit, Twitter, mastodon, and other online communities for the most-hated buzzword, so many developers spat out “single pane of glass” that I can assure you that using the term is the fastest way to chase away a would-be customer. Instead, use dashboard, status screen, or another descriptive term.
Similarly, the first person to make a “leading edge” pun by saying bleeding edge may earn a wordsmithing hat-tip. But that expression (and its sibling “cutting edge”) assumes that the technology or product is at the forefront of its field, which is rarely the case.
Then there’s tech recruiting. Once, in IT circles, rock star meant “master of this domain.” Hiring a “python rock star” or “code ninja” suggested that the developer’s skill went beyond coding, such as a conference speaker or book author. Today, some might say 10x developer (though that implies productivity rather than social status).
Over time, though, “rock star developer” came to mean, “We want a miracle worker because we have no idea what we’re doing.” And it’s said by people who forget that rock stars earned a reputation for poor behavior.
Some “they once were cool” buzzwords are less common nowadays, but they still give developers the heebie-jeebies. Among them:
Most humans aim to communicate clearly. And then there’s the other people.
Some obfuscation is an attempt to sound more impressive. For instance, a writer chooses a fancier-sounding word. Most of us don’t leverage a tool, nor do we utilize it; we use it. (There is a technical distinction between utilize and use and an appropriate time for leverage, but people fall asleep during my copyediting lectures, so I won’t impose it on you.)
In other situations, the marketing copywriting gets carried away, such as the developer experience. Not everything has to be an experience. The “login experience,” the “opt-out experience.” None of these warrant the kind of transformative sensory profundity their names suggest.
Yes, a developer’s experience does matter; it makes or breaks job satisfaction. But the product isn’t an experience. The way it’s used may be as part of the culture of the organization and the tool choices that a developer is given. Maybe the user interface matters – but I won’t go further than “the user experience” and only in the context of “software that makes you curse at the screen” or say to the computer, “Nice bot!
Similarly, accelerate innovation may be a well-intentioned expression because the vendor wants its customers to do cool things faster. But even amazing tools are just tools. It’s up to the humans to innovate.
And furthermore:
Fortunately, nobody is using “metaverse” in marketing to developers. Yet.
Some buzzwords are just noise. They make you wonder what the copywriter intended to say. Perhaps nothing.
For example, synergy is used to describe the benefits of combining technologies, products, or teams to create something greater than the sum of its parts. As an intention? Sure. As a marketing or corporate buzzword? No. Just no.
Finally, there are the unsubstantiated claims to superiority, including:
You can entertain yourself for hours (presumably during one of those meetings that should have been an email) with Buzzword Bingo, the classic Tech Bullshit Generator, Buzzword Ipsum, and the new-and-improved web economy bullshit generator. And, of course, for your musical enjoyment, you should listen to Weird Al Yankovic’s Mission Statement.
Let’s ditch the hyperbole and describe the product instead: what it does, whom it serves, and how it makes a developer’s life better.
I like to think that Redis achieves all those goals with database tools that deliver what they promise and make its users say, “Wow, that’s so useful!” Please do look at the tools we created. We’re mighty proud of them. (And we’re working to omit the buzzwords wherever we can.)
Try Redis now to find out why we think it’s so wonderful – and why we don’t need buzzwords to show the reasons why.
Stop testing, start deploying your AI apps. See how with MIT Technology Review’s latest research.
