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