The Complexity Around Simplicity

Posted by Vikas Hazrati on Jul 01, 2008 04:04 PM

Community

Agile

Topics

Agile in the Enterprise

Tags

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.

In an interesting post, the author, tries to uncover the reason for having complexity even though Agile stresses on simplicity. He quoted the current issue of Management Science

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.

George Ambler mentioned a similar reason for embracing complexity. He mentioned,

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.

A few members think that there is a definite subjectivity associated with simplicity and complexity. What might be simple for one may be complex for another. Andrew Johnston mentioned,

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?

Brad Appleton mentioned on his blog,that he did a lot of research on simplicity and came to following conclusion

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.

1. Back to top

   Also Add...

   Jul 1, 2008 6:25 PM by Jim Leonardo

   "Simple" is not the same thing as "The first thing that comes to mind that will work".
   
   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.

   Reply

2. Back to top

   Simplicity in design

   Jul 3, 2008 2:33 AM by Frederic Monjo

   For those who are open-minded, you should read "The laws of Simplicity" (John Maeda). This short book (100 pages) talks about simplicity in product design, but tries to leverage some "laws" (actually general concepts and principles) about simplicity. These laws are not directly applicable to software coding, but may inspire you with a good approach of simplicity. 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.

   Reply

• Older >