Simplicity vs Complexity: Turns Out That It’s Not So Simple

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

As I’ve said before, and the folks from lesscode.org continue to prove, simplicity really has come full circle from perjorative to virtue – technologically speaking, anyway. But the interesting thing is that simplicity is not an end state, it is rather a moving and very dynamic target.

Following my talk last week, a very polite gentleman from Microsoft (I won’t name him, but if he wanders across this he should feel free to identity himself) approached me and asked a very simple question: how many products was I aware of that managed to maintain their simple approach over a sustained period of time? It was a great question, and frankly one that I still can’t answer all that well. Google maybe – though one could argue the point with the introduction of Google Fusion, I suppose, and Linux perhaps. Craigslist also has preserved much of its original simplicity.

But irrespective of how many examples I could come up with, the point is well taken. Simplicity is relatively easily accomplished at the beginning of any project lifecycle, but gets progressively harder over time. In an industry that prizes innovation and new features, a dedication to simplicity can be seen as stagnation or a disturbing lack of energy. More problematic for the technologies, simplicity can be seen as the antithesis of growth – the single metric by which most if not all commercial entities are judged.

So it is that we see a couple of key members of the LAMP stack adding features that answer needs yes, but may also impact complexity. PHP’s evolving from its scripting roots to a more object oriented approach, while MySQL is adding in features such as triggers and stored procedures that it lacked previously. In short, both are becoming more functional which may be good, at the expense of simplicity, which could be less so. In both cases we’ll have to see what if any impact this product evolution has on the overall simplicity, as that’s been a major selling point for MySQL and PHP in my experience.

This discussion is by no means limited to MySQL and PHP, of course; the balance between simplicity and complexity is something that most technology providers will continue to face as they evolve to meet customer and partner needs. While I regrettably don’t have any hard and fast rules to hand over as guidance, I’d just remind vendors first that listening to your customers (me, Joel) can be both good and bad, and second that whatever path they choose – try and get there with less code.


  1. Three points.

    First, I think you are confusing "good enough" with "simple." Lots of software gets released when it is "good enough," but not yet fully functional. People use it and like it. Some are disappointed that the higher-end functions are missing, but tolerate it. Everyone expects — and most people want — more eventually, but are willing to start with less. That's Christensen's disruptive innovation. Some of the software you think of as "simple" is just in the "good enough" phase of its life right now.

    Second, you have to decide where to measure simplicity. Most UNIX implementations (and, these days, Linux as well) are complicated in implementation, but still have the simple, composition-of-small-tools-with-pipes philosophy. The entire system may be a steaming heap of spaghetti, but if I can do the things I want easily, what do I care?

    Third, absolute simplicity is very, very hard to preserve. At Sleepycat, we have a goal — most often honored in the breach — of publishing less code from one release to the next. If we rework some piece of the system, like locking or transactional logging, we want the new implementation to be fewer lines of code than the old. "Less code" is impossible as your feature count climbs, but if you aim for less code over time implementing each of your features, we think you are doing the right thing.

    Ignoring my second bullet, implementation matters. Complicated things fail in ways that are hard to understand. Simple things fail much less often, because you can anticipate the failures and design to handle them. It's the old saw: "No obvious errors" versus "obviously no errors."

  2. Interesting parallels with the financial world. We are currently trying to fix several problematic business lines that became so complicated that they could no longer be easily understood or controlled. The solution we are using is to strip them down to bare bones so they are more easily understood and so that when things go wrong the reasons are more easily and quickly understood. Unfortunately this also requires the elimination of many of the architects of the complex model. In our case it seems the complexity was used as a means of purposely making the business difficult to understand.

  3. Christopher Baus has something to say about Linux being "simple" (http://www.baus.net/linux-isnt-simple). I know it was a minor example in your article, but I also don't understand how Linux is simple.

  4. The answer to this problem as been found in ages and it's called Application Life cycle.
    True, an application will be more and more complex over time that is why you get to a point where the previous architecture will no longer be the best thing for you customers and you have to change the basic architecture of your application.
    simplicity, usually, isn't a focus of the implementators so, it get's lost with the product's evolution but, that's OK because there is only so much things you can spoil with a few versions and, any architect knows that in a few years the application will have to go back to the bench.
    Now, if you work for a corporation that never re-designs the architecture of a product, then, you'll have problems (security, reliability and lack of concistency in the interface) but that's a choice corporations have to make.
    Of course that speaking of simplicity in general is very easy. Very few products can implement simplicity to every group of people that work with it (developers, Sys. Admins, end users, etc). Usually, things get optimized for a group or the other and that is an assumed issue. I think that is masquerating the issue but, today, I'll give this one for free.

  5. Mike: not sure if i'm confusing them so much as i believe they're inextricably intertwined. taking MySQL, was that a good example of "good enough?" sure. but that "good enough" offering lent to it a measure of simplicity. i agree that the expectation is towards growth, but as you point out i think that's in essence what's difficult to manage.

    second, i agree. simplicity is not a universal constant, and this one of the things i mentioned in my PHP talk. Linux is to some (like me) the very epitome of simple; to other like Christopher Baus, it's inherently complicated. simplicity is in the eye of the beholder, perhaps?

    interesting embrace of the less code philosophy as well.

    pops: remind me of that story – i'll have to bring that one up later. it just drives home the fact that simplicity is not by any means strictly a technology concern.

    anon: yup, i've commented on Christopher's post in my del.icio.us links.

    Jaime: i think you're right in the sense that that is *an* answer, but the difficulty from where i sit is in convincing some organizations that simplicity should be a priority.

Leave a Reply

Your email address will not be published. Required fields are marked *