Software design paradigms tend to ignore the idea of limiting complexity.

What is ''too much'', and ''just enough''?  When should we '''not''' integrate?  The correct answer is only as much as needed to get the job done, and AvoidIntegration if unnecessary.

What this means in practice is using a lot of existing wheels (not ReinventingTheWheel).  As a result, this sometimes means not coding at all. 
In many cases the need for a unique solution outweighs the off the counter solutions - in which case we make sure that we exhaust all standard APIs 
and data representation/encoding options before inventing our own.  At each level, we ratchet up the complexity only as needed, and no more.

This seems to fly in the face of traditional practices where process, regardless of the complexity involved, rules the day.

----

Another way of expressing this, at first blush, is DoTheSimplestThingThatCouldPossiblyWork.  However, this only approaches obliquely ''what is the right solution'' versus ''what is the simple solution''.  I believe these are two different things that may or may not coincide over the lifetime of a project.  -- MalcolmCampbell  (I didn't like the way I said that - but it will have to do until I can come up with something better)

----
CategoryComplexity