by Steven J. Owens (unless otherwise attributed)

Intentionally Hacking the English Language

In no particular order:

Window Blindness - I coined this phrase the other day, and I like it so much I'm adding it here. Window Blindness is generally any example of behavior similar to the sort of bipolar selective memory that Windows users have about windows reliability and ease of use. One day they're ranting about some bug or crash or usability issue, the next day they're defending Windows reliability and ease of use.

Scroll Blindness - The effect of being unable to find information you need because it is buried in too much other, less interesting information. From Robert L. Read's "How To Be A Programmer". I like this phrase not just for what it's about, but for how I can use it as a metaphor for other types of human behavior.


"Always cut towards a major artery... - ...that way you'll be careful." This is something a friend - one of the better programmers I know, and also a pretty good carpenter - told me, and it's a really nifty example of a technique I love, using humor to make something stick in your head. After hearing this one, I can't cut anything without remembering and chuckling at this -- which means I can't help but remember the practice of making sure I'm cutting away from myself.

"Heat until dangerous" - Another saying, this time from the cooking world. When you heat up oil for frying something, you want it to get hot enough that a drop of water sprinkled on the oil will pop and skitter around, and you risk an oil burn if you're not careful. "Heat until dangerous" describes the heat level succinctly, and also reminds you to be careful

Put on your own oxygen mask first - From standard airline emergency orientations, used at headrush.typepad.com to make the point that your responsibility to all of your customers requires you to avoid overcommitting and underbidding to please just one of your customers.


Organizational Accent - From www.randsinrepose.com, "Getting folks in the same group, with the same organizational accent to talk coherently to each other is hard enough. Meetings give us the opportunity to include other organizations with other accents."

Fibber McGee's Closet - when you "clean" by cramming everything into a closet. From the old radio show "Fibber McGee and Molly", which had a closet crammed full of junk that would tidal-wave onto the next person who opened it. Most programmers can think of good examples of Fibber McGee's closet in their software projects...

Abstraction ad Infiniteum - sometimes layers upon layers upon layers of abstraction aren't about hiding ugliness, but about avoiding reality. Or just indecision; it's hard to get the balance right.

You got your dirt in boss's hole... - a paraphrase from Cool Hand Luke, basically it's about insanely unreasonable management types. In the movie, a prison guard points at a spot of ground (i.e. there's no hole or ditch there... yet) and says:

Boss Paul: That ditch is Boss Kean's ditch. And I told him that dirt in it's your dirt. What's your dirt doin' in his ditch?

Luke: I don't know, Boss.

Boss Paul: You better get in there and get it out, boy.

Hit and Run Management - Joel Spolsky (joelonsoftware.com) came up with this phrase to describe a style of poor management resulting from 50's era Command & Control style management:

"Nobody at Juno owned anything, they just worked on it, and different layers of management happily stuck their finger into every pie, giving orders left and right in a style which I started calling hit and run management because managers tended to pop up unannounced, give some silly order for exactly how they wanted something done, dammit, without giving any thought to the matter, and leave the room for everyone else to pick up the pieces."


Financial Hangover - Like a hangover, only resulting from the financial impact of a night out, party, vacation, etc. I'm not sure if this is really good enough to deserve a listing here, but let's run it up the flag pole and see if people salute.

Teddy Bear Debugging - Often the process of explaining a problem to somebody else is enough to make you see the answer to the problem. From Rob Pike's The Practice of Programming: "One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the bear before they could speak to a human counselor."

Push The Shiniest Button - a good phrase that a friend dropped into conversation one day, vividly depicting somebody interacting with things they don't have the faintest understanding of. Not sure whether he came across the phrase somewhere, or invented it. In reference to the writings of Analee Newitz (techsploitation.com) he said, "she has a lot in common with John Katz, i.e. not a serious investigator so much as someone who pushes whatever geek buttons are shiniest."

Boil the Ocean - an industry phrase meaning to attempt something futilely ambitious. I first came across the term in one of Joel Spolsky's columns, in the context of getting everybody on the internet to install some browser add-on. For some reason, the "get the insanely massive installed base to upgrade all at once" really seems to resonate with "boil the ocean."

FLAQ - A FAQ written by a marketing flack. The term could be stretched to mean any supposedly-informational content that is in fact just advertising copy. FAQs originated on the Internet and tended to be marvels of clearly written information, mainly because they were composed by intelligent people who noticed that certain questions came up again and again (i.e. frequently). Until, that is, the internet boom. Marketing flacks noticed that a lot of websites had FAQs, and started putting up FAQ sections in commercial websites, filled with useless advertising copy. The forward to the dead trees edition of the Java FAQ put forward the idea that FAQS are so useful precisely because the repeated discussions end up identifying and explaining the underlying confusion that usually leads to the FAQ.

Pasta Proposal or Spaghetti Estimation "...throw it at the wall and see if it sticks" is an old saying for how to tell if spaghetti is done cooking. Programmers know the term "spaghetti code" to refer to messy, tangled code. We came up with these phrases to refer to an odd, annoying, and all too common situation. Frequently what happens is that a client prospect thinks that they should buy something, but doesn't know what. In a sane and rational world, you'd have somebody good at analysis (i.e. not a salesman) sit down with them and get a decent idea of what's going on in order to develop a proposal. In the real world, often this is politically impossible on both sides, for a variety of reasons. Instead, the salesman makes guesses, pressures the back office folks to throw together a proposal, and throws that at the client to see if it sticks. Sometimes this is about features, other times it's about cost and time estimates (e.g. the client doesn't know what ballpark they want to be in).

Road-to-Hell Technology - paved with good intentions. Client-side javascript (in a pre-AJAX context) is one such technology. I don't mind javascript as long as a) we aren't functionally impaired when it breaks and b) we don't allow it to sidetrack any significant degree of resources. However, the nature of javascript is such that even with the best of intentions, both of these will inevitably happen.

Shiny Technology - I was just editing this and read "push the shiniest button" followed by "road-to-hell technology" and had an epiphany. Certain kinds of technologies are a recipe for trouble, not because of anything inherently wrong with them, but because of their allure. Mostly I'm thinking about technologies that non-techs somehow feel more sure of themselves with; not that they understand the technology, but that it is for some reason more viscerally accessible to them (see javascript). This leads them to assume that their intuition is valid, when it usually isn't. However, most technologists have had an encounter or two with shiny technology themselves.

Slogware, Slogtech - product or technology that by its nature you simply CANNOT "work smarter" at, you have to just slog through it. Oracle is a good example of this, particularly getting an Oracle server to exactly, precisely the same patch level as a working installation so you can move an application over to it.

Fritterware - an ex-colleague, Jim Venis (the "ven" part is pronounced as in "venn diagram") coined this, for technology that tends to suck you into frittering away countless hours of time fiddling with it and fine-tuning the settings, without any real concrete payoff.

Enabling - terminology from Alcholics Anonymous, meaning to help somebody avoid confronting their addiction, by helping them avoid having to deal with the consequences of their addiction. Sometimes technologists do this, by too rapidly fixing (or at least leaping in to fix) the consequences of bad technology decisions. I'm not suggesting that you should play games with your users or colleagues, but it's important to recognize what's going on.

Irrational Technology - Relevant to Enabling. Enabling is particularly tricky when dealing with other technologists, because technologists (correctly, most of the time) tend to assume that problems are the result of incomplete knowledge, and that resolving a specific problem and filling in the knowledge gap that caused it will prevent a recurrence of similar problems. For rational technologies, this tends to be true. For irrational technologies, this is not.

When dealing with a fellow technologist who does not want to accept your advice that a particular technology is irrational, it's important to be careful not to become an enabler.

Systematic vs. Idiosyncratic - I use this dichotomy to illustrate two opposing tendencies in knowledge. This is closely related to rational/irrational. With rational technologies, you can assume that there is a pattern (model, paradigm) to the technology. As you come to understand the pattern, you start to get better at dealing with the technology. Some topics defy this, for example automobile repair and Microsoft Windows products. With these idiosyncratic technologies, you have to rely on brute-force memorization of tricky little details and exceptions.

Most idiosyncratic technologies also qualify as slogware or slogtech.

Transparent Complexity vs Obfuscated Complexity - Some things just are complex, no matter how you try to hide the complexity. I am convinced that the worst excesses of bad UI design are attempts to hide such inevitable complexity. The result is layers of obfuscation added onto an already-complex topic. I'd rather just have transparent complexity, complexity that I can more easily grapple with directly, than complexity buried under layers of gratuitous obfuscation.

Obvious Complexity vs Subtle Complexity - also perhaps shallow vs. deep. Clutter is obvious complexity; subtle complexity often may not seem complex at all - and then comes back and bites you.

Monkey Code - (I intellectually prefer "Monkey Code", but I always end up saying "Donkey Code" for some reason - maybe "Donkey Kong" imprinted itself too strongly on my young mind.) Coding that a trained monkey could do. A classic case in point in getters/setters in Java, delegation for unmodified methods in Java, all the scaffolding required for JDBC in Java. Any repetitive coding you have to do should be done by a program, or better yet, should be built into the technology.

Catholic Tech, or Rosary Code - technology that has a lot of inherent monkey code (e.g. "First you say 500 Hail Marys"...). (coined by James Deikun)

Semantics - often used as a derogatory comment in dismissing a question of terms, meaning "you're quibbling over semantics". In some cases it's correct to avoid quibbling over semantics. In other cases, semantics are half the job. Besides the importance of choosing the right metaphor and the right terms, working with the wrong set of terms and labels (often due to a legacy codebase) adds considerable cognitive overhead.

Cognitive Overhead - additional load imposed on your thinking process, often by extraneous elements.

Spiritual Code - as in "frustration is good for the soul." (based on a comment by John Roth on the extreme programming mailing list).

Koolaid Technology, Way of Life or One True Way - From the phrase "drink the koolaid", generally meaning to completely buy into a mass delusion (for example a cult; put "koolaid" and "cult" together and you can guess the origin of the phrase, which seems strangely popular in certain technology circles :-). There's a frustrating tendency for technologies to have a web of interdependencies. Microsoft and Oracle are two good examples. A friend suggests Zope is an example, but I haven't worked with it.

To get the advantage of the technology, you have to sign up for the entire way of life implicit in the technology. These are Koolaid technologies. This is true in both the larger sense, where you might say there's an entire ecology of interdependent technologies (Microsoft software development is a good example of this) and in the smaller sense, IDEs or particular components or component suites. A technology's Koolaid-ness isn't always evil, but I tend to be wary of it. Aka "a little bit pregnant." Koolaid is not a sign that technology is inherently bad; gratuitous koolaid is bad. Most koolaid is gratuitous.

A friend uses this less-pejorative phrase, "heavy lifestyle assumptions", as in "almost all frameworks come with heavy lifestyle assumptions."

Clever Stupidity - Sometimes I use this phrase in a complimentary sense; somethings doing things the stupid way can be very clever. Most of the time, I'm talking about doing things that seem clever but are ultimately stupid (like most uses of javascript).

See original (unformatted) article


Verification Image:
Your Email Address:
Confirm Address:
Please Post:
Copyright: By checking the "Please Post" checkbox you agree to having your feedback posted on notablog if the administrator decides it is appropriate content, and grant compilation copyright rights to the administrator.
Message Content: