A culture of complexity, or why I left OpenACS for Rails part II

I can’t help but be a bit amused at the response to my post on leaving OpenACS. It illustrates very clearly one of the things that I had almost forgotten, but that I do not long for: The culture of complexity.

Take this gem by Neophytos as an example—not to single out Neophytos, he’s an honorable person, but this quote does represent the culture pretty well:

expose UI granules both at the tcl level and also at the highest level via customization services… for example, there must be a way to represent a page as a tree of UI granules/portlets that depend on a collection of data sets and their decoration and placement (layout). This IMO would enable a developer-developer to prepare a page quickly and only at the end improve the graphic design part. [This is not as simple as it sounds but it can be done]

I’m sure it can be done, but should we?

Actually, I’m not sure what Neophytos is talking about, and that’s exactly my point. If a solution in the web application framework domain is this incomprehensible, you can bet there is a simpler solution. This isn’t rocket science, or parenting. It shouldn’t be this hard.

But there’s a tendency to believe that when your big abstractions and generalized login system/workflow engine/forum/portal system doesn’t work all that well, we just need to think harder and deeper about the problem, and we shall find the Solution.

I’ve been around the block a couple times myself, with login systems and workflow engines that were so complex that nobody was able to understand them, and which nobody used, because even after all that hard work they still didn’t do what people actually wanted them to do.

But what if instead you applied some Judo logic? What if we could avoid the hard problem altogether. What if we did the simplest thing that could possibly work, like the Agile folks like to say.

What if, instead of building a login system, you make it easy for people to make their own login system. You could make it easy to associate the user with the session, so we know they’re authenticated; to filter your requests, so they are presented with a login screen when they need to be logged in; by making it really easy to talk to the database; by making it easy to send out an email with a link to click.

In other words, once you change the level of abstraction from the login system itself, to all the elements you need in order to build the login system, you’ve judoed an unsolved problem into a solved one. Fact 16 (reuse-in-the-large) has given way to Fact 15:

Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem.

As an added bonus, you get something infinitely more useful because you can make just the login system you need, and you get code that’s readable and maintainable by ordinary software engineers. And, needless to say, this is the approach that Rails takes.

Why do so many people drift towards complexity? I don’t have the answer, but I do have an angle on it. Back in the day, at ArsDigita, the engineering team took an MBTI-style personality test, and it showed a strong tendency toward “Analytical”. So it would seem this culture was formed early on, and then stayed that way. All I can say is that I’m happy to have gotten out of its stranglehold.