fauxplexity

15.04.08

Observations while designing, researching, and teaching have recently led to the development of a neologism:

fauxplexity: The false appearance of depth and/or complexity by adding unnecessary (and even erroneous or redundant) information into a design or system.

This term may be applied in any design and/or systems design and/or interface design situation.

Fauxplexity typically has two aspects.

• First, by including concepts/information/design artifacts/behaviors/structure/sub-systems, etc., that do not serve a purpose, and/or are duplicates of information presented elsewhere in the system (or its representation), the system does in fact gain in complexity although it is not useful complexity and therefore only serves to needlessly over-complicate the presentation and/or functioning of a simpler system. Conceptually, this type of complexity is analogous to the system’s ‘belly fat’.

• Second, by adding needless and/or duplicate components and behaviors to a system (or its representation), the unnecessary components and behaviors also tend to entail flaws in logic that result in misunderstanding the composition and functioning of the actual system. This obfuscation of the true composition and functioning of the system can lead to gaps identifying needed considerations of and components and behaviors for the system. Therefore fauxplex systems can also make a system seem less complex than it really is.

Potential problems that result from fauxplexity include the following:

• With respect to the first problematic aspect of fauxplexity, when a system (or its representation) is presented as more complex than it really is, it may never get out of the brainstorming phase. The over-complexified design may be rejected (or altered before being accepted in ways that compromise its value) precisely because the developers assess it is too risky or logistically infeasible to develop.

• With respect to the second problematic aspect of fauxplexity, when a system (or its representation) is presented as less complex than it really is, it may lead to quick and emphatic adoption of a design that later proves to be a schedule or budget killer or that increases the chances of negative interpersonal dynamics and litigation because stakeholders’ risk exposure increases significantly as the project progresses.

Fauxplexity is common among designers and engineers and researchers and scholars who dress up their needs analyses, problem definitions, scope definitions, and solutions (and resumes) with needless details and components that they think will sell well or are trendy or sound impressive or ‘are just the way it’s always been done’.  Sometimes this is intentional but often they’re somewhat blindly following a template.

Rather, if the goal is to assess the true simplicity or complexity of a system (or its representation), then the system should be conceived and represented as simply as possible but no more simply than necessary.

Incidentally, after thinking up fauxplexity, I had to search the web to see if it has been described before (figuring that it had). Of course it has. I came up with the following results:

https://www.google.com/#q=fauxplexity — only three pages and really only a few actual usages of the term

• a review of a book: http://larabuckerton.blogspot.com/2010/05/fauxplexity.html

• a forum comment: https://steamcommunity.com/id/RyanRushia?l=norwegian

• a book: https://books.google.com/books?id=qJesBwAAQBAJ&pg=PT670&lpg=PT670&dq=fauxplexity&source=bl&ots=AUBWJ5dLdv&sig=mnXKaqZlpPc-wxaq3WkPYbRDWTE&hl=en&sa=X&ei=aRI8VamJNMq0ggT9roCYBw&ved=0CCwQ6AEwAg#v=onepage&q=fauxplexity&f=false

These are general uses of the term and not necessarily defined.

Of course fauxplexity is nothing new. It has been a problem in literature and design for a long time.

• In literature, see Poe’s excellent and funny short piece, “How to Write a Blackwood Article.” http://www.online-literature.com/poe/2180/

• In architecture, see Geoffrey Scott’s excellent book, The Architecture of Humanism: A Study in the History of Taste. http://books.google.com/books/about/The_architecture_of_humanism.html?id=NEqKd-fHPq4C Scott describes what he considers to be design fallacies (i.e., logical justifications for design strategies that designers attempt to apply that are not actually necessary/useful).

• For design in general, see the movie, Objectified, that covers this topic very well. http://www.imdb.com/title/tt1241325/

• In software, see writing on cyclomatic complexity, among other writings: https://en.wikipedia.org/wiki/Cyclomatic_complexity