Convention over Configuration

I like the benefits offered from Convention over Configuration.

I probably came across a serious application of it first when looking into Maven, where you are given you project structure and if you follow it, most of the work of looking after you project is done for you. You can of course choose your own, but then it’s up to you to sort it out.

More recently I have found it with grails. Again, your project structure is provided and if you create a file in the domain directory, that is assumed to be a domain object and the framework will, if asked, create a controller and views for it.

Convention over Configuration has enabled me to get into [insert target technology here] quickly, without getting caught up in the sort of lengthy set up that might just be too involved for the time you have available. Imagine taking an hour out of your day to get a handle on your first aspect of J2EE, something like JMS for instance.

Actually, how long would take you to knock up a “Hello World” message driven bean when you do know what you are doing?

Unfortunately, these benefits have only really been mine and not the projects I’ve been working on. Over a number of years, I have been involved early enough to have been involved in some aspect of the inception phase of a number of projects. In many of these there was time spent on defining the project structure. Not the architecture or the design, just where the the source folder was going to be in respect to the lib folder or what the package name for tests would look like. I’m not talking months of discussion here, but time, each time nevertheless. So even this small part of convention would have been beneficial.

comments powered by Disqus