Understanding the concept of Convention over Configuration

Software development has come a long way in the past 10 years. There are some great concepts that innovated and streamlined the way we develop custom software and there are other concepts that most of us would like to forget. Some of the latter things include heavy, process intensive software methodologies, proprietary software packages that don’t adhere to standards and home-rolled architecture that just doesn’t want to die. On a more positive note, the past few years have brought Test Driven Development, complexity measurements, more open standards and one of my personal favorites is convention over configuration.

Simply, convention over configuration is the ability to use coding conventions to achieve the same functionality that external configuration did before. Let me give you several examples using some of my favorite frameworks.


In Spring, convention can be used to define Spring Beans, Autowiring and many of the concepts that before required lots of XML glue. The benefit of this being that you can look at a POJO class and determine exactly what is is used for without having to go digging in an XML file for the “glue code”. Using simple annotations to demarcate Services, Utilities, DAOs, etc, eliminates the amount of XML that you have to write and maintain.


Struts is a little late to the convention game, but if you are familiar with Struts, you probably are familiar with many XML files you maintain to map your actions. The Struts convention plugin eliminates the need for all this XML by using annotations to defined your mappings.

Junit and TestNG

While testing doesn’t involve configuration so much as the previous examples, we gain another benefit here. Previously all test cases needed to extend a parent test class, but no longer. Junit, Unitils, TestNG, DBUnit have all had the ability to use a “Zero Configuration” option for some time just by annotating simple Pojo classes.

Hibernate and Java Validation

I saved the best for last here. Hibernate embraced annotations early, allowing developed to move away from hbm.xml files. Also, when you couple this with the power of the Java Validation Framework, you get a persistable domain model that has built in validation, all in once centralized location, ideal if you have multiple front ends sharing the same common codebase.

“Zero Configuration” is another term that is often used to describe a convention-driven design.

Annotations are relatively new to most developers, even thought they have been used in both Java and C# for several years now. Annotations are simple a way to self document code.

Convention-driven over a configuration-driven design has several benefits.

1. Faster to develop
2. The code is self explanatory
3. Easier to maintain, thus reducing the cost of ownership
4. It’s cleaner and easy to understand
5. Easier to refactor. (Automated refactoring tools very often butcher XML configuration files)
6. Easier to learn for newer developers. (It’s the change-resistant older-developers who usually find it difficult to make the switch)

Now that you know the benefits of a convention-driven design, you should take a look at your own frameworks and see if there is a way to accomplish it. I recommend looking heavily at Spring to start the discovery process and it has a near flawless implementation of this paradigm.