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

By: stephen o'grady

stephen o'grady — Wed, 09 Nov 2005 13:07:23 +0000

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.

By: Jaime Cardoso

Jaime Cardoso — Tue, 01 Nov 2005 05:17:41 +0000

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.

By: Anonymous

Anonymous — Fri, 28 Oct 2005 12:55:21 +0000

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.

By: pops

pops — Fri, 28 Oct 2005 03:22:52 +0000

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.

By: Mike Olson

Mike Olson — Thu, 27 Oct 2005 21:24:14 +0000

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."