«
»

Simple and Complex

October 7th, 2008
[ Software Development ]

At Brainpark, we stuck the words “smart, simple software” on our cards. Simple, what’s simple? The word on it’s own offers little to act on. You need a context to put your product into to assess. Christopher Alexander talks about context and form. The challenge of the designer being to achieve fitness between form and context.

Back to John Maeda who describes the balance between simplicity and complexity as….

How simple can you make it?….versus….How complex does it have to be?

“On the one hand, you want a product or service to be easy to use; on the other hand you want it to do everything that a person might want it to do….The simplest way to achieve simplicity is through thoughtful reduction. When in doubt, remove. But be careful what you remove.”

It’s easy to get lost focusing on form and forget the context you place it in. Simplicity and complexity only really have meaning with both form and context.

This entry was posted on Tuesday, October 7th, 2008 at 8:17 pm and is filed under Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

  • http://dpwhelan.com/blog Declan Whelan

    Interesting connection between Christopher Alexander and simplicity … I had not seen that linkage before.

    On of the mantras that I bring forward in my mind is the agile adage that “do the simplest thing that could possibly work”. While it does not answer the question as to which alternative may be simpler I find that when I keep asking the question over and over again it is often intuitively obvious which approach is simpler. I think this is because the questions being asked are small questions and the possible alternatives are limited and the cost of a mistake is low.

    When I encounter larger problems where intuition is insufficient I will often do a small “spike” on *all* feasible solutions (aka Toyota “set based engineering”). I find that feedback based on empirical results drive quicker and more reliably to a simpler, better solution. I usually time-box such work to a few hours with the intent of garnering sufficient information to make a more informed decision.

    For usability, I must claim a total lack of experience. I like to get a good UX designer and let her answer the simplicity question. I would insist though that she get answers from real users though.

    For architectural simplicity I have become more of an emergent architect where I let code refactoring drive the architecture. But I start with a high-level architecture and re-visit it along the way. Some argue that low-level simplification can just shift complexity up the architecture stack. Could be, but that has not been my experience.

    My perspective on simplicity is more from a developer perspective rather than a UX or product perspective. I really like the 4 rules of simple design suggested in Extreme Programming by Kent Beck:
    * Runs all the Tests
    * Reveals all the intention
    * No duplication
    * Fewest number of classes or methods
    This turns out to be a great way to evaluate whether the code has reached a suitable level of simplicity. I use this all the time and I am still learning ways to write simpler code. More on this here: http://xp.c2.com/XpSimplicityRules.html.

  • http://randompost.ca Jaimie

    Funny I have had this saying since before ’03 on my old site:

    http://rhombustech.com

    IT: smart and simple

    It is a great idea and when you get it right a thing of beauty.