Several popular frameworks have as a core design principle that “convention” is preferred over “configuration”.

I’ve come to think that they’ve actually understated the case.  In fact, our development team has made significant strides in identifying not only causes of defects, but also the factors that slow development in exchange for reducing defects in the first place.

One of the top issues on the latter list is what we’ve been calling the “arbitrary decision”.  If a given technical challenge is hard, that can actually simplify development.  Either the first solution we find is a good one, since we save time by avoiding looking for additional solutions, which might not even exist.  Or there may be a clear best solution, or even only one that will actually work.

This “arbitrary decision” is exactly what’s referred to as “convention”.  Every convention that’s already been decided both reduces defects and saves developer time.

Defects are reduced because:

• Developers have fewer decisions to make, saving focus for important problems
• Mismatches between modules or components are reduced
• The code visually reflects the standard, making deviation apparent

Speed of development is increased simply because there are fewer decisions to make.

Here are some examples of conventions that have benefitted us:

• Code formatting standard.  We really didn’t fight over this, as the development team is aware of the benefits of not fighting about it.  We agreed our standard is “good enough”, so we can move on.
• Variable naming conventions, including capitalization of common names in our domain space.
• Which of the several libraries that provide the same functionality, such as Base64 conversion.
• Coding language versions: do we rely on features of newer implementations or make code backward-compatible