SimpleIsntEasy. There exists EssentialComplexity in most situations in life.

The EinsteinPrinciple states that theories should be AsSimpleAsPossibleButNoSimpler. If you violate the latter clause ("but no simpler") in any system, by not capturing the EssentialComplexity, you make it SimplySimplistic. You cannot be rid of EssentialComplexity (it being 'essential'), so '''simplistic''' solutions, models, and theories end up foisting the complexity they didn't capture upon their user.

One example is AddingEpicycles. A SimplySimplistic model placing the Earth at the center of the universe required that users of this model that observed the universe create complex, epicyclic orbits for the planets.

Simplistic protocols and models and language features can end up becoming '''complexity multipliers''' because the complexity is duplicated by each and every '''user''' of the model or protocol. They are also effort multipliers. Fortunately, one can sometimes solve this problem by wrapping or refactoring the protocol or model or language feature within a library to utilize it, thus capturing the EssentialComplexity into the library and thus creating the feature/language/model that should have existed in the first place. (If a language cannot refactor this model/protocol into a library, or must expose implementation details to do so, it suffers from the MissingFeatureSmell.)

Another example, since YouCanSolveAnyProblemWithAnotherLevelOfIndirection, many consultants unwittingly add complexity after decision makers buy into an attempt to find AsimplerWay using indirection.

On the other hand, there are indeed SimpleSolutions at times. Without these, the SimplySimplistic arguments would not have existed.

----
Related: 
* OverSimplification (how to get a SimplySimplistic system)
* MissingFeatureSmell (the indicator)
* MinimalDesign (the result)
* GalacticModelingLanguageMetaModel (an example of a too simplistic system for UML)
* EinsteinPrinciple (the quote)

CategoryComplexity CategorySimplification