Avoid Complexity

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