The Cost Of Choice

Everything I Know, I Learned From Rails, Part I - The Cost of Choice

This is the first article in a series to try to convince more developers to learn Ruby on Rails, even if they are not involved in web programming. See also part II.

Rails constantly preaches the idea of Convention over Configuration, or con/con. By way of con/con, Rails makes decisions for you. Some of these include directory names and layout, database table and column names, and others.

To quiet the naysayers, there is the claim that you can customize these defaults to your liking. But before this happens, somebody asks the question "Why?" and it doesn't happen. Nobody really knows if you can customize these or not :) As a result, a great many of the Rails applications use the default conventions.

Choice is expensive. Extremely expensive. Is there anything more costly than being able to make choices? Think about it. Here are a few time costs

• Setting our various PATH variables, accommodating the directory structure of a new library we've included in our project
• Figuring out where this project builds to
• Looking at stored procedures to determine mapping to relational tables
  
• Determining which directory/registry to put our configuration files in
• Learning how to configure/configuring/reconfiguring/rolling out configuration/synchronizing configuration
• Added complexity in our code due to options in our software
• Added complexity in our tools due to the above
  

And the list goes on. But, this is only the direct costs of choice. There is also a second, even more expensive indirect cost. The indirect cost is not what we have to do because of choice, but what we don't do because of choice.

• Reusing code is difficult, we'll just write ourselves
• Testing code is difficult, we'll just hope it works
• Automating anything is difficult, we'll do it by hand
• That tool would take a minute to write and an hour to make work, I'll pass

When we move from a configurable environment to a con/con environment, things change noticeably. Configuration is automatic. Things are easy to find. Names are easy to remember. Code gets reused. Test are simple. Automation happens. Tools are easy to write. We make fewer decisions about things which don't impact our final product, and more which do. The Schmitzer becomes happy.