I have been wondering about the advantages of lessconfig, 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 leads to lessconfig, and subsequently more adoption. No XML files to mess with is lessconfig.
A closely related predecessor concept, lesscode, comes from development thinking.
One of the best current examples of a lesscode approach is Ruby On Rails.
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, 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.
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
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
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.