InfoQ

News

"Simple Ain't Easy"

Posted by Deborah Hartmann on Jun 01, 2006 02:03 PM

Community
Agile
Topics
Delivering Value,
Agile Techniques
Tags
Simplicity
We human beings, so often capable of complex thought, paradoxically also long for something often called "simplicity".  A well known example of deep reflection on the subject is Thoreau's "Walden", published in 1854, a social critique of the Western World examining aspects of humanity that needed to be either renounced or praised.  But this tension is surely as old as man.

In recent decades, the idea has been explored in relation to many domains, including charity, time management, consumerism, and home design.  In concert with this movement, it surfaced in 2001 in the Agile Manifesto:
"Simplicity - the art of maximizing the amount of work not done - is essential"
But the term is somehow deceptive - surely simplicity should be, well, simple?

Brad Appleton has blogged at length on the subject, exploring "Myths and Misunderstandings about Simplicity", including these:
  • Simplicity = "easy to do/understand"
  • Simplicity = "simple to develop/deploy"
  • Simplicity = "good enough!"
  • Simplicity = "simplistic"
Appleton wants to open a dialogue on the subject: his posts on various Agile lists this week invited discourse, asking for people's impressions and commentary - comments can be entered here or on his blog. You will probably also find discussions going on in these newsgroups: ExtremeProgramming, AgileModeling, AgileManagement, ScrumDevelopment, LeanDevelopment or PragProg,

Appleton has pulled together much information, to make this blog entry an excellent resource for those thinking about how to apply simplicity as an Agile tool - he's finished his entry with links to 14 resources on simplicity in software and other types of design, and over 30 famous and pithy quotes on simplicity, including this one, by British mathematician Sir Eric Christopher Zeeman:
"Technical skill is mastery of complexity, while creativity is mastery of simplicity."
The Agile approach invites us to consider which of these is necessary at every moment: technical skill or creativity.  Each is valuable in its own right, and when well balanced against one another and focused on customer goals, both can contribute to the creation of extraordinary business value.

Ah, balance. Therein lies the Agile practitioner's challenge!

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.

3 comments

Reply

True, True by Geoffrey Wiseman Posted Jun 2, 2006 9:18 AM
Simplicity is NOT easy by Jason Carreira Posted Jun 2, 2006 12:08 PM
Re: Simplicity is NOT easy by Floyd Marinescu Posted Jun 2, 2006 1:18 PM
  1. Back to top

    True, True

    Jun 2, 2006 9:18 AM by Geoffrey Wiseman

    This is true in so many human endeavours, from writing a short story, to making an email concise, to making a software system 'simple'. It's often worth the effort, but it certainly isn't easy.

  2. Back to top

    Simplicity is NOT easy

    Jun 2, 2006 12:08 PM by Jason Carreira

    Take the famous Blaise Pascal quote:

    I have made this letter longer, because I have not had the time to make it shorter.
    It takes EFFORT to keep things simple. It's easy to cut-n-paste your way to code-hell, it takes effort to identify opportunities for reuse and refactor out common code. At work a lot of what I do is to encapsulate the complexity of something we're trying to do so that the other team members can use what I've done to very simply solve similar problems over and over again. Take for example XFire. There's a lot going on under the covers, and even understanding it and configuring it is too complex to have to do more than once. But now that it's configured, people on my team can just annotate their classes with an @WebService annotation and the bean will be automatically registered as a web service. Don't let the term "simplicity" fool you. Simple != Easy.

  3. Back to top

    Re: Simplicity is NOT easy

    Jun 2, 2006 1:18 PM by Floyd Marinescu

    Take the famous Blaise Pascal quote:
    I have made this letter longer, because I have not had the time to make it shorter.
    It takes EFFORT to keep things simple. Don't let the term "simplicity" fool you. Simple != Easy.
    I can definitely sympathize with that. Take InfoQ.com for example, the UI was designed to be as simple as possible, but we had to jump through many hoops to get it that way... Even editorially, I spend a long time trying to write news items in as concise a way as possible, to make them as clear and easy to understand as I can. That takes a LOT of effort.

Exclusive Content

SOA Governance: An Enterprise View

Michael Poulin explains the necessity for SOA governance to ensure an Enterprise SOA's success, relying on concepts from the OASIS SOA Reference Model and Reference Architecture.

Developing Portlets using JSF, Ajax, and Seam (Part 2 of 3)

This article covers setting up a RichFaces portlet using JBoss Portlet Container and JBoss Portlet Bridge, deploying a RichFaces portlet, and RichFaces capabilities.

Scalability Worst Practices

This article discusses scalability worst pratices including The Golden Hammer, Resource Abuse, Big Ball of Mud, Dependency Management, Timeouts, Hero Pattern, Not Automating, and Monitoring.

Do the Hustle

Obie Fernandez shares his experience selling consulting services for both Thoughtworks and Hashrocket and give tips how Ruby developers can work with clients.

Natural Laws of Software Development - Deriving Agile Practices

Jeffries and Hendrickson derive Agile practices from the natural laws of software development. They don't just say "Be Agile!", but they explain why Agile practices make perfect sense.

Jinesh Varia About Amazon Alexa Web Service's Architecture

Jinesh Varia talks about the architecture of one of Amazon's web services called Alexa. Jinesh explains how Amazon has reached scalability, performance and reduced costs for the Alexa service.

"We Suck Less!" Is Not Enough

David Douglas and Robin Dymond discuss about companies adopting Agile, but don't go all the way, resulting in failure and rejection of it, and predictably having a negative impact on Agile's future.

The Development of a New Car at Toyota

Kenji Hiranabe talks about Toyota's development process of a new car. Kenji shares his experience meeting Nobuaki Katayama, former Chief Engineer at Toyota, and the lessons he learned from him.