Convention Over Configuration
Ceremony
Have you ever thought about how much time on your project is spent on the core problems versus the time you spend wrestling with purely technical concerns? Some may say that the most important goal of all new software technologies and techniques is to reduce the distance between the developer’s intent for the software and the realization of that intent in code. And the industry has continuously raised the level of abstraction to allow developers to spend more time delivering functionality and less time writing low-level infrastructure - but there’s still a long way to go.
If you were to show your code to your business representatives - assuming that they were actually willing to read the code with you - how much of that code would they care about? Those business representatives will probably only care about the code that expresses the business functionality of the system. That code is the essence of the system. On the other hand, they probably wouldn’t have the slightest interest in code such as type declarations, configuration settings, try/catch blocks, and generic constraints. That code is the infrastructure, or ceremony, that you, the developer, have to go through just to ship code.
There are some techniques that we can adopt to reduce the amount of ceremony in our code.
Convention Over Configuration
It means that the environment in which you work (systems, libraries, language…) assumes many logical situations by default, so if you adapt to them rather than creating your own rules each time, programming becomes an easier and more productive task.
The goal is to decrease the number of decisions the programmer has to make and eliminate the complexity of having to configure all and each of the areas of application development. The immediate result is that we can create many more things in less time.
If we follow the established conventions, we can develop a applications in much less time and with many fewer lines of code than we would need developing a similar web application.
If, on the other hand, we want to ignore conventions, you can always replace them with your own code (Configuration). However, since conventions are not arbitrary, but have been established by a community of high level programmers, it rarely does make sense to waste time overwriting them.
Not everything about Convention over Configuration it is positive. There are two fundamental problems in any structured work environment.
- First, it requires a greater learning curve; you need to know the system to get the most out of it.
- Second, some see it as an imposition, an approach they feel forced to follow.
Finding a balance between convention and configuration is not easy. Too much convention can make the system too confusing and it may increase the learning curve. Too much freedom can make the user unnecessarily increase the complexity of the system, making it difficult to achieve the desired objectives.
In any case, to use a system in which most things are pre-configured is always more productive than to use a completely open system in which you have to set all the rules and take all decisions. And the return on investment usually outweighs the need to learn.
Of course, you can always get out of conventions and overwrite the system with your own solutions.
References
- https://rubyonrails.org/doctrine#convention-over-configuration
- https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/patterns-in-practice-convention-over-configuration
- https://facilethings.com/blog/en/convention-over-configuration
- https://en.wikipedia.org/wiki/Convention_over_configuration