Technical: Function, a quite handy word, was conscripted by mathematicians
— a group that combines an admirable respect for precision with an utter disregard for what words already mean and a deep distrust of anything time- bound. The word’s roots in notions of utility were chopped off, its purposive branches trimmed; it was repotted in an abstract relational container. Programmers, whose views of language are quite similar to those of mathematicians, then found it on the shelf and started using it for bits of programs (subroutine was already in use, but had plebeian overtones, and people who spend most of their day in office cubicles tend not to like where the word routine leads them). Once function was co-opted for portions of programs, however, the programmers were left unable to use it for what it normally means. Hence functionality, which essentially means the same thing function would if the latter had not been mugged by Leibniz.
Marketing: Clients think the value of something technical is positively correlated with the length of its name, so functionality is over 50% more advanced than function. Look! Suffixes! Shiny! Shiiiinnnnyyyyyyy! Functionalizationismaticities would be even better, but clients might catch on to what you’re up to. Also, saying that the program “has additional functionality” lets you present all the new things it does as equivalently useful, even if the majority of them turn out to be the kind of thing only someone who gets an interesting score on Autism Spectrum Disorder diagnostic tests would want.
(actual search results for functionality from the Corpus of Contemporary American English)
This one’s pretty much a lost cause, really. Trying to use plain function(s) will confuse programmers (who, after all, are just trying to do their jobs), and most sales reps are constitutionally incapable of talking about what a product actually does, instead of spouting catch-
phrases and slogans. We suggest limiting your response to glaring balefully, which you ought to be doing on general principles anyway (blaring galefully is good too).
Technical: Many programmers are not native English-
speakers, and many who are do not approach dictionaries with a cooperative attitude, or at all. Presumably, at some point deprecate and depreciate became confused in the programming community, and came to mean “obsolete, not to be continued.” Programmers can, apparently, now simultaneously praise a function and deprecate it (“Yeah, it’s really elegant, but it doesn’t work with the new API”).
Marketing: While sales reps do occasionally use this word, there is little evidence that they attach even the small amount of meaning to it that programmers do. They apparently view it as some kind of mantric group-
Increased need for self-
control during technology committee meetings; avoidance of comments such as, “Oh, did they impugn the function’s personal hygiene, or just cast aspersions on its mother?”
Another horse well away from the barn, alas. Tech support ignores references to the OED; marketing reps have absolutely no idea what it is, and no desire whatsoever to read something not easily reducible to a slide presentation with perky clip art. Still, a firm red line through all misuses of the word can’t hurt, and may make one feel better.
Technical: Mathematicians are at work again for this one
— they tend to get in everywhere. Given an equation with multiple variables, there are frequently multiple, even infinite, values that will satisfy it, so “solving” it involves specifying multiple answers. And since these are numeric proportions we’re talking about, a given value (assuming the other variables are pinned down) will either satisfy the conditions or it won’t. Programmers picked up this concept and broadened “solution” to “set of choices that will let me do X.” This works splendidly if X is the kind of thing that you’re sure is either done well or not at all (and your average programmer had really rather work with that kind of X if at all possible). When applied to complex, real- world institutional problems, however.... well, it helps to put a brave face on things.
Marketing: Calling something a “solution” implies that it will actually solve the problem, without all the pesky legal effects of actually claiming that it will. If someone says, “Oh, I’ve got a solution,” and it turns out not to work, you typically consider that person to be wrong
— but not a liar. The implication, however, becomes clear when you consider the oddness of a statement like, “I’ve got a solution for your problems, but it won’t solve your problems.” Every time clients cooperate in calling what you’re pitching to them “a solution,” they’re buying in to the notion that it is one. It’s like they’re brainwashing themselves for you, for free.
“Solution” = “any software that has additional charges attached, regardless of if it works”
It’s particularly important to distinguish between technical support reps and salespeople on this one. If the person speaking looks uncomfortable in front of a group, mutters something about lamp stacks, and answers questions with too much detail while looking desperately at the door, s/he’s probably tech support and is saying “I can imagine accomplishing what you want by doing it this way.” If you can, slip that person some food with vegetables in it, and try to move the meeting outside if the weather is nice
— this may induce panic, but will alleviate what is almost certainly a severe deficit of vitamin D. If you’re dealing with a team of confidently blatherslinging folk in nice suits, on the other hand, it’s time to counterattack. If at all possible, bring a small compressed- air boat horn, and blast it every time the sales reps say “solution” as part of a product name (if higher admin is involved, try to make sure you have a senior tenured faculty member, or someone equivalently immune to retribution, available to deploy the device. Emeriti, by the way, love using the boat horn). If this strategy appears to be out of bounds, draw attention to the deceptive wording by interjecting phrases such as “alleged solution” or “approach, not solution,” or asking questions such as, “If it doesn’t really solve our problems, why are you calling it a solution?”
Technical: One needs new words for new meanings, and so it is not surprising that teams working on projects with highly specific needs in a new area will develop novel terms, nor that different project teams will think of different terms. It is also less than startling that, when faced with the existence of competing terminological frames, software engineers might be less than enthusiastic about giving up the terms that they invented to adopt those of other software engineers. They are somewhat like linguists in this way. And as in linguistics, differences in terminology can end up masking the ways in which competing frameworks are basically similar, or (conversely) the extent to which a given framework is completely stupid. The institution becomes so invested in the terminology that the quality of the product means less than the costs of using something else. Once that harpoon is in, pulling it out is painful.
Marketing: Yeah, yeah, we know our Document Organizational-
Management Excellence- Leveraging Smart Engine (DOMELSE) package is basically equivalent to Plone but with bullshit names for everything. But hey, middle management has no effing idea what any of the words mean, and once they’ve sunk time into learning how to appear to know what the hell they’re talking about, they’re gonna keep shelling out the bucks even if open source does the same thing for 3% of the cost. If they change anything, it’ll become clear that the folks in the cubicles know more about it than the folks with windows. And besides, those names have advertisements built right into them, so just talking about them does our work for us! What’s the matter with you? Why don’t you like excellence? Firms that leverage their excellence will outcompete you, you know.
Just pick up “expert whitepapers” from any major software vendor, and actually look at them. Go on. Look at them. Look at the words. Look at how they’re put together. See? Here’s a bag I grabbed from the last flight I was on; you probably need it.
This is another case that requires a certain degree of immunity from retribution, and it helps if you can convince the marketing reps that you might actually have some say in purchasing decisions. If you meet both these criteria, start asking the sales reps to tell you exactly what named applications or functions do, and insist that they do not do so using other jargon from their platform. Usually, they can’t refrain from dropping it in anyway, at which point you should say something like, “I know what you call it; I want to know what it is”, or “I think that if there were actual benefits to this, you could explain them in actual language.”
Technical: Compound nouns, including the “loose compounded” type, are useful, especially when you’re trying to pack needed information into a clause without adding more clauses. And the information you typically pack into a compound noun is the kind that nobody argues about; that’s tied up in what makes it so nounful. Plus, programmers spend a lot of their time typing out compound names in code; these are the folk who have to deal with intSysErrcode_wtf and the like.
Marketing: If we say “This pagefarming thingie increases efficiency,” someone could say “I don’t think it will,” or “How would it do that?” But if we say “The efficiency-
enhancing document manager is included in this edition,” they’re stuck! What are they going to do, say “No it’s not”? And oh, does this ever work well with jargooning!
Look back at those whitepapers. Count the frequency of long, stacked noun phrases. Now look at what’s in them. Try not to get too angry.
The only way to deal with this trick is to confront it head on
— you have to stop the discussion, focus attention on the compound label, and ask what evidence there is for any claims that have been folded into it. This will not make you popular at all, but then, preventing a meeting from going anywhere is standard behavior for faculty, so it won’t seem too unusual.
Technical: Obviously, for a wide range of numerical data, charts are a much better way of representing patterns than is text. Charts based on statistically massaged data are, unfortunately, proportionately efficiently misleading, but that’s really the fault of the masseuse. Alas, once charts became standard in business presentations, businesspeople started fetishizing them, attaching a kind of totemic value to them that has nothing to do with the chart as a way of packaging information
— a process made easier by the fact that many in management don’t understand the relationships among the data being presented.
Marketing: Charts! Shiny! People who use charts are smart! People who confidently point at charts are successful! People who worry about what is actually in the charts, on the other hand, better put whatever the hell we tell them to on them, or we’ll give them a bad performance review. The purchasing decision is made by management, not tech support.
(an example; not to be construed as from an actual company that might litigate)
Examine carefully every chart in a marketing package. While a frontal assault on a chart’s construction will likely cause you to be ignored by management types (since you’ll be marking yourself as an underling by actually caring about content), implying that the company’s marketing team hasn’t done its homework will immediately be recognized as the kind of dominance-
jockeying that occurs among equals (like eyebrow- flashing or urine- marking among other primates). Try raising an eyebrow and saying something like, “Oh, did your people put that together? Hmm. I suppose they were in a hurry.” Your goal is to create a situation in which the total bullshyteness of the chart will emerge naturally as a seeming side- effect of the more canonically managerial posturing.