The cost of applying Convention over Configuration
This post is in response to an email from a colleague of mine who (quite appropriately) has some reservations to applying Convention over Configuration. For those of you unfamiliar with this approach, or wanting to learn more, I would invite you to read Jeremy Millers article on this topic on MSDN. Over this post, I will frequently paraphrase and quote content from Jimmy Bogards blog, since many of my opinions have already been said by him, in a more coherent way that I ever could!
Quite rightly, my colleague Chris has pointed out a cost associated with Convention over Configuration:
My trouble with conventions is that they give you performance enhancements [in regards to efficiency] in the long-term, but can confuse the be-jesus out of people when they first look at them. E.g. Loosely coupled systems can be a pain to track down where the coupling occurs, unless people are adhering to some convention regarding their setup.
At first glance (unaware of the conventions), it is easy to be put off by the inherent “magic” of the convention over configuration approach. Additionally, embedding “opinions” into your code or framework may detract from potential reuse in new scenarios where those opinions aren’t as favourable. There is also the complexity involved with enforcing conventions, although static code analysis (as part of continuous integration) can go some way of relieving this.
Multiple Versions of the Truth
Ignoring conventions by iterating endlessly, never retrofitting opinions results in having many versions of “truth” in our system, all of them correct at one point in time, none standing out above the other.
Opinionated (convention-driven) software development tends to be more efficient however, removing unnecessary decisions from the developers and promoting consistency. The result of this is that we often write need to write less code to achieve the desired result. Of course writing less code is good by me!
Application of Conventions
It is important to remember that conventions should be applied by turning already implicit concepts, into explicit concepts. Trying to form opinions in absence of any context is very likely to lead to awkward, friction-inducing development. In this case, YAGNI should prevail.
Opinions formed in one application are frequently only appropriate to that specific application. It is therefore appropriate that opinions are formed within the team involved, with new members introduced to these concepts when brought onboard.
In summary, I’d like to refer back to this comment from Jimmy Bogard, stated in regard to forming conventions:
The middle ground here is one where we become finely attuned to the pain induced by our design, [do] not try to invent problems where they don’t exist, iterate our design, and retrofit after each breakthrough. Opinionated software is a fantastic concept, but we can’t confuse opinion formation with misguided attempts to make all design decisions upfront in the absence of agreeing upon the principles that led to the opinions.