Okay, here's some terminology for you. Some of it is tongue-in-cheek, but it's useful (I think) when discussing design issues.
- Yoda Notation: the reversal of order, in particular with respect to operands of an equality operation in C and C++, as in
if ("blue" == theSky) ...
in order to prevent a bug caused by accidental misuse of the assignment operators. Stems from Yoda's curious word ordering in the Star Wars movies: "Backwards it is, yes!"
It is an example of a workaround of the decision of C and C++ language using = as the assignment operator, and == as the equality operator, illustrating Sins of our Forefathers. - Mental Speedbump: an incongruity in design that interrupts one's concentration, and the natural work flow of the task at hand. UI Designers often consider MessageBoxes, like "Are you sure you want to continue?" as mental speedbumps. Sometimes also incorrectly named procedural potholes, but potholes generally aren't designed into existence, speedbumps are.
- Pearl Effect: The workarounds and procedural accretions that are meant to insulate users from a defect that wasn't discovered in time to be fixed. Unlike the pearls of nature, these are not pretty to look at. cf Sins of our Forefathers.
- Sins of our Forefathers: The legacy of bad designs that seemed logical or appropriate at the time (even if only marginally so) but in retrospect seem really boneheaded. They differ from Pearls in that these are consciously added, though both often result in workarounds.
- Katrina Syndrome: the rather irritating requirement of having to start all over again. This is typically applied to reconfiguration of an application after an upgrade, since the upgrading software has removed or not carried forward user settings and customizations. It also applies, to a lesser extent, to some Windows applications that force you to restart Windows after installing or uninstalling that application, forcing you to close other applications and save other work that may have been in progress.
- Workaround: Actions the user must take to circumvent a failure in the development process, often a failure in design.
Sections: 7
Gorilla in an Evening Gown
— Thomas M. Tuerke
This colorful turn of phrase is meant to suggest something out of place decorated to look like it is meant to belong. In terms of design, it's usually an awkward feature cosmetically improved—or even just surrounded with vague rationalizations—to appear better.
(And before the animal rights activists everywhere complain: I'm sure everybody—especially any gorilla involved—would agree that gorillas are not meant to be in evening gowns. ;-)
Katrina Syndrome, from the Customer's Perspective
— Thomas M. Tuerke
People hate this situation...
| From: | [omitted] |
| Date: | Aug/11/06 - 08:19 (GMT) |
| Re: | Share your thoughts and wishes with the [Product] team! |
| | I was disappointed that, when I upgraded from 04 to 07, my toolbar arrangement was not transferred. I have to start again to re-set this after years of continuous use. |
It's really just designer (or management) laziness.
Rearranging the Blacksmith's Shop
— Thomas M. Tuerke
A well-intentioned but perhaps ill-advised change in procedure or design because of a negative impact to existing users. Despite being perceived as an improvement by the implementer, it causes users (often familiar or set in their ways) to become less productive, at least in the short-term. You might consider it a case of not listening to the old saw, "If it ain't broke, don't fix it."
The name stems from the scene in Jabberwocky where Michael Palin's character decides to improve the efficiency of the blacksmith's shop by rearranging it, with catastrophic results.
Inventing a Faster Horse
— Thomas M. Tuerke
This term stems from Henry Ford's quote: "If I had asked my customers what they wanted, they'd have asked for a faster horse." The meaning, therefore, is to just moderately improve the status-quo without really innovating or looking at the problem in a new light—with all the attendant opportunities (and, yes, risks.)
The idea here is that it's important to listen to what your customers are asking for, but it is equally as important to understand the need behind the request. In a way, you shouldn't take your customers' requests too literally, but search them for the need that's motivating them.
Innovation is, by its nature, somewhat unanticipated.
Missing O-Ring
— Thomas M. Tuerke
Metaphorically, a "Missing O-Ring" is a seemingly inconsequential but actually significant piece of a much larger thing. This expression comes from failure of such an O-Ring in the Challenger Shuttle Disaster, where a failure of a small ring weighing a few ounces resulted in the destruction of the shuttle.
This metaphor speaks to an injudicious application of "lossy" conversion algorithms, the omission of a small but crucial detail in a process or description, or an inattentiveness in design or implementation that results in crucial information being lost.
Complexificate
— Thomas M. Tuerke
This little jewel, meaning the process of making a reasonably simple thing extraordinarily complex or unnecessarily complicated, (typically by committee) was created quite tongue-in-cheek, yet so wonderfully illustrates a concept, it was a shame not to add it to the canon.
Imagine a meeting not unlike many others, where a topic is being discussed and suggestions are being made. What started out as a fairly straight-forward concept has been bent and twisted into this mutilated, ungainly thing that bears little resemblance to the original concept.
Mocking frustration, one contributor suggested that the original idea had been made "far too complex", to which somebody else retorted, "you mean, it's been complexified?" Another, immitating an earlier contribution, (by somebody who hadn't warmed up to the original concept, but probably would have after mulling it over) chimed in: "That's new. I don't get it. I'm not comfortable with that." The riff then briefly digressed to coin a term that means "to needlessly complicate or make too complex," from which "to complexificate something" was adopted (the irony of it being even more complex than complexify not being lost on the contributors.)
Terminology Nouvelle
— Thomas M. Tuerke
What with colleagues doing a cover of this site, with Yoda Notation taking on popular momentum in top-terms lists, and with almost a decade having passed, I think it's about time to update the site with a few more terms. These range beyond "design"-related terminology, so they didn't find inclusion the first time around, but I'll put them here for now.
Sections: 6
Bog of Eternal Stench
— Thomas M. Tuerke
Typically a poorly-designed, poorly implemented, or otherwise undesired feature nobody wants to work on for fear of having their name show up in the revision control history logs (or else just code somebody worked on long ago and has transitioned away from, and would rather not continue to be associated with.)
Like the eponymous bog from the movie Labyrinth, once you touch it, you’ll stink forever (that is, you will be associated with it—and called upon to maintain it—for the rest of your career at the company.)
Archeology
— Thomas M. Tuerke
Reverse-engineering intent from source code, which was typically poorly written, or at least poorly commented (though many would argue that's one and the same.) The "archeological record" consists of the source itself as it appears in its present form, with additional layers in the form of previous versions (if available) right up through the beginning of time.
Haz-Mat Code
— Thomas M. Tuerke
Code so bad, it needs to be treated like the Hazardous Material that it is; at a minimum, you need OSHA safety glasses to protect your eyes when you look at it.
Disgusted with poor code quality at one employer (namely management's indifference to it) I happened upon a pair of such glasses at a closeout store, and took to bringing them to code reviews.
Could-o-wisp, maybe-o-wisp
— Thomas M. Tuerke
Named after the Will-o-wisp of lore, which was an insubstantial light frequently seen in bogs: legend has it these are creatures meant to lead unwary followers to untimely ends.
Essentially, this is a form of feature-creep when designing something. These appear as phantasmal "we could do this" or "maybe we make it do that" ideas, frequently posed without any concrete basis for their need. Brainstorming and exploring options are generally good, but only to the extent they meaningfully contribute to solving the identified problem. Could-o-wisps and their ilk (might-o-wisps, maybe-o-wisps, etc.) generally lead the design astray with dazzling, attractive nothings and specifically are not backed with a concrete need for such. They are distractions.
Starbucks Cup Size Syndrome
— Thomas M. Tuerke
A skewed and hyperbolic scale of labels, reminiscent of the major beverage chain's list of cups sizes: rather than small, medium, and large, their scale is tall, grande, and venti with the conspicuous omission of anything from the middle or lower end of the scale.
Instances of this abound beyond the menu of the Evil Green Mermaid. For example, a recent migration from Bugzilla to Jira resulted in bug priorities being changed from numerical designations (P1 = most important to P5 = least important) to things with hyperbolic labels such as "Blocker", "Critical", and "Major", followed by a sudden drop to "Trivial". Missing only from the scale are "Earth-shattering" and "World-ending" to make the drama complete.
Contrast this with a different prioritization scale used in project management (given unskewed labels with far less emotional baggage attached to them) known as MoSCoW: Must, Should, Could, and Won't. The entire spectrum is accurately and descriptively represented with a fairly uniform distribution across the range.
Codious
— Thomas M. Tuerke
A portmanteau of “code” + “odious”, any coding practice that is far less than desirable, being on the unpleasant end of code-smell, though not necessarily into the territory of Haz-Mat code.
Generate a QR code link to this page