--- title: "37Signal's David Heinemeier Hansson responds on lessconfig, the advantages of convention" date: 2006-04-13T23:12:26Z modified: 2006-04-13T23:12:26Z permalink: "https://redmonk.com/jgovernor/37signals-david-heinemeier-hansson-responds-on-lessconfig-the-advantages-of-convention/" type: post status: publish excerpt: "" wpid: 581 categories: - Uncategorized timestamp: 2006-04-13T23:12:26Z tags: - Uncategorized --- I have been wondering about the advantages of [lessconfig](http://www.redmonk.com/cote/archives/2006/03/re_lessconfig.html), that is, the maintenance advantages of delivering technology that needs less configuration, because, for example, the right defaults are chosen in the first place. Good open source [package management](http://www.redmonk.com/sogrady/archives/001458.html) leads to lessconfig, and subsequently more adoption. No XML files to mess with is lessconfig. A closely related predecessor concept, [lesscode](http://lesscode.org/), comes from development thinking. One of the best current examples of a lesscode approach is [Ruby On Rails](http://www.rubyonrails.org/). Ruby on Rails is interesting because it forces constraints on developers… _and they like it_. Rails is about freedom in the Kantian sense-development has a categorical imperative – what you do should be _morally_ applicable to anyone else in the same circumstance. Its about responsibilities rather than rights. The responsibility to ease of use. Abstractions are aspects or constraints of the framework itself, rather than veneers to hide code behind and allow ever more configurations to be applied. Freedom comes from accepting and working within constraints. Beautiful code comes from limitations, not being able to configure everything in sight. Forgive the philosophy but the creator of RoR, [David Heinemeier Hannson](http://www.loudthinking.com/), is a pretty deep thinker, touched as he is by the hand of Design with a capital D. So I decided why not just ask David what the lessconfig implications of RoR are. David was good enough to answer the question, helping us to understand the [signal vs noise implications](http://www.redmonk.com/jgovernor/archives/001420.html). > Q: Does lesscode mean lessconfig, less maintenance? What are the advantages of convention over configuration? Am I barking up the wrong tree-or do you have any evidence, anecdotal or otherwise, that gets to the heart of the second order benefits of lesscode, or dev by convention? > > DHH: I think conventions, less code, and less configuration are all > instrumental to lowering the costs and pain involved with maintaining > legacy applications. We’ve been working with the Basecamp code base > for nearly three years now. It’s about 10,000 lines of code. > > Convention has meant the world to this application. We’ve had four > different programmers work on it and the conventions make it much > easier for people to pass in and out. It removes the hunt of the > complete picture by having the concerns centralized around very few > lines. > > So my experiences would tell me that conventions of reward ("do it > like this and you’ll get that for free") has a really long shelve > life. I remember when I worked in PHP, I would always tweak the > configuration approach a tad going from app to app. This would lead > to the code base of the previous project feeling really old really > quick. > > Rails applications don’t suffer from the same notion. Yes, we keep > adding features and tweaking APIs to make the common stuff easier, > but the majority of core conventions has been stable for a very long > time now. It gives all applications a common culture and fix point. Tags: [David Heinemeier Hannson](http://technorati.com/tag/David+Heinemeier+Hannson), [Basecamp](http://technorati.com/tag/Basecamp), [37Signals](http://technorati.com/tag/37Signals), [Rails](http://technorati.com/tag/Rails), [Ruby on Rails](http://technorati.com/tag/Ruby+on+Rails), [PHP](http://technorati.com/tag/PHP), [lesscode](http://technorati.com/tag/lesscode), [lessconfig](http://technorati.com/tag/lessconfig)