Complexity is a disease

The Ockham's Razor Principle of Content Management Systems says that given two functionally equivalent content management systems, the simplest one will be chosen. It asserts that simplicity is preferred to complexity. As content management systems become more alike in terms of critical functionality, ease of use will become a key differentiator (rather then functionality).

In addition, web application frameworks like Ruby on Rails, whose goal is to develop applications with as little code as possible, are redefining the rules of how websites are built. For web application developers, ease of development will become a key differentiator.

Hackability is key.

Complexity is a disease.

Making Drupal (i) easier to use, (ii) easier to develop for, and (iii) easier to theme -- while maintaining its functionality and flexibility -- is what I'll be working on.


Chris Johnson (not verified):

I agree with your main point about simplicity being a key differentiator. From my point of view as a developer and implementor, however, CCK adds complexity. Sure, it makes it easier for the "author" user of a website to create new content types. But as someone who has to code or support or admin the system resources for such a site, CCK makes that life more difficult.

It's for that reason, I do not think CCK belongs in core (or actually, in the framework). I definitely think that CCK should be a core-maintained set of modules, and likewise included in a standard, popular install "profile" or "package." I just don't want to have to disable it and de-install its tables for the many websites I may have which won't use it.


I agree, in its current shape the CCK adds complexity. By the time the CCK is ready for inclusion, it should be free from any unwanted complexity. To get there, review the CCK's code, and provide John and John concrete feedback. Watch over their shoulders to make sure they don't add too many bells and whistles. I want the bare minimal.

Wim Mostrey (not verified):


not necessarily so. If the CCK comes with current popular content types, like 'page' and 'story' preinstalled, there is no added complexity, at least not for the end-user. He gets to keep the curent usability, with the added functionality of getting to create own content types. Popular content types could even be easily added by sharing sql statements, added in an easy-to-use php script or not.

Khalid (not verified):

Less code = less complexity + less bugs + less maintenance.

This disease is common among software developers, even in the corporate world: if all you have is a hammer, then everything looks like a nail. By analogy, since they are software developers, they write MORE CODE to solve problems, thus starting a vicious cycle that never ends: code gets more complex and hard to maintain, hence more buggy, hence more code, ad nauseum ...

The KISS Principle is so true when it comes to software (Keep it Simple Stupid) ...

Laura (not verified):

I'm not so sure that simpler is always better. Which is easier to drive: A BMW? or a prototype car that just has a joystick? The BMW, with steering wheel, pedals and gear shift, is much more complex in terms of user interface, but for most people it is also easier to use, despite the fact that the prototype vehicle with just a singular joystick is obviously a much simpler interface. Existing patterns of use always come into play.

In another example: A looping handle on a door you can only push open is bad design, no matter how simple it is. People will take a cue from the design and try to pull that door open. A push-latch bar on a door, on the other hand, is much more complex to design and manufacture, but it is infinitely easier for people to use. Very few people will try to pull open that door.

Complexity isn't a disease -- confusion is the disease. Complexity often leads to confusion, and that's a problem. But complexity in itself doesn't have to confuse. All you have to do is listen to a Beethoven symphony to hear the proof of that.

When it comes to Drupal's complexity, I don't see it as a problem in and of itself. It's how the complexity is organized for the user that many people find challenging.

You're speaking to my heart when you say that the true emphasis in growth should be on the user experience. In my mind, that means user inteface design that:

  • uses affordance (as in the door design above)
  • is accessible
  • chunks information
  • has a high signal-to-noise ratio (easy to see what's important)
  • embodies forgiveness
  • provides effective feedback loops
  • finds a balance between flexibility and useability
  • employs effective use of the 80/20 rule (80% of use involves 20% of features)

I could go on. (IMHO, while there's room to improve, especially with admin functions, Drupal isn't that bad in these design areas. One reason I didn't like Mambo when I tried it early last year is that it did not embody too many of these design principles -- especially forgiveness.) With the direction we're going in terms of separating theming from function, I think we can really rule in the area of design and useability. Both function and GUI can develop at full tilt, without conflicting or crossing each other up.

A book you might find interesting is "Universal Principles of Design", by William Lidwell, Kritina Holden and Jill Butler (Rockport Publishers: 2003).


Complexity isn't a disease -- confusion is the disease. Complexity often leads to confusion, and that's a problem. But complexity in itself doesn't have to confuse. All you have to do is listen to a Beethoven symphony to hear the proof of that.

Interesting comment, Laura.

An audience listening to a Beethoven symphony cares about the sound, not about the underlying complexity. However, it takes expert musicians to perform such symphony. Furthermore, a symphony is set in stone. Contrast this with Drupal, which has to evolve in order to survive. As Darwin said, it's not the strongest organisms that win, it's the most adaptable. Thus, Drupal targets both the users (listeners) and the performers (developers); it needs to be easy for both. From a developer's point of view, complex systems are often more difficult to change, whether they are confusing or not.

Of course, there will always be exceptions to the rule, but in general, I think that complexity is a disease. Saying that confusion is a disease is correct, but slightly too narrow.

Laura (not verified):

Interesting, because I would say just the opposite: that saying complexity is a disease is too narrow.

Maybe we're getting sidetracked, but I would disagree that the audience does not appreciate the complexity of Beethoven. Further, I don't think it has anything to do with being carved in stone. Every performance is different -- perhaps not as different as different recordings of Miles Davis or John Coltrane, but still, there's a difference between the Chicago Symphony and the Berlin Philharmononic playing the same symphony. And every listen brings out new nuances, new complexities that make such works last over the centuries.

I'm with you 100% on making things, including Drupal, "easy". But complexity in itself is not the ultimate challenge. When you say, "complex systems are often more difficult to change", what you're really saying is that it's easy to get confused when changing complex systems. But simple systems can be just as rigid. For example, movie cameras, despite incremental changes and improvements in engineering, haven't changed much in 100 years, while digital video cameras, infinitely more complex, have changed radically just in the last couple of years. Yet I would bet our annual gross revenue that 99% of the people out there would find the digital video camera easier to use than a Bolex or Eyemo or Arriflex 435 Xtreme. In still photography, my point-and-shoot Sony DSC-P200 is vastly more complex than a classic Leica, but which is easier to use? Most people would say the Sony.

--And yet, given some advanced-beginner knowledge, many people would choose the Leica or Arri for their quality of results, despite their greater complexity of use. The more complex but easier to use digital camera affords point-and-shoot for the user, but the simpler but more complicated to use film cameras afford the kinds of control that invite photographers to experiment and really think about what they're shooting and how.

Taking it to a web front, one reason we see some truly radical applications of Drupal is its relatively easy to use complexity, while systems like Mambo/Joomla come across as simpler to new users, but end up locking them in to more rigid architectures that are more difficult to change.

All I'm saying is that there's much more to design of all kinds than working against complexity. Sometimes complexity is exactly what's called for (e.g., having several different ways to do X, adding failsafes against catastrophic errors, or offering added flexibility for people for whom the simple options simply do not suffice).

Ease of use: ++++1
Lack of complexity: depends.

Anyway, interesting discussion.

MarQ (not verified):

Met Drupal heb je het gevoel met een auto te rijden met een zeer krachtige motor, met een toenemende frustratie omdat je niet van het hele potentieel kan genieten. De leercurve is lang en ontmoedigend. Maar toch heb je ergens het perspectief dat alles ooit in mekaar gaat passen. Maar heb ik daar de tijd voor? Of wil ik daaraan tijd besteden? De discussie over complexiteit is niet alleen boeiend, het is, gebaseerd op eigen beperkte ervaring, een kwestie van overleven. Na de mist van de meervoudige sites, is het nu worstelen met de vertaling. Drupal is voor de engelstalige wereldburger gemaakt. Vertalen, zoals naar de moedertaal van de ontwerper, is moeizaam. Haalt het perspectief het van de complexiteit?

Anonymous (not verified):

With all due respect Drupal would take a huge leap forward in terms of usability (not to mention simplicity) if you'd just sort the confusing terminology before you worry about CCK. What's a story anyway, and does a node get published in another node, if so why do I create pages? Etc etc.

There is a growing feeling that Drupal is doomed because of the aformentioned Ruby on Rails approach or, more accurately, the 37 signals philosophy. This stresses simplicity as the main goal.

Whilst you guys are arguing about what a core element should be, others are creating CMSs that have as their goal the ability to easily theme and doctor a CMS without even seeing code.

In my opinion it is the philosophy of Drupal that is all wrong; the kind of mentality that assumes it's no big deal downloading a module, installing it, then configuring some PHP to get it all working. This is so old-fashioned it's practically steam powered.

A good example of this is that the admin interface, even for Drupal 5, is way to complex to hand over to a client if you are designing a site for someone else. Again the terminology is dire, and there's seems to be little thought being put into what a CMS is. It's certainly a lot more than a loose collection of modules.

Whilst the goal of keeping the core simple (in terms of modules that are included by default) is commendable, it seems pointless given Drupals considerable learning curve. As noted the time would be better spent making Drupal make more use of people's existing skills. As a web designer I am ideally looking for a system that will exploit the knowledge I already have (design, layout etc) without having to wade through PHP. I understand a website is made up pages, which in turn contain content like text and images. Why would I spend time learning new words for these things?

Just so it's clear I use Drupal myself but I'm desperately looking for something more sensible; ideally a CMS that never uses the word "node". However if complexity is a disease, then I'd say Drupals' prognosis is probably terminal. The philosophy behind newer approaches like Ruby on Rails is completely different from Drupal. The very fact that there is a discussion here about whether to include a module to change content types reflects the problem. Why is it an optional module at all? Since you can't predict what kind of content people need, and the applications purpose is to serve content, then it's needed. Simple.


I'm trying to translate your comment into concrete action points so let me summarize and break down each of your comment's paragraphs:

  • Paragraph 1: make Drupal's terminology more accessible.
  • Paragraph 2: Ruby on Rails drives the need for simplicity.
  • Paragraph 3: your time is best spent making Drupal easier to use.
  • Paragraph 4: don't ignore the fact that downloading and installing a module is still a big deal.
  • Paragraph 5: the administration interface of Drupal 5 is still difficult to master.
  • Paragraph 6: your time is best spent making Drupal easier to use.
  • Paragraph 7: you're doomed if you don't try to be a better development platform, similar to Ruby on Rails.

In short: make Drupal easier to use (terminology, administration interface, downloading and installing modules), and invest in making Drupal a better platform for development.

Isn't that what we have been doing?

Gs (not verified):

If Drupal is a tool for the development of adaptative sites, what is best to achieve results:

1. A discrete set of basic pieces that can recombine to form highly complex forms with simple methods in an embedded and recursive accumulation.

2. An ever-growing set of basic pieces that recombine to achieve many results with many different direct methods.

I think (1) achieves much more effectiveness. It's the generalistic approach (Less tools, more recombinatory rules) against the casuistic one (one type of piece, one rule if you take it to the extreme).

Anonymous (not verified):

Until Drupal gets simpler and easier to deploy on tight deadlines I will continue to use ExpressionEngine. Enough said.

alvin (not verified):

I feel weird writing something here three years after the original post and two years after the last comment, but in 2009 -- as I just set up my first two websites with Drupal -- I find Drupal very hard to use. To create my first blog entry using Drupal, I had to watch several videos, buy an O'Reilly book, and install modules. I quickly realized that using Drupal was going to require a significant investment of my time.

By contrast, with Wordpress, I just install it, and start writing blog entries.

That being said, my reason for coming to Drupal from Wordpress is that I want/need the built in multi-user functionality. I am currently expanding one of my websites ( to include features like a photo gallery, travel section, event calendar, and other multi-user features, and I didn't like the Wordpress approach of trying to integrate third-party apps like Gallery2 for a photo gallery.

From what I've seen, I think Drupal has an advantage here of having a consistent user interface across modules, single sign-on across modules, and the use of one database for all apps/modules.

I was going to write more, but in short, I hope Drupal 7 is a significant leap forward in usability. The barrier to entry is very high right now.