InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

"Simple Ain't Easy"

Posted by Deborah Hartmann Preuss on Jun 01, 2006

Sections
Process & Practices,
Architecture & Design
Topics
Agile ,
Agile Techniques ,
Delivering Value
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!
True, True by Geoffrey Wiseman Posted
Simplicity is NOT easy by Jason Carreira Posted
Re: Simplicity is NOT easy by Floyd Marinescu Posted
  1. Back to top

    True, True

    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

    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

    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.

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.