Antisimplicity

I've decided to coin a new word:

Antisimplicity -- The force that conspires against a simple solution to a complex problem.

I've felt this force for many years. It's troublesome that it doesn't have a name. The big moment came recently when I was once again confronted by an annoying thought:

Aren't complex solutions necessary for complex problems?

No. Complex solutions, user interfaces, business processes, systems designs, procedures, etc, are not always necessary to address complex problems. And if the answer to that question is really "no", then the opposite of simplicity is not complexity. Rather, it's something else: antisimplicity.

Like gravity, antisimplicity is everywhere. In our business it's propagated not only by the complexities of the domain in which we operate, but by our own overly analytical and technical engineering senses. We sit down with customers wallowing in complex problems, and attack the issue with more complexity. That's the force at work.

Some examples:

• Antisimplicity eventually killed EJB, and hobbled J2EE for life.
  
• The United States Federal Tax Code.
  
• Antisimplicity causes business people to implement corporate policy within their IT systems.
  
• Antisimplicity was responsible for X.400 (rather than SMTP). Likewise OSI vs TCP/IP, WAIS/Gopher vs HTTP, etc.
  
• Rube Goldburg (who said antisimplicity couldn't be entertaining)
  
• Antisimplicity causes me to interfere when my kids are arguing over their toys, rather than leaving them alone to work it out.
  
• Antisimplicity is responsible for the NFL's instant replay rule.
  

Please feel free to provide your own examples. :)


Postscript: Sean Reese has a great example of antisimplicity at work via The Complicator's Gloves.