Some relevant excerpts ...
==========================
- "Simple is not the same thing as "easy to do/understand."
- "Simple design" is not the same thing as "simple to develop/deploy."
- "Simple" is not the same thing as "good enough!"
- "Simple" is not the same thing as "simplistic!"
- What is "simple" for one request may not be "simple" for the whole!
... The Agile Manifesto defines simplicity as "maximizing the amount of
work not done." But I think that's a more accurate characterization of
Lean than of simplicity.
... Simplicity involves being able to see the whole from a system's
thinking perspective while at the same time being able to focus in on
what is relevant and essential and how it impacts the rest of the
system. Sustainable simplicity often has to evolve or emerge on it's own
from a set of simple guiding rules.
The opposite of simplicity is complexity (as opposed to "hard" or
"difficult" or "time-consuming" or "labor-intensive") ... Hiding
complexity isn't the same as removing complexity.
I think that true simplicity is about minimizing and managing overall
complexity. For any non-trivial system, simplicity often has less to do
with the number and kind of different things involved and more to do
with the number and kind of interdependencies between them. Simplicity
is less about managing "points" and "things" and more about managing
rules and relationships.
When dealing with large or complex systems (like most software, and
software processes) the number of things (scale) and different types of
things (diversity) that need to be managed is overwhelming. If we can
come up with a modicum of modest, simple rules & principles to govern
our design decisions in ways that helps us minimize and manage
interdependencies, eliminate constraints, and remove waste, then we are
on the path to solving the real problem and meeting stakeholder needs in
a way that is both simple and sustainable.
