Wednesday, November 14, 2007

Convention & Configuration

When I took the (very good) Pragmatic Studio Rails training course almost a year ago there was an interesting approach to configuration that Dave Thomas made sure to cover. I remember vividly Dave saying, “Rails favors convention over configuration.” He followed this up by saying that this frees the application developer from having to think too much about configuration.

What the heck does that mean? And how does it make my life better?

Well, to get a running server (for example) there are things that simply must be specified. They may be specified by default, but the information must be contained somewhere, right?

So I've an idea that there is a little wackiness going on here and I'd like to think about it for a few minutes and see if there isn't something there.

I’m going to step away (a long ways away) from software and use geometry in 3D to examine the information required to specify something.



Going in Circles

Consider the problem of specifying a circle in 3D.

There’s the brute force method of specifying all of the points on the circumference of the circle. Given that there are an infinite number of them that’s quite a task. But fortunately we can do much better.

Another way to do it is to specify any three distinct, non-collinear points on the circle’s circumference. There is a single distinct circle that passes through all of those three points.

Is this the only way to do this?

No.

We can also specify a plane by giving a single point (p1) in the plane along with a second distinct point (p2) that defines a line normal to the plane. There is only one plane with a given normal that passes through a given point. Now if we have the convention that the circle we want in 3D falls in that plane and has a center at the first point (p1) and a radius of (p1-p2) then we have completely determined the circle.

But wait! Where did the information that was contained in the third point go? Two points don’t determine a circle (in 3D).

That’s right. There is some information implied in the convention that we will use the first point for one purpose and the second point for another purpose and the relationship between those two points for a third purpose. The information is still there. We’re just representing it differently via our convention.

And here’s where things get really interesting. Consider the human interaction of specifying circles as configuring the circle just as you might configure a server.

If you are sitting at a keyboard trying to correctly configure circles and you enter the coordinates for a given point correctly 90% of the time, then the chances are that using the three point method you will get the entire circle right about (0.9^3) 73% of the time.

But using the two point method and our convention, you will get the entire circle right about (0.9^2) 81% of the time.

That’s only one error in five as opposed to one error in four! Hell, you can leave work early and go snowboarding this afternoon with that improvement.



Back to Servers

In the circle case we were only trying to get a couple of things right (the points). But when we configure servers there are often hundreds of settings and getting each one right, with the right setting, typed right, saved in the right file, in the right location, with the server rebooted (or whatever) to get it in the right state and you can see how errors add up. With 1000 settings and an error rate of just 1 in 1000 (0.1%) you have just a 37% chance of getting it right.

No wonder it takes so long and is so hard to configure software!

But with strong conventions there are far fewer "touch points" for you to mess up. The more configuration you can push into convention the better off you are. But everyone has to understand the conventions. In a way, those conventions are just shared principles. And they go a long ways towards making things easier and less error prone once you understand the principles that the conventions embody.

So, this has been a bit of a long rambling post. What I'm hoping you get out of this "conventional" discussion (yuk yuk... I make funny) is that there's nothing too wacky here and that conventions are your friend. They encode the exact same information in a more compact and less error prone way.