Simple, Easy

Simplicity is widely misunderstood (in programming as well as in life in general). It doesn't mean simplistic, amateurish, or insufficient in any way. Quite the opposite. Simplicity is often much more difficult to achieve than an overly complex, kludgey solution.

-- Practices of an Agile Developer, Subramaniam and Hunt

We've all been in this meeting. A new system requirement is put on the table. Business stakeholders and developers join together in a throng of thoughts, ideas, and concerns. At the conclusion of the exchange, someone chimes in: "Look, the important thing is that we just need to keep it simple, and not over-engineer the solution." Everyone nods their heads and gets down to business, believing that there was substantial agreement on what was said. But confusion is waiting in the wings. Did the summarizer mean simple or easy? Which version was heard by the participants? What's the difference anyway?

When concepts become confused in this way, I often find it helpful to distinguish them by means of their opposites. The opposite of simple is complex, while the opposite of easy is difficult. Your project's complexity is the degree to which it is comprised of mutually interlocking components or hierarchical layers. Your project's difficulty is simply a measure of the effort required to develop it.

Think of complexity as applying both to the conceptual domain (model) of a system, and to its implementation. In the domain arena, the core skills for managing complexity are analysis and design: breaking down the problem conceptually, and matching the domain of the solution to the domain of the problem. In the implementation arena, the core skill is development: expressing the solution to the problem in some kind of programming language, in a way that clearly communicates both the structure and the intent of the design. In traditional "waterfall" methodologies, these exercises tended to be distinct and non- (or mostly non-) overlapping. In contemporary "agile" methodologies, they are tightly integrated and iterative.

At first glance, it would seem that project complexity and project difficulty would have a fairly direct relationship. When your system's complexity is properly understood and managed, this is probably true at a very macroscopic level: don't expect to implement and test a transaction server or remoting system with the same effort it takes to write a little CRUD web application for your corporate intranet. However, if your team isn't making the effort to analyze problem domains, and design solutions that fit, the ease and simplicity you're trying to achieve will forever elude you. Ironically, by focusing on the easy-difficult axis instead of the simple-complex axis up front, you will create far more difficulty in the long run.

Start paying very close attention to the way you use the words simple and easy, and see if it's not the source of much confusion in your own thinking, and much misunderstanding in your development strategy.

Common sense? Perhaps. But the temptation lurks just beneath the surface of that all too common mantra: "Keep it simple!" We simply must dismantle this confusion as soon as possible. It won't be easy!

"Make everything as simple as possible, but not simpler."

-- Albert Einstein