The Complexity Around Simplicity
Most Agile practices place a lot of emphasis on simplicity. XP, stresses the simplest thing that could possibly work. However, simplicity is not always easy to achieve and there are several reasons which lead to complexity. Many members of the Agile community discuss 'Simplicity' as a concept and why it is not always easy to keep it simple.
Many software designers intentionally create unnecessarily complex products that do less to serve their companies and customers than to advance their careers.
...Highly capable designers have an incentive to choose somewhat more difficult designs to better prove their talent, while less-capable designers have an incentive to choose highly difficult designs to obfuscate their lack of talent, Prof. Siemsen concludes.
We spend too much time complicating our lives by trying to do too much, too fast! There seems to never be enough time to do something correctly, but always enough time to do it over again! Given to complexity of managing technology, we’re prone to think that complex solutions, are better solutions.
Other members of the community think that simplicity is being used as a convenience for cutting corners. This in turn leads to complexity. Damon W. Carr, in his blog, questioned if Agile as a movement had gone past the point of simplicity. He asked,
Has the Agile movement gone to far in its near obsessive love of simplicity and reduction of ceremony at the expense of unwittingly encouraging teams to throw out common sense good object oriented design in an effort to 'do the easiest thing that works'?
According to Damon, since Agile places a lot of stress on working software, many developers chose to ignore important aspects like maintainability, scalability, code reuse, internal robustness, component use, etc.
Complexity and simplicity are relative terms, and simplicity for one stakeholder means complexity from a different viewpoint, like the frantic activity underwater to power a duck's elegant glide.
So what is simplicity and is it easy to understand?
I think it's fair to say that while "Simplicity" may be, well, "simple", truly understanding "simplicity" is in fact quite hard!
According to Brad, simplicity in a systems development involves seeing the whole, at the same time being able to focus on what is relevant and how it impacts rest of the system. He stresses that true simplicity is about minimizing and managing overall complexity. Brad mentions that though a lot of stress is laid on simplicity however there are many myths surrounding the same. He detailed some myths which would help understand simplicity. According to him,
"Simple" is not the same thing as "easy to do/understand" – the simpler solution might require the team to learn something new and open the mind to new ideas.
"Simple" is not the same thing as "good enough!"- the simple solution might not be sufficient. It might be sufficiently workable for now but needs improvement.
"Simple" is not the same thing as "simplistic!"- simplistic may be the false appearance of simplicity. A solution may appear simple, however, just appearing simple is not enough, it should also work.
What is "simple" for one request may not be "simple" for the whole! - trying to simplify one part of the system may bring undue complexities in other parts of the system. There is a need to view the system as a whole.
Thus it seems that there is a reasonable amount of complexity surrounding simplicity.The key lies in working on the myths surrounding simplicity and avoiding the notion that complex solutions are better solutions.
Simple is in fact something that takes far more work than complex. You need to put all the ingredients in the pot and boil them down to get to simple, so it often takes several iterations to get to that point. As pointed out in the article, you need to identify WHAT you are trying to make simple. Is it to make it simple to code, or simple to use, or is it to make it simple to extend, or simple to maintain (notice, we're following the "ilities" here).
Simple to Use is the hardest one to reconcile with the others (particularly when you're talking about UI). Simple to Extend and Simple to Maintain often go hand in hand. All of these require more WORK to code, but that doesn't automatically make it more complex to code.
Simplicity in design
As an example, one principle has been explained in this article: simplcity can't exists without complexity. It's all relative, so you have to deal with both and try to put each one at the right place.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015